Should we choose Iterative or Agile?
One of my current clients, a large government agency, have recognised that their current monothilitic waterfall approach doesn’t work all that well and are trying to decide whether to change their delivery approach to Agile or “just” Iterative (mini-waterfall style).
Management have recognised that introducing Agile is a major change and that it requires a change in the way people go about their daily work, a different management style and a change in attitude and behaviour for everyone involved.
I respect my client for recognising the magnitude of the change and I also appreciate that the attraction of an iterative development approach is that it doesn’t require much change. However, I think this is a “weasel-out solution” which, while helping management to hedge its bets, will not solve any of the fundamental problems associated with waterfall projects and will cheat my client of the benefits Agile could provide.
Here are 6 reasons why I would highly recommend to choose Agile rather than Iterative:
Iterative vs. Agile:
First of all, Agile is iterative already but it is way more than just iterative. Here are a number of differences between Agile and “just” Iterative development:
Mini-waterfall is still waterfall
Iterative is still waterfall, just on a smaller scale. A series of mini-waterfalls is certainly better and less risky than one big waterfall but mini-waterfall still is fundamentally waterfall and comes with all its known problems such as difficulty to adapt to change (“Nice idea but sorry, the requirements have been signed off months ago”), cascading delays (“Oops, we need to shorten the testing phase”) and low quality (“We don’t have time to fix those bugs. We’ll fix them in a later phase/iteration”).
Agile is iterative AND incremental
Iterative development splits large problems into smaller chunks but without an incremental approach it requires a perfectly shaped idea and solution upfront as well as dead accurate estimation to build the right thing according to plan.
Agile assumes that the first idea is not necessarily the best and final one and that learning happens continuously throughout the process. It encourages a tight feedback loop to incorporate new knowledge, emerging requirements and innovative ideas even late in the process. Incrementing in addition to iterating towards a solution hugely increases the chances of success.
Agile helps “building the right thing” through customer involvement
Iterative development does not address the lack of business and end user involvement usually seen in waterfall projects. Reports and PIRs time and again show that lack of business and end user involvement results in solving the wrong problem, making the wrong tradeoffs and increasing risk by not building core functionality first.
Agile bakes customer involvement in through making the customer and end-user representative part of the delivery team throughout the entire duration of the project or life cycle of the product. Agile teams don’t second guess; they ask, watch and learn.
Agile delivers high quality
Iterative development still puts the testing phase at the end of each iteration. Testing at the end of an iteration results in defects not being detected until late in the iteration which usually makes it impossible to find the time to fix them. In addition, if any of the previous phases of analysis, design or build is delayed the test phase will be shortened and quality issues will go undetected even longer (Ever been on a project where bugs were found during systest or UAT?).
Agile on the other hand does not have phases during an iteration and ensures testing is done continuously from the very beginning. Any bugs found during the iteration will be fixed before new work is started. This guarantees that we have working software at the end of each iteration with no work left to be done (no 90% done or known defects). Should we run out of time we compromise scope but never quality.
Agile is open to incorporating feedback and learnings
Iterative development has no mechanism built in to accommodate feedback and learning. Most of the time planning and design still happen upfront and scope is usually well-defined and fixed. Change arising from user testing, stakeholder involvement, increased understanding of the problem and an ever changing world can’t easily be incorporated into a just iterative approach without increasing project risk. Also, iterations can be as long as three to six months long which makes collecting feedback an infrequent matter and increases the risk of being out of touch with customer and business needs.
Agile limits iteration length to one to four weeks which ensures that feedback is received in a timely manner and can be used to adjust course. Scope is somewhat variable and defined in user and business goals which makes it possible to be open to changes to the solution while focusing on the desired business outcomes. In fact, Agile encourages testing all our assumptions to maximise early learning and to minimise risk. Apart from early feedback risk is managed through ensuring that core functionality is built first, a concept that is not necessarily required in iterative development.
Agile fosters communication and collaboration
Iterative development retains a phased approach (analysis, design, build, test) and promotes the existence of functional silos. Functional silos communicate through written handovers, often “thrown over the wall”, which are a known breeding ground for misunderstandings and omissions. At best BAs, designers, developers and testers will co-ordinate their work with each other but they will never truly collaborate.
Agile relies on self-organising, cross-functional teams responsible for and authorised to reach a shared goal. Not only will this reduce the number of handovers and miscommunication it will foster real collaboration where the whole is greater than just the sum of its parts.
Overall Iterative development doesn’t force organisations to change and while some might say that’s a good thing I think Agile has so much to offer that it’s well worth the effort and learning curve.