An Agile Business Planning Model

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.

 

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.

 

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.

Comments

• Anonymous
  March 08, 2007
  Looks good.  Sounds good. (I have my own blog, I'll write it up later) The only shortcoming I see is that the higher up the hierarchy, the faster they'll be able to sprint out ahead of the lower echelons.  Higher == more abstract == less wind resistance.  Ultimately the further down the hierarchy, the larger the backlog.  This could likely lead to impatience due to a misperception of lack of progress, thus bringing the whole process full-circle resulting in something similar to the first graphic.  (History has taught that there's a gap between "business" mentality and "technical" mentality that needs managed.) I don't disagree with it in concept, and I'd love to see it in practice.  Perhaps another interesting question is: How would this scale to the Thomas Friedman flat organizations, or SMBs?

• Anonymous
  March 08, 2007
  The comment has been removed

• Anonymous
  March 09, 2007
  Great diagram. I really like the breakdown.

• Anonymous
  March 21, 2007
  Companies require business agilityCompanies require business agility to survive; software requires agile development procedures to respond to change; development requires agile business rules to allow change; and the enterprise requires agile business

• Anonymous
  April 11, 2007
  Hi, Yes, this does work. This is Nick's agile take on general principles of "relationship managers" from IT implementing demand management. A continous cycle of requirements gathering, refinement, scoping, implementation. Anyway, I have been doing a version of what Nick suggested since July last year with fantastic results. Executive sponsorship is absolutely key in this. Cheers Bob