Contents:
- This month's Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 3
- Announcements
=-=-=-=-=-
Feature Article: Making Waterfall (a Serial Lifecycle) Work For You, Part 3
In the previous two issues, I suggested some approaches for making a waterfall work for you. If you missed either of those issues, see Waterfall Part 1 and Waterfall Part 2.
Now you're at the end of the project–or you'd like to be. One of the problems with a serial lifecycle is that the project team doesn't receive feedback early in the project about how they are implementing and testing the features. At least now, the team is receiving feedback. If you doubt that this project will ever end, try some of these possibilities:
- If the team hasn't been implementing by feature, have them finish their work by feature, or by scenario. Each system has some common workflows. Break those workflows (or scenarios) into small feature-like chunks, and make sure the developers complete each small chunk, working with the testers to test as they finish developing.
-
Make sure developers don't check in code without some sort of code review.
If you're struggling to finish a project, the cheapest and fastest way to finish is to make sure the developers check in clean code. Code review will accomplish that. Offer all the possible techniques to your team. They will choose one that doesn't take a lot of time and provides feedback (because they want to finish the project too).
- Integrate the code continuously.
Yes, I know I said this last month. But it's even more important at the end of the project when the pressure to release is high and mounting.
I hope your builds are fast and that you have smoke tests to know if the system works at all. If not, consider deferring some features so you can divert people to the build infrastructure.
- Ask the testers to plan and use a project dashboard to test the most valuable parts of the system each day and report daily and weekly.
Some testers think they need to start testing at the “beginning” every time they receive a new build. If they use a test dashboard, organized by value, everyone will see what they have planned to do on a given day and during a given week. The testers aren't interrupted with new builds; they remain on their planned testing course.
Note: this doesn't work if your project changes everything on every build. If your team changes the database and the data is changed for every build, the testers will have to start all over again. If the code is redesigned (the internal contract changes) with every build, the testers can't count on enough stability to go forward.
If you're a project manager, look at what's changing and what's not, before you try testing-from-where-you-are-rather-than-the-beginning. And if everything is still changing at the end, you have a bigger problem than the testing. The testing is just making that problem obvious.
- Develop and use exit criteria.
One of the problems with a serial lifecycle is that the project just doesn't turn out the way everyone had hoped. One way to obtain agreement on when you want to release is to have release criteria, exit criteria for the project. Exit criteria are not all the requirements; they are the vital few characteristics of the project that must be met for project success.
Use these steps for defining and using release criteria:
A. Define what's important for this release so you can monitor release criteria throughout the project.
B. Draft release criteria.
C. Make release criteria SMART: Specific, Measurable, Attainable, Relevant, and Trackable.
D. Gain agreement from the project team and senior management.
- Timebox all activities with one-week timeboxes.
Timeboxes focus everyone's attention on what they have to accomplish this week. When you're at the end of a serial lifecycle project, it's even more important not to let the project slip a week every week. Timeboxing asks people to commit to certain work for a short time, and accomplish that work. If too many people are working on too many disparate items, you'll know within the first week–which gives you plenty of time to reorganization and forge onward.
=-=-=-=-=-
Announcements:
The next AYE conference is November 4-7, 2007 in Phoenix. See <http://www.ayeconference.com> for more details. I hope you decide to join us. Email me for more details or to be added to our mailing list. If you'd like to sign up directly for our email list, go to <http://www.ayeconference.com/signup.cgi>.
I've changed my blog feeds (and appearance). Please do a take a look:
Managing Product Development
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.