Many years back, when I was in the second year of M. Tech (Computer Sc.) program, my hostel mates who took Fortran Programming course, used to consult me when they had any difficulties in programming. On one such occasion, one hostelmate came to me. His teacher had told him that the program that he had written was too big and that he should use subroutines to make it smaller. My friend took the advice but he could not make program smaller. Instead, he ended up adding a few more lines to the code. He came to me for help. I asked him to show me what he had done.  He had 200 lines of code which he broke in 4 parts of 50 lines,  made each part a subroutine and was planning to call these subroutines in the sequence. Obviously, the code size did not reduce. I explained to him the concept of the subroutine which performs a defined function and can be called from other parts of the code. So, one does not have to write code for that function again and again. We reviewed the logic of his program, identified couple of subroutines that could be called from multiple places and the code size came down to 40% of the original code. The code was easy to read, understand and maintain. My friend was thrilled to learn this!

This story illustrates what happens when people implement concepts that they have not understood correctly. I often see such examples in the space of Agile adoption. Recently I came across a team that has adopted agile and were following scrum practices religiously. When I attended their daily stand up, I saw the meeting being driven by the manager who was focused on addressing the UAT issues that were preventing the Go-Live. Each UAT issues was discussed, actions were agreed upon with timeline and after that the meeting ended. I asked them if the team updated the board in their agile planning and tracking tool before coming to the meeting and the answer was negative. As I probed deeper, I discovered that the way user stories were formed, individually each story did not deliver value. Multiple stories together only would deliver business value. In the end I discovered that they had stuck to their traditional waterfall development process and had introduced agile practices on top of them, as a result they were “doing agile” but in reality, were practicing waterfall with additional overheads of Agile practices. They were “doing Agile” but were far from “being Agile”.

Similar to the organization in the above example, many IT organizations are jumping on Agile bandwagon without fully understanding what it takes. Their desire to adopt Agile has business reasons. Businesses today, need to respond quickly to the constantly changing business environment. These responses are mostly enabled by the IT and hence IT organizations need to be Agile and respond quickly to the demands of businesses. However, adopting Agile is not just adopting some agile practices like delivering something in a short period of two to four weeks and having a daily meeting. It is much more than that. To understand this better, let’s look at some fundamental facts that create agile organizations.

• For an organization adopting Agile, It is necessary to understand that the paradigm of a repeatable process borrowed from manufacturing industry does not work in IT industry. In manufacturing industry machines do the bulk of the work while humans are needed only to operate the machines. These operators are replaceable. Whereas, in software world replacing any individual is not that easy. When an individual is replaced some knowledge is lost and the new team member changes team’s abilities. The change could be positive or negative. Therefore, in software world, individuals and interactions are more valued than processes and tools.  Agile frameworks recognize this and facilitate the required team behaviour.

• Various agile practices are aimed at reducing the risk of failure in software development. Agile practices take a customer centric view, advise working closely with the customer, seek frequent customer feedback and ensure customer satisfaction. They promote collaboration with customer, stepping away from contract negotiations.

• Agile practices are designed to deliver value to the customer as early as possible and continue doing that in an ongoing manner. This is done by approaching the software development iteratively and incrementally. Understanding of this iterative and incremental approach is necessary for an organization that adopts Agile.

• An User story is not just a small chunk of work that would be completed in a few days but a small unit of work that delivers value to the customer. When a story is delivered, the customer is able to do something that he was not able to do before.

• Agile practices recognize the fact that in the current fast changing world, customer’s needs can change and advocate accommodating such changes. 

• Agile approach discourages creation of huge, verbose documents. Multistage development process with each stage creating a document that is passed onto the next stage results into loss of some understanding at each stage and results in creation of bugs in the end. Agile approach emphasizes delivery of working software to the customer rather than delivery of documents.

• Agile teams are self organized. They are cross functional, empowered teams which take their own decisions and are responsible for the outcomes. Organization provides necessary support for their success.

Understanding these fundamentals of Agile and adopting the practices with full understanding of the philosophy behind them will enable “Being Agile”.  This may sound simple as it is easy to understand intellectually but its implementation could throw up challenges where the team would need help from an expert or a coach who has the expertise and experience needed to navigate through those challenges.

To conclude, just adopting Agile practices such as daily meeting, retrospectives, having a tool like Jira or Rally to support Agile etc. will not help the IT organization to be Agile. That may help, ”Doing Agile” but it will not deliver the benefits of Agile. What is needed is the full understanding of Agile values and principles, creation of rightly oriented, right sized, cross functional teams that are fully empowered, understanding of iterative and incremental approaches, focus on delivery of value to the customer, having customer engaged in the development and continuous focus on improvement and learning! These are essential to develop the Agile mindset and culture. Of course, this is something that will need time and conscious effort under the guidance of an expert.