Background

Traditionally software development projects have followed a sequential life cycle as shown below. A project starts off by understanding all requirements up front (what the project is about). Then you spend time thinking about the technical solution, the design (how to address the requirement). And then actual construction and then testing and so on and so forth. This life cycle is also well known as “waterfall”.

No method or life cycle is perfect and so is this one. Waterfall method has some limitations or challenges and they are:
1. We can see the real end product only at the end of the project, where there might be surprises (too late)
2. Testing happens only at the end. Most of the times projects are pressed for time and what gets compromised is the last phase which is testing.
3. Almost till halfway through the project, only documentation exists, real progress or working software is not visible.
4. By virtue of this life cycle, we end up creating specialty skills like BAs, testers, coders etc and then tend to work on their own islands, at different times during the project.
5. All these roles are part of same endeavor but don’t talk to each other often.
6. Student syndrome (study only when the exam is near )
7. Wishful thinking that “we will get there” until it’s too late
8. Very few opportunities to inspect and adapt (feedback cycles)
These are just some of the challenges of following this life cycle.

 

Ever Thought Of This?

You take any product, say your mobile phone or laptop or any website like flipkart.com, how many features do we really use? It’s not even 20%! So, apply the 80-20 principle (Pareto’s law) and you will notice that 20% features of any product provide 80% of the value. Survey done by Standish group has proved this fact. So, some people always felt why we should pressurize project teams to get everything done? Especially when projects are always pressed for time? Can’t we think of delivering these 20% features in given time and still be ahead of competition (i.e. reduce time to market)?
Another interesting fact is that every product consists of many features. Can’t we break the product into its constituent small features and prioritize (80-20 rule)?
And then build this same product incrementally, feature by feature, starting with most important features first to the lesser important ones at last?

Iterative & Incremental Approach:

Iteration means repeated cycles. So some people felt that we should work with short cycles of analysis—design-coding-testing. And repeat these cycles every few weeks and keep delivering small but finished increments of the product, every few weeks. Eventually we will get the same final product. So, we will iterate, that is repeat the cycle and keep producing a “potential shippable” product increment. And keep in mind the 80-20 rule while following this method, that is, build the most important feature first and lesser important ones later.

 

           

Any Advantages? :
1. Get to see, actually touch and feel the final product increments, every few weeks
2. Any surprises or dysfunction will be surfaced early and not at very end
3. Testing happens all throughout and not only at end
4. Most important features get tested multiple times, in each iteration
5. Multiple opportunities to inspect and adapt – both the product and your process
6. Every iteration starts with a plan only for next few weeks, ends with review and retrospection of product and process
7. Entire team, all skills required to convert specification into finished increment will work together all throughout
8. Built in PDCA cycle
9. Extent of wishful thinking and all uncertainties are limited to a few weeks
10. Brings discipline and visibility and predictability since over a period of time you will know how much we are able to deliver every few weeks.
Are there some disadvantages also?
1. Lack of big picture – especially architecture / design will evolve as product grows and sometimes you will end up with a dead end that current approach won’t scale, leading to rework / revamp of technical solutions
2. Amount of regression testing will go up as you progress through the project. Every subsequent iteration will have to verify increment of that iteration, plus regression of everything built till then
3. This means heavy reliance on automated testing – otherwise this model can’t survive
4. Cross skilling and people willing to pick up each other’s work, learn new skills is mandatory
5. Users or who give requirements need to be involved all throughout. This makes sense but hard to manage at times
6. Needs skilled team members who are willing to assume their own responsibilities – to realize real agile results
7. It can’t solve all traditional challenges. But it makes them very much visible. If you ignore to notice them, the approach can’t succeed.

This is agile: There are various flavors of this method being practiced. The concept or philosophy is called agile. The actual implementations may vary, may have specific rules etc. Scrum, extreme programming, feature driven development, DSDM, etc are different methods under the umbrella of agile.