Contents:
- This month's Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 1
- Announcements
=-=-=-=-=-
Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 1
If you read my blog, or have heard me speak, you know I'm not a fan of serial lifecycles, such as waterfall. In fact, unless you have a short project, where you know the requirements (and they won't change), and your project team is stable (and won't change), I recommend against a serial lifecycle. But if you work in an organization where your management is firmly wedded to serial lifecycles, you need to make the best of the situation.
First, let me explain what I mean by a serial lifecycle. First the requirements folks define the requirements. After the requirements are “complete,” the architects do their analysis and high level design. Then the developers do their low-level design. After design, the developers start coding. Finally the testers start testing, possibly during development, but more likely during integration or even after integration. (It's possible for testers to design their tests starting after the requirements, but most organizations don't allow the testers to start their work until the coding has started.) After many exhaustive cycles of code-integrate-test, the organization releases the product.
It's all but impossible to obtain feedback about the work that's been done so far until coding has started. (Feedback here, is how the product is working–or not. The feedback is product feedback to the requirements folks, architects, designers, and developers.) And the real feedback doesn't happen until the testers start testing. In organizations that transfer the project from one functional group to the next, it's likely that the testers are the first people to produce feedback to the requirements folks, the architects, the designers, and the developers. That occurs very late in the project.
If you are stuck with a serial lifecycle, consider these early-in-the-project options for making that lifecycle work for you:
- Timebox the requirements work.
I have yet to encounter a project where anyone could know all the requirements at the beginning. So, instead of trying to know all the requirements, work on obtaining the most valuable requirements and defining them so the developers and testers can start. Spend as little time as possible on this step. If you have a 9-month project, spend no more than a month on defining the requirements. Sure, not all the requirements will be defined. But the most valuable requirements–those should be clear.
- Re-estimate at the end of each phase or stage.
When the serial lifecycle was initially defined and refined in the literature, there was a notion of gates or stages. In order to pass through the gate or successfully end the stage, management held a project review. At the management review, the project team (or manager) explained the current progress, including the total money and time spent on the project to date, and the re-estimated amount of money and time projected to successfully conclude the project. (Most of my clients did away with these management reviews in the mid-80's, when it became impossible to predict the end of the project without actually finishing the project.)
Even if you don't have management reviews, you can still re-estimate your projects as you proceed. You do know more about this project now, even if you still don't know when you'll be done. The project team will realize more about what they do and don't know about the project. They are more likely to break the remaining tasks into smaller chunks, which will allow them to make better estimates.
- Use prototypes wherever possible.
One of the big risks in a serial lifecycle is that the architecture (or the GUI design) ends up being not quite right for the product or the users as the requirements evolve.
One answer is to restrict changes to the requirements, but that leads to the problem of “You built what I asked for, but not what I needed.” (I've met very few projects that could restrict requirements changes. Too often those requirements changes affect the architecture.)
Another alternative is to build prototypes of the architecture (or the GUI), or whatever risky area of the product you might need to explore. The way I suggest you build architectural prototypes is to fully implement several features, but not all the architecture. If you implement several features, implementing just what you need to make this feature or that one work, you will have holes in the overall architecture and design. That's ok. Your goal here is to gain feedback on the architecture, not to implement the whole darn thing.
For the GUI, consider paper prototypes, which take much less time to develop than any electronic prototype. You'll learn about what needs to change in the workflow as soon as someone uses the prototype. Once the workflow seems stable, it's reasonable to develop some electronic prototypes, to test the rest of the GUI.
I'll have more tips for the middle of the project in my next Pragmatic Manager.
=-=-=-=-=-
Announcements:
Drum roll please: My most recent book, Manage It! Your Guide to Modern, Pragmatic Management is available. The early reviews are excellent. See the page at Pragmatic Bookshelf, or here for more reviews, some excerpts, and the templates from the book. If you review the book on your blog, let me know so I can point other people to your review.
I'm one of the hosts and session leaders for the next AYE conference November 4-7, 2007 in Phoenix. See the AYE site for more details. The other hosts and I delve into a specific area in detail, exploring that area of personal, team, or organizational effectiveness in depth. (I have a new simulation for my multitasking session.) We have a diverse group of participants this year, and I hope you decide to join us. Email me for more details or to be added to our mailing list.
As always, take a look at my blogs to see my most recent writing: Managing Product Development and Hiring Technical People.
Thanks for reading, and please do send me your comments.
Johanna
© 2007 Johanna Rothman
If you'd like some common sense, down-to-earth ideas about how to manage your projects, manage your people, or manage your individual work, you've come to the right place.
See back issues of my email newsletter here.
Tell me how you've used these ideas. Or, if you have questions, comments, or feedback, tell me that too.