[First, previous, next in series]

This is the second of nine articles in a series exploring the matrix below (introduced here):

Previously we looked at Needs; today we’re moving down one cell to Outcomes.

Alignment on outcomes – aligning the outcomes of the delivery process with those of experienced by the user and customer – has several things in common with Discovery of needs:

1. It seems obvious – “yes of course we should make a deliberate effort to understand rather than assume needs, and of course their success is our success!”
2. It is rarely practised well, and often practiced not at all, seen as “too hard”
3. It is genuinely hard if certain things aren’t in place, but is easy and natural when they are

The closest many organisations get to aligning the outcomes of the delivery process with those of the customer is when they use a business case to justify each piece of work. Consider that carefully: their “best practice” is to ask via a business case (sic) whether the project in question will deliver good outcomes to their customers, some months down the line. A conversation removed from the customer in perspective, in space, and in time. Oops.

What’s needed are conversations with real customers that happen close in time to the realisation of their outcomes. Two prerequisites then: some kind of collaboration with the customer, and the opportunity to realign before, during, and – crucially –  after the work is done. Closing a feedback loop.

This is easy and natural when work is delivered incrementally (as opposed to in huge batches) and there is opportunity for customer engagement during the delivery process. This is easier and more natural still when there is an expectation from the customer side that it will happen. Cultivate that if you can!

To finish I will illustrate with a story, an excerpt from my book, Kanban from the Inside. It’s from Chapter 4, which explores customer focus, one of the nine values of the Kanban Method and the fourth category in the Agendashift values-based delivery assessment.

Satisfaction Assured

Recall this policy from the scenario that opened Chapter 1 [Transparency]:

• Developers retain responsibility for work items until they have obtained customer confirmation that the item is proving its worth

This policy was a relatively late addition. We had evolved a development process that seemed effective enough. We’d gather requirements, build new features, test them, and release them. After a while, we got a little more sophisticated: We added a column on our board that let us track features that were released but still required further implementation steps before they could be considered complete.

Too often, though, when we checked, we found that we’d delivered features that would never be used. Features that had been asked for! How does that happen?

Our new policy was added to address what we assumed at the time to be bad customer behavior. Why ask for stuff you don’t need? How about letting us know when you change your mind? However, it soon became apparent that this new policy was changing behavior on both sides. Closing a feedback loop was the catalyst for a level of customer collaboration (a value straight out of the Agile Manifesto) not previously seen.

Knowing that the process was going to end in what could turn out to be a difficult conversation, developers and our internal customers alike made sure to nail those final implementation steps (clarifying timetables, keeping people suitably informed and trained, getting static data cleaned up, and so on). When necessary, these steps would be tested beforehand, often collaboratively. That, in turn, influenced the way development and specification was done. All the way back at the start of the process, it changed even the way work got prioritized, now that it was apparent that success depended on shared commitment.

I’m not exaggerating when I say that the impact of this policy change went way beyond my expectations. Some humility is in order too: We didn’t have bad customers, just relationships that weren’t effective enough.

Blog: Monthly roundups | Classic posts
Links: Home | Partner programme | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter