Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Making Waterfall (a Serial Lifecycle) Work For You, Part 3

Written by Johanna Rothman

Monday, 17 December 2007 11:05

In the previous two issues, I suggested some approaches for making a waterfall work for you. If you missed either of those issues, see <part 1> and <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:

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

2. Make sure that 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).

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

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

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

6. 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 reorganize and forge onward.

Johanna Rothman consults, speaks, and writes on managing high- technology product development. She enables managers, teams, and organizations to become more effective by applying her pragmatic approaches to the issues of project management, risk management, and people management. Her most recent book is "Manage it! Your Guide to Modern, Pragmatic Management."

Set as favorite

Bookmark

Email this