Why are there no product owners in Kanban?

Or perhaps the better question would be: Are there no product owners in the Kanban method?

It is actually a question I hear more often lately – especially since I started to publicly rant against the misnomer that “product owner” has become.

The question doesn’t make too much sense

As I mentioned earlier it does not make too much sense to directly compare the Kanban method and Scrum because they exist on different levels. Same is true for their lingo.

The Kanban method neither promotes or prescribes roles

There is no formal definition of any role. (cf. Essential Kanban Condensed, p. 33) The aim of the Kanban method is to help create systems that can evolve, following an agreed upon –and in itself evolving– set of explicit policies. That being said, there are roles that the Kanban community has observed as emerging in many Kanban scenarios, but those are not prescriptive. (And of course, there’s more to the Kanban method than explicit policies – bear with me for the sake of the role argument with regard to the product owner)

Are there any product owners? Anywhere?

The first principle I ever heard when I learned about the Kanban Method was “Start with what you are doing now.” I'm personally quite fond of the statement “Accept reality.”

Accept reality

However you put it – the role that is described as a product owner in the original scrum literature (imho that would be Schwaber, 1995 or Schwaber, 2003) is very hard to find out in the fields. As a story goes which makes its round in Germany right now, some famous product development guru (if someone could point me to the source I would be happy to quote the original source) asked a room full of conference attendees how many of them were “product owners.” Almost everyone raised a hand. The next question was “Who could end their product tomorrow?” No one lifted a hand. Thus the stated conclusion was “So – we don’t have any product owners in the room.”
This might sound a bit harsh, but it points to a quite valid aspect of working together IMHO: the question of our understanding of that role.

What is a product owner?

In today’s reality, there are many people who are called product owners, but who aren’t really product owners in the original sense. That’s not as bad as it sounds. At least many people have a rough idea of what a product owner could be. The trouble is that there are many different interpretations of the role. Unfortunately only very few of them are coherent with the original definition. Given that the process descriptions out there use the term as it is interpreted in their context, problems arise when business analysts, subject matter experts, product managers, requirements engineers and other people working on the conceptual development of products are all collated into the umbrella term “product owner.” If you hold people accountable for ordering work items who are specialized in requirements analysis or if you try to get the conceptual sign-off for a new decision table implementation from someone who’s area of competence is customer management it is highly probable that you will be disappointed. “You” in this case can be anyone – from the CEO to the customer to yourself. I have witnessed huge disaggreements about the competencies of the different product owners (note the plural) that work together with a team. A lot of these arguments vanished when we dropped the name “product owner” and used terms appropriate for the real expectations and competencies. But then the process models had to be adapted to these new names. Which, in itself, is not necessarily a catastrophe, but –more often than not– only the end of an illusion. Those descriptions had to be adapted because they didn’t fit “anymore.“ Actually, they never had, but with the new wording, the discrepancies became visible. And all of a sudden, a model of the real –living– workflow became visible.

The Kanban method makes these things explicit by default

Amongst other things the Kanban method encompasses 6 practices –Visualize [work and workflow], Limit work in progress, Manage flow, Make policies explicit, Implement feedback loops and Improve Collaboratively, Evolve Experimentally.
By applying only two of them – “Visualizing” the real workflow and “making [the real ] policies explicit” – you already can find out if there are product owners in your actual workflow. And by applying the other practices and policies you can evolve (step by step) your technology business to an organization that is fitter for purpose than it is today. But that would fill a whole book. Or several. :-)

till next time
  Michael Mahlberg

Legacy code can be made 'easy' - legacy requirements are hard. Welcome to the Zombie-Zone...

In several companies where I supported process improvement initiatives (often by setting up Kanban systems) I saw the same effect: hundreds – or even thousands – of tickets in the (pre-existing) system.

Everybody knows that most of these tickets can't be addressed. Especially with new tickets arriving in the system at a rate exceeding the speed with which tickets can be handled.

Is there a problem at all? After all we can't work faster than we already do, can we?

IMHO this question is really besides the point. Most of the time the answer is ‘yes’ by the way. Most teams with a high workload could go way faster than they do if the took the time to ‘sharpen the blade‘ which they think they can’t do because it seems more important to cut trees. But that is not point I‘m trying to make. Much more important is the question “What is the harm those requirements do, even if nobody is working on them?”

What’s the harm? Enter the Zombies

Comparing those old requirements to Zombies is closer to the truth than one should think. To my knowledge Zombies have never been proven to exist, but Zombie requirements seem to be a fact of life!

So how do they compare? Let’s see:

• # One: They eat Brains!
  Whether you like it or not, these old requirements still consume brainpower.

  • Ever so often someone has to go through them and check if one of them is more important than a new one.
  • Each time a new requirement arrives someone has to check if it is not already in the system

• # Two: They come back!
  Unfortunately people don't realize that those are dead, because they look so alive from afar.

  • Customers enquire on the current state and have to be answered. This usually takes time.
  • Service level agreements and maintenance plans (which your company sold to your clients) kick in and create a huge debt. (Think “fixed in the next major release”)

• # Three You can not trust them

  • There is almost always at least one person who thinks someone else is working on ‘that’ (long dead) requirement and accordingly they rely on it being implemented ‘soon.’ Little do the know.
  • On the other hand there almost always one person who didn't get the memo and thinks it is a good idea to optimize for ‘that’ feature - which never comes.

• # Four They grow, especially because they are dead
  Even though it may seem counterintuitive for people from outside the software-industry, software tends to rot and decay.

  • That requirement you priced at 2 days of effort two years ago – perhaps even in a binding offer – now might costs you three weeks because the software has evolved and the database-schema now includes another dimension that wasn't there when you wrote the offer.
  • That other requirement, which was a “excitement factor” when your sales representative first mentioned it to a customer has become a “dissatisfyer” in the meantime.

Kill your Zombies! Now! Just think Triage. And do it!

till next time
  Michael Mahlberg

How about some Wiscy in product development?

Lean and Kanban (as in David Andersons Kanban) focus very much on value to the customer – but in practice a lot of software development efforts are not quite there yet.

A humoresque (I hope) approach to increasing the productivity of software development was put forward once by the webcomic xkcd: the so-called "Ballmer Peak"

But since product development does not only consist of developing software there is more to delivering value for the customer.

And ever since 2011 when my friend and esteemed colleague Tom Breur introduced me to the concept of wiscy (yes it is an acronym, not the drink) I am torn between my instinct to urge people to flee analysis paralysis and to find out, what it is the user really really wants

You wonder what wiscy is? It is the question Why Isn’t Somebody Coding Yet?

And even though I strongly encourage early feedback through early delivery of working software, you should always make sure that you don't overdue it as depicted in this cartoon.

As they say in Zen and in tightrope walking – it is important to find the right balance.

till next time
  Michael Mahlberg