Scaling Lean-Agile... Inspired by Mountains

With my new partnership with Dean Leffingwell and the  Scaled Agile Partners, I will be blogging in several new places.

The migration from this blog site, however, was also deeply inspired by the unexpected death of my highly customized Fast Frontier WordPress template.  When I changed hosting services, it shattered into fragments of unreadable code.

I’m settling nicely into my new stand-alone blog site, ScalingLeanAgile.com with a simple site design inspired by mountains.  Stop by.  It’s worth the trip!

Cheers,
Drew
http://drewjemilo.com

Strategic Vision, say hello to Agile

It was in 2008 that I developed a management consulting company’s enterprise Agile methodology to marry their strategic business framework with Agile.

The focus was two-fold. The first was planning: the breakdown of the vision statement — enterprise or product-line focused — to the detailed product, operational, and architectural Stories required to build out the supporting capabilities.

The second was execution: creating the scaling infrastructure to manage hundreds of people working together to deliver on the vision.

I had my own ideas, but also drew heavily from Dean Leffingwell’s book, Scaling Software Agility. We began exchanging ideas through email and before I knew it, a summer had passed and the framework was built. His model, called the Agile Release Train (ART), was comprehensive. My model was simplified for those new to Agile at scale, but the alignment with Dean’s model remained the same: synchronization across the value chain.

What is the Agile Release Train (ART)?

In summarizing the Agile Release Train at a presentation at Agile 2011, I distilled it down to two bullet points:

1. It is a scaling model for enterprise Agile programs
2. It synchronizes the vision, planning, interdependencies, and delivery of many teams on a cadence

The Voice-Over

To understand ART beyond the above bullet points, I recommend Dean’s new book, Agile Software Requirements. You can also read summaries and additional concepts on his blog.

I’ll add a bit more detail: the voice-over I use when explaining the Agile Release Train big picture graphic.

The Agile Enterprise Big Picture (c) 2011 Leffingwell, LLC. (click for more)

The Agile Release Train is not just about the synchronization of multiple teams working together on a complex enterprise software release. It is about the delivery of value. It covers the value chain from business case through release. Its focus isn’t completely “from concept to cash” (Mary and Tom Poppendieck’s immortal phrase) because it doesn’t cover aspects like pricing, sales, and distribution. However, it drives development from top-level enterprise investment themes rather than just lower-level program and team backlogs.

Since the adoption of Agile often begins in a company’s software engineering department, it might neglect enterprise Agile portfolio management, product management, architecture, and operations. The Release Train synchronizes all of these into a cadence which emphasizes the flow of value from high level planning to customer delivery.

Why define a product you can’t build, build a product you can’t test, test a product you can’t release, release a product you can’t support, or support a product your customer’s don’t want?

This is the track upon which the Release Train rides…

Power in Product Management

I find a lot of disagreement in the Agile community over the Product Owner role and how it relates to a Product Manager.  Oh, and you better not mention the Business Analyst.  But that’s a discussion for another day.

I love Roman Pichler’s work, but I disagree with one of his points of view: that a Product Owner is involved in the continuum of product management from the strategic to the tactical.  Why?

It’s expensive.

Product Ownership at Scale

The term “Product Owner” gained rock-star status through Scrum.  It sounds pretty powerful, eh?  No wonder why a Product Manager wants to own the title.

In a large organization, however, a single person who manages both the product strategy and the day-to-day execution isn’t scalable unless you have money to burn.

I recommend to my clients that a Product Owner supports the Story backlog for 1 or 2 Scrum teams.  A Product Manager manages the strategy upon which multiple Product Owners execute.  A Chief Product Manager (or even a Chief Marketing Officer) manages the investments in these strategies.

So Who Owns What?

I appreciate the simplicity of the Epic-Story requirements model.  It works great for simpler products and smaller companies.  However, the model made popular by Dean Leffingwell scales better.

We have Investment Themes which govern our investment in Epics.  Epics break down into Features which then decompose into Stories.

The Epics are the major investments made in a product.  “Add social networking capabilities,” for example.  The Features are the talking points a sales person might use.  “Guess what? Comments on products purchased by your customers can also be posted to their Twitter feeds!”  The User Stories execute those Features.  “As a customer who wants to comment on the product I just purchased, I can add my comments to the website and choose whether it’s published to my Twitter feed.”

Who Makes Which Decisions?

The Chief Product Manager would choose to make the investment in social networking capabilities.  The Product Manager would choose to integrate website comments with Twitter to execute against that investment.  The Product Owner would decide whether it’s worth the Story Points to present a checkbox giving the option to publish to a Twitter feed.

Product Management and the Requirements Breakdown Structure (RBS)

There is empowerment but also visibility into the decisions being made at each level. For that, I recommend Product Scrums twice per week.  I’ll loop back to this type of Scrum in a future blog post.

Scaling the Product Owner role in this manner works for companies who don’t have money to burn.

It’s been a long time since anything fresh has appeared on this blog. I still have 30 or so drafts that I periodically attempt to finish. Unfortunately (for my blog, fortunately for me), I’ve continued moving deeper and deeper into the complexities of enterprise Agile with two $1B companies.

Until I catch up on my old entries, I’ll move forward with a few simple entries on my heroes of enterprise Agility. The first is the man who believes in why even more than I do.

Dean Leffingwell

One stop shopping for scaling Agile

I began an email dialog with Dean in 2009 regarding his published works on Agile requirements at scale. It ran in parallel with my own work developing an Agile requirements model which bridged to the strategic business model of a management consulting company’s framework.

We still have conversations on the topic. But nowhere else does holistic scaling come together than in his new book, Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.

Why I Love Dean’s Work

In a nutshell, Dean started at the strategic enterprise level and worked his way down to executing under Agile.  He’s been the founder and CEO of several companies, Senior VP at Rational Software, Agile enterprise coach, and executive mentor.  His perspective spans the entire enterprise value chain.

I disagree with a few of his concepts, but he always has a logical reason for his points of view.  For example, when I was puzzled by his approach of assigning relative business value at the release objectives level (which is near the top of the value chain) rather than the feature level, he had a clear answer.  A feature doesn’t deliver value.  Deployed software does.

Always Know Why

In my own coaching, I always tell my clients that I first want to talk about why we do things, drawing from Lean principles, the Agile Manifesto, and works on organizational change.  Dean does the same.

Once establishing this baseline, we can adapt what we do and how we do it with the simplest tool of all.

The question why.

Some Like It Hot

In my early ScrumMaster days, I experimented with Sprint Burndown Charts which could be both simple and packed with information.  Whenever my teams were collocated, I used hand-drawn versions on the Scrum Room wall.  Each daily Scrum would end with the ceremonial plotting of the next point on the Burndown.

However, I had a problem with the “classic” format which showed a single line crawling its way down to zero.  The hours remaining showed the hours completed and the hours added (or “discovered”) as a single data point.   I wanted more.

The “Classic” Problem

For those who use hand-drawn Sprint Burndown Charts, the one on the right might look familiar.  In the first few days of the Sprint, the number of hours remaining may bob up and down.

Sure, work is being completed, but other factors are impacting the number of hours remaining.  New tasks may be discovered.  Effort may have been underestimated.  Acceptance criteria may evolve to clarify a requirement or add a bit of “gold plating.”

At a glance, what’s really going on?

The Secret Lies Below the Surface

I decided to plot points below the x-axis whenever hours were added. It didn’t tell you why they were added, but at least it made visible when they were added.

How exactly does this help?  Let’s walk through a Sprint.  The first chart shows what we’ve plotted at the end of the Sprint Planning Meeting.

The second shows day 4.  Hmmm… things were going as expected days 1 – 3, but something happened on the fourth day.  Hours were added.  Anyone looking at the chart knows the obvious question to ask.  What happened?

On day 7, we can see a trend.  Hours are being added almost as quickly as they’re being completed. If we were using the classic Sprint Burndown Chart, we’d see a relatively flat line.

With this Burndown Chart, we know that the Sprint isn’t finished when the line above the x-axis hits zero.  It’s finished when the lines converge.  Do we still have time to respond and complete the Sprint?

In the fourth chart, you’ll see how at any point we can extend the lines and ask ourselves, “What happens if the trend continues?”  As early as possible, we can use our Agile management skills to respond.  Can we scale back on our acceptance criteria and consider a User Story “good enough?”  Can the whole team  “swarm” our bottlenecks?  Should we (gasp) pull a Story entirely?

Regardless, we have better feedback day-by-day and can brainstorm the latest options.

Beyond the Bounding Box

I saw a similar approach applied to the Release Burndown Chart on Mike Cohn’s site, mountaingoatsoftware.com.  The technique is simple and solid.  It helps me think about ways to move beyond the bounding box of the upper right quadrant.