Kane Mar

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.]

Read the rest of this entry »

Foreword: This blog entry was originally intended to be a single article. In writing it I found that I had trouble trying to communicate all the information in one sitting. As a result I’ve decided that this will be a 2 part article. The first part (presented here) discuss the Iterative Waterfall pattern and the reasons why this pattern of software development process is detrimental. In the second part I’ll discuss possible approaches to moving away from this pattern.

Update: Dave Nicolette has written a great article that provides more context, from the both organizational and team point of view. It’s well worth reading and you can find it here.

Over the last 3 years I’ve noticed a reoccuring anti-pattern amongst companies trying to implement Agile. This has happened with development teams that are particularly experienced with RUP [for reasons that I'll discuss towards the end of this article].

There are two variations of this anti-pattern, which I’ve called Iterative Waterfall and Staggered Iterative Waterfall. The Staggered Iterative Waterfall anti-pattern is simply the Iterative Waterfall anti-pattern taken to it’s extreme. Throughout this article I’ve used the term Iterative Waterfall to refer to both variations except in situations where I need to distriguish between the two.

So, what are the characteristics of these anti-patterns?

Read the rest of this entry »