Keeping It Agile

A truly agile project will produce lots of short software releases, unleashing them on the world in quick succession (with each release lasting anywhere from a week up to a month or two^[2.]). If we end each release with a design review, then the design is reined in before it has a chance to get out of control.

The design review is actually a code and design review, because we also compare the code with the design (once the design has been reviewed) and bring the code back in sync with the design.

Tip 

Bringing the model and the source code back in sync is an important Agile ICONIX practice. We need the model and the source code to be tightly coupled so we can reuse these diagrams for the next release. In other words, we’re going to drive the code from the model, so we’d better have the model in good shape.

This also works the other way: when we review the code, it will probably remind us why the design followed a particular route. So this prevents us from taking the design in a direction that just isn’t going to work with our chosen solution.

The first design review (between release 1 and release 2) is also the most important. It gives us a chance to radically alter the design if need be, before so much code has been written that it would be prohibitively expensive to make such sweeping design changes. In this chapter, we pay very careful attention to reviewing the mapplet design as we prepare for release 2.

^[2.]Our preference is for a 1- or 2-month release cycle (3 months as an absolute maximum). Anything less than 1 month creates too much admin overhead, and anything longer than 2 months greatly increases the risk of delivering something the customer wasn’t expecting. (We discuss this idea further in the “Chapter 4.)