It’s great to move to a model where we can adapt and learn as we develop software. Instead of trying to specify everything up front for the next years work. In making this transition, it’s important not to swing to the opposite end of the spectrum and suffer the consequences of under commitment.
Fortunately, projects are a great way to organize commitment in the short term. A project spans multiple iterations, over a period of several months, long enough to achieve a greater purpose than can be accomplished in a two week iteration. A purpose that can align with business objectives. And a duration sufficient to accomplish the objectives.
Projects offer a method to structure commitment to a unique, temporary endeavor. There’s nothing temporary about a multi year effort. Nor is there enough time in a two week sprint to make the commitments necessary to avoid wandering aimlessly week by week, waiting to see what happens.
That said, back to back projects can be problematic. By back to back, I mean finishing a project one week and starting on the next project the following week. Especially if the projects are iterations on the same overall system or are related in some way.
When this happens, project commitments will leak into subsequent projects and the commitments will waver. With back to back projects, there’s less impetus to wrap up a project if you can continue to work on it during the next. As project lines blur, organization has a tendency to devolve into on going, run on development.
The best way to avoid blurring project boundaries is to put some space between projects. By space I mean taking a break, both mentally and physically. The more related the projects, the more space necessary. But even unrelated projects would benefit from a break.
I’d recommend at least a week between unrelated projects and several for related projects. There’s always plenty of work that can be done in this time. If anything, invest it in learning and effectiveness. Reflect on what went well and what didn’t.
Doing something completely unrelated between projects gives everyone’s mind a chance to stop the rat race of daily work. It gives our minds a chance to reset. Our biases will fade. Our narrow focus will broaden.
Breaks encourage us to wrap up commitments within a project and not let them bleed into the next. If we put distinct boundaries between projects, we’ll define much more focused commitments. During the break, don’t allow any work on the project. If the project isn’t done, finish it.
Done means valuable, working software that fulfills the objectives entirely. It doesn’t mean software waiting to be deployed. It doesn’t mean recently deployed, untested software. It means nothing left to do to consider the project a success.
By prohibiting work between projects, we’ll develop the habit of actually finishing projects and fulfilling our commitments. And when we’re ready to start the next project, we’ll have the mental clarity to carefully craft a worthwhile commitment that we can believe in achieving.