In IT, for years now, we’ve been debating and arguing for changes in the way in which we write software.  Clearly, models where all requirements come before all design, and all design comes before all code, is just not realistic.  That model doesn’t reflect the dynamic nature of modern business.  (if you want to argue with me on this point, get your own blog).

So why are things so slow to change?  I think because many corporate leaders PLAN in a waterfall model.  That makes sense.  It takes time for an organization to react, so their form of change control is to create change slowly.  So strategy meetings only produce big public announcements on an annual basis.  That keeps the organization from thrashing, and keeps them focused on the plan in place.  Of course, in executive planning circles, there are many strategies that have been suggested… not all of them are announced.  Why is that?

For the same reason as you would have all your requirements in a backlog, but you only release to the development team the subset of requirements that they can accomplish in a single sprint.  Stability.  The dev team appreciates the control they have by taking on only a subset of requirements for each sprint.  In return, they demonstrate value on every sprint. 

Unfortunately, executive planning is pretty conservative when it comes to this.  Rather than letting the organization see the entire queue, and letting them decide what to take on, planning committees usually just pick the requirements that “should” get done, and then dump them on the organization and say “make it so.”  They have an arbitrary date (one year hence) to make it happen.

Look at that for a moment.  Seem familiar?

Requirements from above.  Arbitrary deadlines.  The team doesn’t get to see the entire list of requirements.  They are told what to do, when to do it, and given a fixed budget to do it with. 

Sounds like waterfall software development.

Looks something like this.

Waterfall Planning Model


Unfortunately, this idea is just as ineffective in business as it is in IT.  It is time that we, in IT, take our ideas of Agility, and share them with our friends in the business side.  This is happening in some very agile corporations, including Microsoft, but not in enough places.  We, in IT, can help share this notion. 

The real key to making this work is the Prioritized Queue.  Just as an agile model allows developers to see the most important things that need to be done, and THEY can choose what they will deliver in a cycle or sprint, this model needs to work itself all the way up the chain.  Executive Management doesn’t have to participate.  They probably won’t.  But everyone else should, especially as it comes to planning for changes in the IT side.

The think to keep in mind about this model is this: At each level, work is iterative and continuous.  EACH LEVEL IS A SPRINT TEAM.

At each level, the work is continuous.  Development is continuous.  Requirments Gathering is Continuous.  Planning is Continuous.

Here’s the new model.  Click the image to see it full size.

Thumbnail image of agile process


One big advantage for us: if we get to this model as a normal form of business, then a lot of the “waterfall pain” we feel in IT goes away.  Something to think about.