THE “WATERFALL” VS “AGILE” BATTLE SEEMS TO BE OVER BY NOW AND AGILE HAS EMERGED AS THE WINNER. Still the current software development landscape is far from the order. It is filled with many tools, processes, frameworks, methods, methodologies, best practices, procedures (Be my guest …)
This drives many software development teams in to confusion. Outcome of this confusion is that teams have been following processes, methods, etc. just as a recipe. It can be scrum, XP, Lean Start up or even SAFe but you will see many teams use them without understanding the underlying thinking. Probably this is one reason why the (almost) movement “Be agile” had to be born.
It is obvious that teams should not use “Agile recipes“. There is no better reason than the first value of Agile manifesto to show why any team should not use a recipe . The first value states ” INDIVIDUALS & INTERACTIONS over processes and tools”. What has most value is the team itself and the interactions around it, not the use to tools. Teams should understand the basic underlying thinking of these Agile methods in order to be successful.
So the first question is what is the underlying thinking and the second question is whether is there any similarity of this underlying thinking? There is very simple answer to both the questions. All these Agile methods are based on a simple concept of “Iterative thinking” (at least what it should be). Applying any Agile method just as a tool will not guarantee the success of the project but if one can find the success if he/she understands and applies iterative thinking. In my view, there is no need to use ANY tool or method if one can master and use iterative thinking in a project.
So the big question is what is “Iterative thinking”?
Iterative thinking is connected to all the areas of software development. Iterative planning, Iterative design, Iterative development, etc. are examples. Iterative thinking can be simplified in to “it is all about slicing the customer need and deliver the solution in a progressive piece meal manner“. One important factor here is that each delivery should ensure that it is build on top of previous delivery and the future deliveries can be build on top of it.
The outcome of the “Iterative thinking” is the “Iterative delivery” and it is an extremely important concept when it comes to complex domains, scopes, etc for the success. When it comes simple software problems, the iterative thinking becomes less visible and just using a recipe can lead to success.
The “Iterative thinking” can be illustrated in an example. Let’s take typical user management feature:
- The first iterative delivery can be a simple screen where users can be added to the system and the added users are listed in a crud list. There are no validations for the user creation form. Not much thought given for the design of the user management feature. The main objective is to get the initial thinking in sync between the development team and the problem owners. This delivery can be called as “User management Spike”.
- The next delivery can be “Basic user management” where more features are beefed up on top the the user management spike. It can be that user creation form has more fields and validations are added, passwords are encrypted, etc. Also the basic design of the the user management has emerged.
- This can be extended to further iterations till the problem owner is satisfied with the given solution.
(This should not be confused with incremental delivery. See this http://goo.gl/MSWRMI)
When it comes to complex software problems (such as automated vehicle guidance systems, etc.) there will be many more iterations than a simple user management feature.
- The first iterations can be that nobody touches the code and it is all about presenting (by PPT) team’s understanding on the requirements.
- The next iterations can be further strengthen on design aspects of the system (if team feels a certain up-front design is required).
- These iterations can be further worked on through providing basic integration tests.
- This can continue from the first delivery to final user acceptance.
The magic behind the “Iterative thinking/delivery is rapid & constructive feedback. When a team follows the iterative delivery, the feedback would be specific (such as saying “I don’t need the “middle name” field here, add a new field called “Date of birth”, move the “address” to the bottom, show the last login date/time, etc.) This specific feedback would speed up the team thus resulting rapid value delivery which fits to the purpose.
So in conclusion what can be noted is that the important fact in Agile software development is not to use the tools, processes, frameworks, methods, methodologies, best practices, procedures, etc. as recipes but to understand the concept of Iterative thinking. The simple use of Iterative thinking can lead the successful project delivery even ignoring all the norms and prescribed methodologies such as Scrum.