Why Agile?

Has anyone ever wondered, why has Agile become so prominent in last decade or so? What is the differentiating factor that is making people leave their traditional software approaches and take up the agile route? Does it really work or is just another gimmick created by some sales people and agile practitioners?

I may not have answers to all the similar questions that you may have, but I can share my experience with Agile. Before that, let’s just have quick look at the history of Agile. The manifesto for agile software development or agile manifesto as it is popularly known was formulated in 2001 by 17 thought leaders from the software industry (Scrum dates back to 1995). So it is nothing new; it is already time-tested and has proven its utilization in many software development products.

What transpired between the 17 thought leaders back in 2001 has now become a major wave and every other software organisation wants to make the most of it. So what exactly happened? Well, in February 2001 at a ski-resort seventeen people met to discuss, relax and find a common ground around the challenges in software development. These 17 included representatives from Scrum, XP, DSDM, Crystal, Pragmatic Programming and others who were not excited by the state of traditional software development. What emerged from that discussion was a – Manifesto for Agile Software Development – signed by all the 17 participants.

The 4 major challenges of waterfall

Visiblity: With waterfall way of software development the visibility of the product being developed acorss all its stakeholders varies drastically overtime. If we draw a graph depicting how visibility varies over time it would look like as follows:

That is at the start of the project there is lot of visibility, then as the project goes through the various phases of analysis, design. architecture, code, it starts to deplete. It starts coming back as the product comes into the quality phase, and it is made highly visible when it is deployed.

Change: With waterfall way, change management was very difficult. Especially, when the actual development is started. The ability to handle a change over the lifecycle of software development in the waterfall way gets lost over period of time.

Value: In traditional SDLC the value delivery happened at the end of the life-cycle i.e. when the product was deployed in the production environment. There was no way to create value with the product throughout the product development life-cycle.

Risk: During the initial stages we do not have much clarity about the product itself, also we do not have any mvp or prototype that would validate our assumptions. Thus, the overall risk involved with the product is high. It remains high for a longer duration till we actually start building the product and get into the stages of architecture, development, testing and deployment.

How agile overcomes the challenges with waterfall

Visibility: Two of the four values of manifesto for agile software development talk about – Individuals & Interactions and Customer Collaboration – that is a lot emphasis is given on keeping things transparent and visible to everyone who is involved with the product. Various frameworks/processes that support agility imbibe various events to ensure that all the aspects of product development life cycle are inspected regularly and made transparent and visible often to key stakeholders.
A visibility graph with agile way of working would look like

That is the visibility even though dips for a while it soon emerges back.

Change: One of the core principles of agile is,

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

teams welcome change. Even though the ability to handle change decreases to some extent overtime, yet teams working in an agile environment can manage changes better than the waterfall way of development.

Value: In iterative and incremental software development model, in agile value could be realized earlier and often. The idea in iterative and incremental development model is to create small increments of the product in an iterative fashion and release every increment as and when it is ready for market. This gives the business to realize value earlier as well as an opportunity to make decisions whether to continue or discard the product if it does make sense for the business.

Risk: With the iterative and incremental model, we start building and releasing the product from the very initial stages. This allows us to validate any assumptions that we have around the product. As a result, the risks involved are addressed from the very early stages and are reduced/mitigated to a larger extent over a period of time.


Thus, it is pretty clear that with agile the major challenges faced with traditional software product development can be tackled effectively.

I hope I was able to address few questions with which I started this post.