Enterprise Agility–The Big Picture

(Note: The Big Picture graphic below has been revised during this series of posts. I try to keep the latest version here so you may see some differences if you follow the series from front to back).

I spend a fair amount of time working with executives trying to give them the “big picture” of what their software organization, requirements, process and delivery model would look like after they adopt enterprise agility and implement the Agile Release Train (Chapter 18 of Scaling Software Agility). My thinking is that if I can paint the “after” picture in their minds without spending all day at it, then it will be easier to for them to understand the types of work they need to do to achieve it.

For some time, I’ve struggled to come up with a graphic that communicates the high-level model of enterprise agility as simply as the waterfall graphic communicated its stage-sequenced model. I’ve made a number of attempts at it, including a few in the book, but I don’t feel that I ever really captured the essence in a single graphic. (Though I’m a writer at times, I’m a far more visual learner).

Recently,  I worked with Matthew Balchin and Richard Collins at Symbian Software Ltd. , ( and later, with Juha-Markus Aalto of Nokia, Nov-Jan 2009) to build a “single slide” big picture that we could use in a number of presentation contexts. Here is a modified result.


The Big Picture (updated Mar 2009)

I tested an earlier version of this graphic recently with a group of software executives contemplating an agile transformation. We spent a solid hour just discussing the graphic. It seemed pretty effective in helping them understand the intended result, with far fewer words and slides.

Since it seemed to work but it’s not quite self explanatory, I will annotate it extensively in some upcoming posts in the hope that it might help others struggling with the same communication challenge.

7 thoughts on “Enterprise Agility–The Big Picture

  1. The picture does a great job of really articulating the general flow of an agile release train effort. The one area you may want to consider treating differently if the context warrants it is the definition of vision above the detail line.

    We leverage epics at the release level. An epic can span iterations but not releases. This allows us to group a series of stories across several iterations within a single release. This allows us to establish commitments at the release level during release planning. Teams then have autonomy to adjust stories within the release without breaking the “spirit” of the epic commitment.

    We then use release objectives / features to track our vision and roadmap beyond a single release. A release becomes one piece of the roadmap which consists of a series of plan of intents (POIs) and one and only one plan of record (POR). This part is a less “formal” reason for doing what we do. The key part is the epic piece I mentioned above. We even took it a step further – every epic is tagged as internal impacting or external impacting. If it’s internal, it’s something only development manages. If it’s external, we involve the entire release change control process inherit in the entire company from past waterfall execution. Again – autonomy while playing nice 😉

    At the end of the day, it’s all the same – an epic is a larger grained story and that’s what counts. For us, it was a way to build autonomy and separation from a preexisting structure that wasn’t inherently agile.

    Great picture – I can easily see how it would create a great conversation. Wish I could have been a fly on the wall that day!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s