Order out of Chaos

Putting your Product Backlog in order – what should you work on first?

Suppose you’re a Product Owner and you have a few items in your Product Backlog. How would you advise the Development Team on what to start working on first? Should you even care at all? What difference would it make if you were a bit deliberate about the order in which work items get tackled?

The tale of the two leaky barrels

To explore answers to these questions, let’s consider the story of two leaky barrels. Imagine we run a bar and have two troublesome barrels. One holds whisky, the other holds beer. Both are leaking right now, losing us money. Every minute that passes, we loose about $50 worth of whisky and $10 worth of beer.

Based on this information, which one should we fix first? A natural impulse would be to start working on the whiskey barrel. After all, we’re losing five times as much money each minute from it. So far, so good.

Imagine that we resist that temptation briefly enough to get curious about how long it would take to repair the barrels. Let’s further suppose that our investigation turns out that it would take a minute to fix the beer barrel and about ten minutes to fix the whiskey barrel. Armed with this new information, is it still a safe bet to fix the whiskey barrel first? Oops. Not so much anymore.

Sure, in the minute we’d take to fix the beer barrel, we’d lose $50 worth of whiskey. But if we took the ten minutes to fix the whiskey barrel, we’d lose $100 worth of beer. Ouch.

Cost of Delay or Speed to Value?

We can think of the $10/minute beer loss as a cost of delay (see Don Reinertsen’s work). Seen from this perspective, it shows us how much would it cost us if we delay the repair by a minute. However, we can also think of it as a speed to value. In this interpretation, if it took a minute to achieve, we’d get a $50 value saving from the whisky barrel and just $10 from the beer one.

Thinking of it as a speed to value has another benefit. In physics, when we divide speed by time we get acceleration. Therefore, when we divide the speed to value by the duration estimate, we end up with acceleration to value. In our example, $10/minute divided by 1 minute gives us a value of 10, whereas the whisky $50/minute divided by 10 gives us a value of 5. The higher value for the acceleration to value is a simple and reliable indicator that that initiative should be undertaken first. In my experience, thinking of acceleration to value is a lot easier to wrap your mind around than "Cost of Delay Divided by Duration" (or CD3 as it's sometimes referred to).

In this manner, you can develop a cunning practice of ordering your Product Backlog in such a way as to maximise the acceleration to value. Items with the highest acceleration to value would be worked on first.

The Scientific Method to the rescue!

This economic assessment is equivalent to using the scientific method: making a theory, running some experiments, assessing the results, then improving the theory. First, we make a theory of which items are most important to work on – the value model, speed to value and acceleration to value concepts are elements of this theory. Then, we run some experiments by creating items in the order suggested by the theory, and assess the outcomes. Based on the findings, we can then decide to continue to use our theory as-is, or adjust its elements to improve its predictive ability.

It’s conceivable that in some cases dependencies across items may sometimes drag items with smaller accelerations to value closer to the top of the backlog. However it would only happen if it enables the creation of an item with acceleration higher than everything else.

The Quality of Order - What's "good enough"?

The quality of the order of the items in the backlog is driven by the accuracy of the value model used to determine speed to value. The result is further influenced by the accuracy of the effort estimates. Overall, it’s good to remember you don’t need a “perfect” model. You just need something “good enough” to give you a promising order to experiment with. Having a system to create and assess value is far more effective than just random decisions.

The overall intention is to figure out how soon it’s a good idea to stop. Your development team will have a known burn rate.  You’ll want to stop work on this product as soon as the value of the items you’re trying to build is lower than the cost of production over the same duration.

The Lean Leadership mindset

In his excellent Gemba Walks, Jim Womack suggests a Lean Leadership mindset. The Lean Leader will:

1. Embrace the practice of problem-solving by going to the actual place of work, seeing the actual situation, asking great questions about the issues and impediments found, seeking root causes, and showing respect for the lower-level managers and for colleagues at the same organizational level by continuing to ask hard questions until good answers emerge.
2. Understand that no manager at a higher level should attempt to solve a problem at a lower level on their own. Instead, the higher-level manager can assign responsibility to a manager at a lower level to tackle the problem through continuing dialogue, both vertically with the higher-level manager and horizontally with everyone actually touching the process causing the impediment. This is where Communities of Practice may shine (such as the ones fostered by our Agile Transformation Offices in our various organizations and accounts), by providing ready access to the people most closely involved with and familiar with relevant topics. Problems are best solved right where they are found, in conversation with the people that live with them, rather than pondered in abstract in some remote executive suite.
3. Know that all problem-solving is about experimentation, preferably by practicing a plan-do-check-act habit of continuous inspection and adaptation. No-one can know the best answer before experiments are conducted, and the many experiments that fail will yield great learning to be applied for the next rounds of experiments.
4. Appreciate that no problem is ever solved forever. Introducing a promising countermeasure is sure to create other new problems elsewhere in the system. This is not bad - it is to be expected, and it is good, provided that the critical, probing minds of the Leaders keep pursuing continuous improvement.

Delight and Joy - unalienable rights

The Agile Manifesto is an excellent foundation for creating better software development organisations. However, on its own, it lacks a unifying foundation - a means of bringing everyone together, across any organisational boundaries.

Many people still predominantly think in terms of applicability of Agile for specific projects: "Can this project be run using Agile?" or "Would Agile be appropriate for this project?". That kind of attitude slows organisation-wide improvement - it implies that in some areas, the existing ways of work might be "good enough" and therefore exempt from scrutiny and improvement.

The Agile Manifesto, as it currently stands, doesn't directly help people to think in more holistic terms, like: "How may we delight our customers better?", or "How may we best improve our way of work?", despite the fact that agile techniques are very well designed to support improvement.

A few hundred years ago, a nation was born with a proclamation that included the following words:

We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.

In my experience, nothing fundamental has changed in the mean time - we can still safely perceive these truths as self-evident. All of us that work for a living deserve the opportunity to delight our customers and find joy in our work.

Recent research shows that positive emotions play a significant role in achieving success. Consider Shawn Achor's TED Talk: The happy secret to better work, and Barbara Fredrickson's work on positivity.

We all deserve to have ample opportunities to pursue happiness. Since our work lives use up most of our waking hours each week, we had better make sure we can find great joy in our work. Focusing on delighting customers is an excellent and sustainable source of joy and satisfaction in work.

Dan Pink proposes that in our current culture we are primarily motivated by autonomy, mastery and purpose - I find it fascinating how well that parallels with spirit of the Declaration of Independence. Liberty matches autonomy (the freedom to choose our own course of action), mastery matches life (the opportunity to work at improving our skills, minds and bodies), and happiness matches purpose.

I suggest we may find ways of improving upon the Agile Manifesto, quite possibly by harnessing the influence of positive emotions to achieve lasting success in our organisations. What do you think?

Beware greed in retrospectives

Retrospectives are healthy. Retrospectives are vital for improving our work life. Without them, we wouldn't have a systematic way of examining what needs improving and what we might do about it.

Even so, too often I see teams becoming so excited with the 57 things they've just discovered could do with improvement that they want to try them all at once. Beware greed in retrospectives - do your best to pick just one. Search for the most valuable improvement opportunity, design some experiments for countermeasures, and focus on that one improvement. Create a measurement system such that the results can be analysed with as much clarity as possible. Let the data speak.

Only then focus on the next most pressing constraint and repeat the process of root cause analysis, countermeasure design, experimentation and adaptation. We owe it to ourselves to be very reserved with our investments - we only have a very limited capacity for improvement, we should spend it wisely, on the item that we expect will lead to the best improvement.

The Power of an Agile Mindset

Linda Rising gave rousing closing keynote The Power of an Agile Mindset at Agile 2011. She got an impressing standing ovation at the end of the session, and at times there were even a few tears in the audience - a most impressive feat for a rather cerebral audience.

Linda draws our attention to the “agile mindset,” an attitude that equates failure and problems with opportunities for learning, a belief that we can all improve over time, that our abilities are not fixed but evolve with effort.

In contrast, a fixed mindset constrains our ability to change, improve & adapt - it robs us of a joyful future.

Entertain me!...

As Agile Coaches, we often have to find fun ways of inspiring our Teams to learn and gain fresh insights so they may collaborate better.

The Mashmallow Challenge is a very instructive design exercise that encourages teams to experience simple and profound lessons in collaboration, innovation and creativity. The TED video is well worth watching, it's virtually guaranteed to amuse you.

TastyCupcakes.org is another brilliant source of inspiration for various games, including quite a few designed for Agile Teams.

Great Teams are Grown, not Hired

Roy Osherove discusses three maturity stages of a team and adjusting leadership accordingly, along with techniques meant to bring craftsmanship and maturity in a software development team.

Roy argues that Great Teams must be grown - they cannot be hired in whole. Teams must learn how to become great at their work through practice and intense collaboration (just as military units become better by drilling and fighting together).

To grow Teams more effectively, leaders must tailor their leadership approach to the development stage or characteristics of the Team.