In my last blog I descibed the Iterative Waterfall anti-pattern. I described what the problem looked liked, a variation of the problem (the Staggered Iteratvie Waterfall anti-pattern) and some of the reasons for how these anti-patterns evolve.
This week I would like to discuss how to avoid these anti-patterns and, if avoiding them is not an option, how to move a team from this model of software development to a model that is more closely alligned to Agile methodologies [such as Extreme Programming (XP) and Scrum.]
How to handle the transition
I struggle to see anything beneficial with the Iterative Waterfall (or the Staggered Iterative Waterfall) approach to software development. It has all the disadvantages of a traditional waterfall model and none of the advantages that are promised by Agile.
A project that has adopted this model can be very complex to manage, especially when there are exceptions. How should bugs and software defects be handled in this model? Should a whole cycle be devoted to debugging? Should the defects from one cycle be fed directly into the next available development phase? Either of these approaches would have direct impact on work that has been already planned, so how should we deal with scheduled slippages?
To effectively manage in this environment requires increasing levels of sophistication and complexity. Teams using this approach can (and do) deliver software successfully. There are however, ways to deliver software that are far more transparent and hence more likely to succeed.
My personal recommendation is that the Iterative Waterfall and Staggered Iterative Waterfall approaches to software development be avoided all together. If you’re about to start a project and this is the approach that you were thinking of taking then please take the time to rethink that decision.
I can understand some of the arguments for using this approach: the organisation may be risk adverse and a fully Agile approach may be seen as too risky; the team may lack understanding of Agile; your primary customer may not like change, etc. When all is said an done, however, both the Iterative Waterfall and Staggered Iterative Waterfall antipatterns will take you further away from highly collarbrative, productive teams.
When avoidance is impossible
It’s a more complex situation if you’re already in the middle of a project that is taking this approach. Stopping and restarting a project using an Agile methodology can be both difficult for the team (relearning processes, responsibilities etc) and often politically unacceptable.
I personally don’t feel that an abrupt interruption to the team is a good thing, and I would recommend a approach of evolutionary change. My perferred approach is to try and change the teams development practices over a period of time (often months) within the current process. Initially, this approach starts slowly, but if done on a regular schedule it can be very effective.
Evolutionary process change
The crux of this approach is creating the perception with management, the development team and the business customer that the current model (ie. Iterative Waterfall, Staggered Iterative Waterfall, RUP etc) is just a stepping stone to adopting a full Agile process. This is a message that needs to be repeated loudly and repeated often, possibly for the duration of the project.
Once there is broad understanding that the project will continue to evolve it will be easier to gradually introduce change to the team. When I talk about introducing change, I’m really talking about introducing agile practices. The practices that are recommended by Extreme Programming (XP) can be found here.
XP is a useful place to start because, as you can see from the list above, there are planning practices, design practices, coding practices and testing practices. I find that this categorisation of practices is straight forward and quite easy to comprehend. These practices need to be introduced in a regular and frequent manner; a new practice every monday morning, for example. You might introduce continuious intergration this week, and next week you might ask everyone to colocated in a project room for at least 6 hrs a day for the remained of the project.
Implement those agile practices that are easiest to implement. Every project and every environment is different, so recommending what will be easiest to impliment for a particular situation is impossible. But I think it’s safe to say that some practices are easier to implement that others for any given situation. If continious integration can be easily introduced into your organisation then do it; or if Test Drive Development can be easily introduced, then do that. Practices which remain a mystery to you (such as adopting a metaphor) can wait until some of the more readily understood practices are in place.
Of particular importance is the introduction of stories to replace tradition waterfall deliverables and/or use cases. This is often the most difficult part of learning Agile software development and is the least likely to be implemented correct. Rather than discuss Story writing here, I would like to refer you to Mike Cohen‘s excellent book “User Stories Applied”. Suffice to say here that Stories should only contain a brief outline of the business intent and should most definitely contain acceptance criteria.
Last week I discussed the Iterative Waterfall and the Staggered Iterative Waterfall antipatterns. This week I’ve talked about how to migrate a project from these antipatterns to a more agile approach using evolutionary change [rather than abrupt change].
Bringing change to an organisation is possibly one of the most difficult endeavours that one can undertake. Although the ideas presented here are conceptually simple and straight forward, make no mistake that the implementation of them is seldom simple and never straight foward. I wish you the best of luck.
My next blog entry will be about how to select a project for Agile development from a portfolio of projects. Often when an organisation is just adopting Agile practices they have a broad range of projects to choose from. Without having a coach or mentor to guide them, how should project management select projects that will have a high probability of success? I’ll talk about the characteristics that Agile coaches frequently look for and present a “scorecard” that can help decision making.
If you have comments on this blog I’d appreciate your feedback. You can contract me at Kane at Danube dot Com.
Download the PDF version: Staggered Iterative Waterfall 2 blog