What Happened to the Beautiful Plans? (They Became Experiments)

Tim, a senior manager, loved seeing plans for work and roadmaps. Then, the organization decided to Embrace, Not Manage Change. Tim wasn't sure how to track the work.

This image helps me frame the need for an agile approach. (See the blog series: Where I Think “Agile” is Headed, Part 1: Do You Need an Agile Approach?) The less discovery you need, the less you need an agile approach. The more discover you need, the more you need an agile approach to succeed.

Tim managed the IT and the Engineering departments. The IT department managed the internal applications and the infrastructure for the company. The Engineering department solved problems for three different markets. One market served their original “bread-and-butter” clients. The other two markets were new to Tim's organization.

The market for the original clients was in the midst of disruptive change. Everything was new about that market. Tim's company could no longer make assumptions about the customers and the customers' problems. That meant the product people and the teams had to run small experiments. They couldn't anticipate much more than two to three weeks ahead.

The new-to-the-company markets were more settled. Those teams had a look-ahead of a couple of months.

Different Problems Require Different Plans and Experiments

Because the markets were different, the teams planned, managed risks, and create experiments differently.

The IT department mostly had delivery risks. They had very few discovery risks. They often called their work, “rinse and repeat.” The IT teams worked on the left side of the continuum.
The Engineering teams who worked on the new-to-the-company markets were in the middle of the continuum.
The Engineering teams who served the market in disruptive change were on the very right of the continuum.

That meant Tim never received solid plans for the work he was most nervous about—the teams on the right and the teams in the middle. Tim was a smart cookie. He knew that asking for plans meant he would slow down the teams who needed to work as closely as possible with the customers.

Tim, as a senior manager, had these concerns:

He wanted to make sure they could capitalize the software efforts as early as possible.
He wanted to make sure the market in disruptive change was still a market the company wanted to pursue.
He wanted to manage expenses.

Back in the more predictable days, he would have asked for detailed plans and roadmaps. He could still ask IT for more detailed planning because they had risks only in delivery. However, he knew it didn't make sense to ask the Engineering teams for the same level of planning.

See Progress Differently for Experiments and Plans

He tried asking for this information instead:

What did the teams learn from their experiments every week? In particular, what options could they now rule out?
Asked for the product backlog burnup and feature burnup charts (as in Velocity is Not Acceleration).
Asked when the teams thought they were close to having more delivery risk as opposed to discovery. At that time, the teams could create more solid roadmaps and plans to complete the work.

Because Tim asked for that data, the teams on the right side of the continuum worked in these ways:

The product people created MVEs and MVPs to finish the smallest valuable work. That smallness meant the teams could then refine or create new experiments. (See Consider Product Options with Minimum Outcomes for definitions.)
As soon as the team had something small checked in, they demonstrated the finished work to anyone who would watch the demo.
The teams kept their WIP (Work in Progress) to one or two items at a time. The teams also used continuous integration and continuous delivery inside the organization.

After several months, the market in disruption settled down. However, because everyone became accustomed to small planning and small delivery, they used these approaches for all the projects they could.

The IT group iterated on their requirements and designs at the start of their projects. When it came to delivery, they worked hard to see how to make shorter projects with more frequent deliveries. They didn't think they needed a strictly agile approach. However, their approach was much more adaptable.

One type of project planning does not fit all the projects in your company. You, as Tim discovered, might find that there is not much need for beautiful plans. Instead, small experiments with customer-centric outcomes might be precisely what you do need.

Learn with Johanna

I'd hoped to have more online workshops to announce, but not yet!

My online workshops with Esther Derby are at Your Management Mentors. The first workshop is Make the Most of Your One-on-Ones.
My online workshops with Mark Kilby are at Distributed Agile Success. The first workshop is Prepare for Successful Distributed Agile Teams.

Create Your Successful Agile Project is now available in audio, wherever you buy audiobooks.

I'm still in technical review for the Modern Management Made Easy books. If you like buying books in progress, please do pick them up. If you prefer to read completed books, please wait!

New to the Pragmatic Manager?

Are you new to the Pragmatic Manager newsletter? See previous issues.

Here are links you might find useful:

Till next time,

Johanna