Decreasing Project Completion Time, Part 2

Feature Article: Decreasing Project Completion Time, Part 2

Last month, I discussed techniques to decrease project startup time. Now it's time to look at practices that can decrease project completion time once you've started the project.

1. Ask the developers to unit test their code. There are free unit test development tools for Java, C, C++, and other languages. (sourceforge.net has pointers to unit test tools.) When developers unit test their code, they produce fewer defects along with the features. Fewer defects means the builds and follow-on testing complete faster, enabling you to release as a business decision, not just when the testing is finally done, or the pressure to release is too high to withstand.
2. Build and smoke test frequently. If you're not already building every night, move towards nightly builds. If you do build every night, determine if morning/afternoon or hourly builds would help others assess the software faster or help you make better release decisions. If you've architected the product for frequent building, you can allow developers to work in parallel, verifying their modules without delays.
3. Make sure your automated smoke tests are automated and small. If you don't have automated smoke tests, write some. (Smoke tests verify a build is usable — that's it.) If your smoke tests require human intervention, they're not automated. The ability to release at any time depends on your ability to know if the build is usable by others and good enough for more system-level testing. Passing the smoke tests tells you if it's worth assigning the testers to test the build.
4. Create space in your configuration management system for developers to prototype. Developers need to prototype their designs, to see what works and what doesn't. You want developers to check in their work whenever they're ready, so make space in the configuration management system. Consider a multi-tiered checkin system with labels such as these: prototype, done, module-checked, and build-checked. As developers prototype and evolve their thinking, they use the label “prototype.” When the developers think the product is ready, they check it in as “done.” After the module build and smoke test, the file is labeled “module-checked.” Once the build is smoke-tested, the file is labeled “build-checked.” The project manager can tell more about the state of the software when you use multiple labels in the configuration management system.
5. Start testing before developers write the code. If you're not already using test-driven development consider how you can adapt the ideas behind test-driven development to your environment. One technique is to test designs before any code exists. One of my favorite techniques is to ask “What three things can go wrong with this design?” or “Under which conditions won't this design work?”
6. Start testing as soon as you have code. Create tests (unit tests, integration tests, system tests) that are small and adaptable, so that you can start testing as soon as any code exists. You'll still need whole-system tests, and some of them may be large and time-consuming, but the more flexible your tests are, the faster the feedback you'll receive from testing, providing more value.
7. Use a risk-based approach to testing the entire product. Many organizations test everything for each build. If you know what's changed, you can test that, plus some other high risk areas after every build. If the testers aren't repeating the same tests over and over ad nauseum, they're more likely to observe strange behaviors and perform more exploratory testing.
8. Create and use release criteria so the project doesn't lag on, waiting for someone to notice it's complete. Release criteria are the vital few cross-functional issues that the release needs to fulfill. Make the criteria specific to this release, measurable by the project team, attainable for the project team, relevant to the product and customers, and trackable so the project manager can assess progress.

These practices reduce the time to complete the project. If you're not using these practices, ask yourself what's preventing you from doing so. If you are using these practices and you still can't release when you want to, determine what else is standing in your way and fix it.

Choosing a release frequency is much easier when you can release at any time. Make the long start-up and completion durations a relic of the past.

All contents © 2004 Johanna Rothman.