Thinking for a Change

A potential new bottleneck

Last week we noticed that some of our users didn’t know some features were available or were unsure how to use the new features in the previous release. So, we spent some time explaining some of the features.

This is a timely warning: our ability to effectively transition the software into production use could become a bottleneck. This is both a good and a bad thing:

• It means that our bottleneck, the development team, has been elevated to a level that’s nearer the capacity of the users to accept new features. This is good: our efforts to elevate the constraint are starting to work.
• Our capacity to train users and the user’s capacity to accept new features might become the new bottleneck. This is bad news: we don’t want the bottleneck to get out of our control.

This is a typical pattern for agile processes: the development team is elevated and after a while the customer, who subordinates to the development team (as the XP customer does), becomes the bottleneck. Suddenly, the customer can’t write stories fast enough to keep the team occupied; releases are implemented so quickly that the users can’t keep up with the flood of new features.

What to do?

Before the users become the new bottleneck, we need to take measures to elevate them so that the bottleneck doesn’t shift. What are we going to do?

• We have regular meetings with our key users who follow up new developments. We need to make these more “hands on”: show the users how new features work, let them experiment some more.
• Training and transition to a new release is handled by people in the users’ organisation. We can support them more during final acceptance testing and transition to the new release.
• We can hold an “end of sprint demo”, like Scrum prescribes to show the new features (and how they’re to be used) to a wider audience than the key users.
• Each release is focused on one group of users. For example, the current release contains mostly features for the commercial people. They will need some training to use the new release. Other groups will see only a few minor changes, so that for them the application doesn’t change too much.

Release less often?
Some have suggested that the problem is caused by us releasing too often. We release every two months. Should we release less often? I don’t think so: we used to release every 6 months and that caused big acceptance, transition and training problems. In comparison, today’s problems are insignificant.

I would suggest to release more often, establish a regular rhythm of changes. Have each release contain fewer changes, changes that appear shortly after the users ask for them and they’re fresh in their mind. Get a regular rhythm going on the “drum“, increase the “takt time”, level the load to reduce the waste due to unevenness.

Making change routine

People don’t like to change. They like routine and predictability. How can we make change easier? Regular “Kaizen” events, regular retrospectives to steer the process establish a rhythm of change. If you review and improve your process each month, every month, people become accustomed to the change.

If you want to change the routine, make change routine

The project burn up/down chart

Our team has a very public burn up/down chart. This is where we stand today.

A short reminder:

• The red line tracks the burndown of estimated story work to do
• The green line tracks the delivery of estimated story value

What happened in the past two weeks?

Two weeks ago, both graphs went sharply up/down. The value chart a bit steeper than the cost chart, because we work on the highest value stories in the beginning of the project

Last week the chart was flat. No story completed this week. Oooops….

Why?

• One story counted two weeks ago turned out to be incomplete. Added some more tests to make the problem apparent, completed the implementation. No extra points, as they were already counted. If we hadn’t completed the story before the end of the week, we would have subtracted the effort and value.
• We’re all working on big, 4-5 point stories. When these complete we’ll have another big jump on the chart. That’s another disadvantage of big stories, they don’t help us level the load and they make tracking less smooth. Maybe we’re in trouble, but we won’t see quickly. We’ll only know next week, when these stories are expected to finish.
• Some of our users seem to be unclear on what new features are available and how to use them, so we spent some time explaining how the application works.

Lessons learned:

• Spend more time on tests, especially acceptance tests
• How could we have broken down these stories in 2-3 point parts?
• User acceptance of new features could become a bottleneck. Read more….

Big VISIBLE chart

People passing by and looking at the chart came up to me and asked “Hey, what’s wrong? Your graph is flat.“. Now that is instant visibility into the state of the project. Passers-by know at a glance when we’re doing well or badly.

Not bad for a tool that cost almost nothing and takes 10 minutes a week to update…