Agility is often thought of in terms of “fixing” the ills of the sequential, step-wise, plan-driven methods that have come to be known as “Waterfall”. So the question begs, just what is wrong with waterfall?
The short answer is nothing is wrong with waterfall methods. We’ve all done good work using these methods and I expect that we will all do more good work with them as well.
Let’s look a little deeper though. In his book Agile & Iterative Development; A Manager’s Guide, Craig Larman describes two broad categories of projects:
Predictive- You can define all the work for the project upfront, put a plan and schedule together to do that work, and then execute that plan with reasonable confidence that things won’t change much beyond the normal rigors of running a project.
Inventive- The project has a high degree of uncertainty and change and you cannot derive estimates or schedules from previous similar projects. As work on the project is completed, you learn more about what is required and the resources and effort needed to deliver it and adjust accordingly.
Waterfall techniques address predictive projects very well. Because the work is well-known is it possible to set the correct path for the project and then use traditional waterfall methods to maintain that path. That is what these techniques are all about. Change is acceptable but only after some rigorous validation that it is the best thing for the project.
Agility on the other hand is best suited for inventive projects. Because the work required is not well-known, these techniques focus on the expected business value. Change is not only acceptable, it is expected as we learn more about the business objectives and the work required to achieve them. As a result these methods readily adapt to change in a receptive, but disciplined manner.
So while there is nothing wrong with waterfall methods, what is wrongis mis-applying them to an inventive project.
As professional project managers we have an obligation to recognize (and help our stakeholders recognize) where our project falls in the predictive-inventive spectrum and adopt the project management methods that offer us the best chance for success.
Waterfall and Agility are both valuable toolsets. Every project manager should have both in his or her tool belt and know when and how to use them.
Recorded at the Agile 2007 Conference, this video presents Mike Cohn offering his thoughts, wisdom and as always, his unique and engaging view on transitioning to agile practices.
As a developer, analyst, and designer I have seen the rise of patterns that recognize common behaviors and advance learning of the craft. I was therefore curious about this book; Fearless Change, Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising. Then after meeting Linda at a recent conference I was hooked and bought the book.
The authors immediately begin talking about a pattern language that focuses on the Change Agent, the Culture and the People of the organization in which change in being introduced. The pattern names themselves allow us to speak and be understood in this language. For instance:
As an Evangelist I want to introduce iterative development by proceeding Step By Stepto Test the Waterswhile taking Take for Reflectionand focusing on Small Successes.
Without knowing the particulars of these patterns we still have a good sense of what course we want to take. The actual pattern definitions then speak to the actions and motivations we should consider as we move forward.
Fearless Change is full of common sense information that can give us a great structure in which to shape our change initiatives. I haven’t tried it yet, but I am pretty confident that as we become associated with new organizational change efforts, we can use the sequence of patterns that Mary Lynn and Linda suggest to assess where the organization is at and determine what our next steps should be.
This is a very insightful book I would highly recommend to anyone wanting to understand how to successfully introduce and adopt organizational changes.
Consider these four statements about software development requirements:
♦ You can discover all the requirements upfront.
♦ You can minimize requirements changes early in the development cycle.
♦ Once you select a set of requirements you can precisely estimate the effort to deliver them.
♦ The fact that a requirement has been defined is an indication that the requirement will be delivered.
Are these statements true or false? How you answer that might be a good indication of the project management methods best suited for your project.
If you think that these four statements of mostly true, then a traditional, step-wise, plan-driven (read “waterfall”) method is likely appropriate and has as much chance of succeeding as anything else. On the other hand, if you think these statements are mostly false, then that same plan-driven approach is likely to be problematic. Instead a more agile approach that re-evaluates requirements at iteration boundaries has a much better chance of success.
An agile approach embraces the notion that we don’t know everything upfront. Changes in requirements are not only expected, they are often seen as a good thing. They keep us on a path that is delivering value. Developing software should not be about delivering some fixed set of features by the desired date. Developing software should be about making the business bigger, better or more efficient. It’s alright that we don’t know all the details about just how to do that upfront. Agile methods let us start with something we know and build on to that based on what we learn along the way. Frequent feedback validates the work we have done, identifies changes that could make that work better, and discovers new ideas that couldn’t be seen before. Managing this level uncertainty and change is uncomfortable to traditionally trained project managers, but doing so provides our best chance for success.
Successful businesses are not static; they constantly evolve as they adjust to changes in their market, the activities of their competitors, fluctuations in the economy and many, many other things. We should not think that we have a static playing field when developing software in these business environments.
In The Software Project Manager’s Bridge to Agility, co-authors Michele Sliger and Stacia Broderick do a great job of making agility more accessible to traditionally trained project managers. Both PMPs and CSTs, Michele and Stacia have solid roots in both the traditional and agile worlds that serve as the foundation of this work. They ably provide great review of the nine PMBOK® knowledge areas and how they correlate to agile processes. While some in the agile community might say “so what”, I think the effort to engage traditional project managers can only advance the adoption of agility.
I found this to be a particularly fascinating book that delivers on its premise that artists have something to say to business. Although an unusual pairing of authors, Harvard Business School Professor Ron Austin and Theatre Professor Lee Devin collaborate very well to make their case. This book is not about agility, nor project management but offers significant insight into the leadership model for agile teams.
Agility is often thought of in terms of “fixing” the ills of the sequential, step-wise, plan-driven methods that have come to be known as “Waterfall”. So the question begs, just what is wrong with waterfall?
Subscribe
