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.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

5 thoughts on “An Agile Business Planning Model”
  1. 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?

  2. it definitely does work… [for us]

    2 years down the line and we have a fairly robust engine with various layers of agility, top-down, independantly collaborating- much the same as you’ve drawn out.

    and the success factors are no different to what it takes when implementing agility in dev only. thanks to very open minded executive, along with his willingness to improve and change [sound familiar?] we don’t fight the same ol’ traditional us vs them battles no more 🙂

    but the biggest challenge still remains: getting the synchronization between the different layers to turn at the right time. requires a _lot_ more collaboration [honesty, maturity and courage] across the board.

    also, your values need to be embraced "all over". quite hard when the potential for conflict is increased n-fold. and what do a bunch of whacky geeks know about business anyway? :p

    so maybe that’s why it’s easier to stick to traditional business plans [traditional software] ‘cos it doesn’t require "of" you [in the same way] to engage at the kind of level agility demands? it’s hard work- but oh so worth it! 😀

  3. 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

  4. 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.



Leave a Reply

Your email address will not be published. Required fields are marked *

2 × two =

This site uses Akismet to reduce spam. Learn how your comment data is processed.