Scaling the Product Owner.

I’m a huge fan of Dave Snowden’s work, especially as it comes to Scaling Agile. In particular I love the “Recipe Follower and Chefs” metaphor. It captures the difference between what I call theorists and practitioners, although I should really refer to practitioners as praxis-ists. To me, the theorists are the ones who make up the recipes rather than the ones who follow them.

The problem with recipes is that they ignore context. A practitioner operates within a context and so cannot ignore context. The recipe for making a cup of tea is simple… unless you are on a beach, or in the Himalayas where the boiling point for water is much lower.

I love Scrum for its simplicity. Its an approach that can be explained in half an hour yet takes a life time to fully master. Scrum has three roles “Product owner”, “Team” and “Scrum Master”. The product owner makes all the decisions about the product, they prioritise (order) the backlog. Simple! In the context of a single team, Scrum is great.

The problem with Scrum is when you have multiple teams. Or rather, Scrum is not designed for a multi-team development and assumes a single team environment. There is no problem with Scrum, the problem is that reality does not fit into the context that Scrum was designed for.

So lets look at this problem in more detail. Imagine an organisation with two teams (TeamA & TeamB), each of which has a backlog owned by a product owner. TeamA has an MVP called MVPA which requires work from both TeamA and TeamB. TeamB has an MVP called MVPB which also requires work from both TeamA and TeamB. The product owners prioritise their own MVP in their respective backlog… TeamA will has MVPA at the top and MVPB at the bottom. TeamB has MVPB at the top and MVPA at the bottom. This means that MVPA and MVPB will not ship until both are complete.This might seem a crazy situation but it is exactly what happens if a mechanism is not put in place to manage it. Product Owners will prioritise the requirement of the last senior executive to shout at them to get their work prioritised. Furthermore, this is an abdication of responsibility by the executives of the organisation who should be providing direction and focus. In effect the executives have devolved responsibility for the companies direction to the product owners of the Scrum Teams. Although the product owners may understand their product, they do not necessarily have an organisation wide perspective.

What we need is some mechanism to unpick these dependencies so that either MVPA or MVPB is at the top of both backlogs. What are the solutions?

1. The immediate response it to organise the teams into proper Scrum Teams or “Feature Teams”. Each team should be able to deliver a full MVP without any dependency on other teams. This is the ideal situation and should be the first approach. There are contexts where this is not possible. There are organisations and products that are so large that specialisation is needed and a team of 6 to 9 developers cannot cover the entire space. This is the context of Scaling Agile. If you are following a recipe, this is where you will struggle as the Scrum recipe does not work. Its like trying to follow a recipe to make an omelette without eggs.

2. In this situation, we decided to use the “theory of constraints” to find the constraints and create an organisational backlog. We were no longer following a recipe, instead we were having to experiment like Chef’s do. The product owner recipe actually became a problem for us. The theorists ( Recipe Maker ) told us that the product owner should always own the ordering of the backlog. The context meant that to deliver fast, the product owner needed to prioritise their backlog according to a higher level “organisational backlog”. Scaling the Product Owner role creates a direct conflict with the principles of Scrum. If we follow the Scrum Principles we have no control over delivery at the organisational level, however if we create an “organisational backlog”, we violate the Scrum Principles.

For an organisation trying to scale the Product Owner role, this presents a very real challenge. We had executives who saw the need for an “organisational backlog” but also the need for product owner autonomy. In some ways this was a good thing as the executives were thinking hard about not undermining the product owner. On the other hand, it hampered our ability to deliver.

Note that this does not even consider how the “executive backlog” is prioritised / ordered. Whether the prioritisation is top-down, bottom-up, collaborative or directive, democratic or autocratic. Simply the need for an “organisational backlog” causes the Product Owner role recipe to “fail”.

If you are Scaling Agile, you need to hire a (team of) Chefs. You need to hire people with years of experience applying Agile in the role of product management, architecture and IT (risk) management. This team will be coaches to help you handle the situations where the recipes fail. You will also need the people churning out the recipe books and training the teams in team level Agile practices. Your teams will need to follow the recipes but you will also need Chefs for when the context causes the recipes to fail.

A final word of warning, beware of Nigella Lawson. Nigella simply copies other people’s recipes (She has a vast library of Cookery books) but does not invent recipes herself. She is famous but she is not a Chef as should not be listened to when the recipe fails. Instead, hire the Chef from your local gastro pub where you like the food.

I’m conscious that I am not an expert in Scrum. If I have misunderstood something, please let me know and I will update the post.

Introducing Roleism

At XP Day a few weeks ago I gave a lightening talk introducing “Roleism” and I wrote this up after being prompted by a couple of people present.

“Meet the Parents” is a funny film with one underlying “ism”. Its a film about “Roleism”, a prejudice that one person is better than another because of the role they do. In the film Greg Focker is considered inferior because he is a nurse rather than a doctor. Furthermore, it is assumed he is a nurse because he could not get the grades to be a doctor. The underlying message is “Why would someone choose to take a lower status role in society just to help others?”

As a Business Analyst and Project Manager I have often experienced roleism in the Agile Community. Friends will introduce me “He a business analyst, but unlike all the rest, he’s a good one”. What happens if we replace the term “Business Analyst” with “Indian”, “Woman” or “Gay”. How does that make you feel? The assumption is that all Business Analysts are useless but I’m alright. Once you get away from the bright lights of the Agile Conferences you discover that many Agile Teams work with business analysts or architects or some other “untouchable”. The reality is that prejudice on the basis of role is no way near as serious as the other forms of prejudice and I do not mean to imply it is in any way. Then again, when we look at the correlation of roles with gender and ethnicity, we might start to feel less comfortable about “Roleism”. “Roleism” might sound like a joke, however it is the basis of the caste system in India which is perpetuated by poverty and access to education.

I’ve experienced “Roleism” in the Agile Movement for many years. I’ve seen a video of an Agile Thought Leader describing business analysis practices as evil. The implication being that anyone using those tools is also evil. The thing that caused me the most concern about that incident was that no one challenged them. No one said “we should not demonise or de-humanise sub-groups within the community”. It was tolerated.

I’ve worked in a company where “Roleism” is institutionalised with leaders saying testers are not as good as developers. Perhaps if the testers had had he same educational advantages as developers….. but that starts to make us feel uncomfortable.

Why is “Roleism” important now?

Many Agile practices came from studying the best developers in the community. XP was based on the practices of Kent Beck, Ward Cunningham, Martin Fowler, Ron Jeffries, Chet Hendrickson et al. These were built upon by Tim Mackinnon, Steve Freeman, Nat Pryce, Janet Gregory, Lisa Crispin, Lisa Hendrickson, Liz Keogh and many others. Practitioners, not theorist.

There is a huge demand for scaling Agile to the Enterprise. This means that some of the roles we do not need at the team level start to come back into the picture when we are working across teams at the organisational level. All of a sudden we need Business Analysts and Architects and Project (Risk) Managers and and and…. The problem we have is that “Roleism” means the good ones stay away from the Agile community. We do not have the Kents and Wards and Rons whose practices we can model. And into that vacuum steps the trainers and the theorists. In absense of practices developed by the best practitioners, the theorists and the trainers make them up. Their clients expect them, so as experts they are expected to provide them. And we know what happens when the theorists start calling the shots. In a few years we will find ourselves being controlled by people who do not know what they are doing because they have been “helped” by people who do not know what they are doing.

Imagine a movie called “Meet the Project”. It stars a veteran project manager who does not trust a business analyst. The business analyst claims they could have been a developer but really wanted to help projects instead. The business analyst is the butt of the jokes, an outsider, until they are eventually cast out of the project. Only then does the project manager discover that the business analyst once contributed to open source. Who is the butt of the joke now?

The NOT Agile Test

I am increasing concerned about the projects that people are calling Agile. I encountered an “XP” project that took eighteen months to deliver the first release, and nine months for the second. Even worse, the project was the flagship Agile project for the organisation. I encountered a project that has yet to deliver a single release after two years that claims to be Agile because they are using Scrum. I think anyone involved in Agile would agree with me that these projects are NOT agile.

Whilst defining an Agile test would result in endless discussion and debate, I think we can all agree on a test to demonstrate that a project is NOT Agile.

Here goes. As a minimum, an Agile project…

  • Delivers demonstrable value each iteration.
  • Sustainably delivers a high quality product.
  • Releases in short iterations.

All three are needed because any two can be gamed. e.g. You can deliver value quickly but not high quality or sustainably.

A project is NOT Agile if it does not do all three. Doing all three does not mean that the project is Agile.

Some more detail on what these mean…

Delivers demonstrable value each iteration

Each iteration delivers value to the end customer or the business. A stakeholder (not necessarily the product owner) can see the value delivered. Delivering software is not enough, especially if it does not deliver value to anyone.

Sustainably delivers a high quality product

High quality means high quality code (with no bugs) that performs according to user needs and has no user experience bugs. Sustainable means the teams are not sprinting and collapsing, but rather have a sustainable pace that they can maintain indefinitely.

Releases in short iterations

The project delivers value in short iterations. Each iteration is a month or less. I choose one month because that was considered best practice over a decade ago and should not be considered a difficult goal by any stretch of the imagination. In reality, many organisations deliver value several times a day.

The key measure for the iterations is the lead time rather than the time between releases.

So there you go. A test to show things are NOT agile, rather a test to show things are Agile. Note that there is no mention of Scrum, XP, Safe or Kanban, or any of the Agile practices. It is the qualities of the project that determine whether it is Agile, not the practices ( Hat tip to Alistair Cockburn ).

This thinking is not mine, it is the result of many hours of discussion, especially with Marina Oliviera, Tony Grout, Alan Hawrylyshen, Paul Hammond and many others.

Cynefin and Estimates

This morning I saw a discussion on twitter about “Estimates being wrong”. This struck me as really odd. I’m a huge fan of Todd Little and Troy Magennis on the subject of estimation. They have taught me that the relationship between actual and estimate follows a log-normal ( or rather Weibel ) distribution.

When we make an estimate, it occurs at a time t based on an information set ( I0…It) with a filtration funtion F(t). There is a huge amount of uncertainty involved in the estimate. It is obviously going to be wrong. A better question is, is the estimate useful?

We estimate in order to make decisions. Do we want to do this thing? Do we want to do something else?

In Capacity Planning we use estimates to help us work out the approximate demand on a team during the quarter. We can use this information to identify which teams are constrained and this helps with creating an organisational backlog. Our process asks the Product Owner for the estimate, and NOT the engineering team. This means the engineering team cannot be held accountable for the estimate if it turns out to be WRONG. It also means the team do not try to get it RIGHT. The process allows the Product Owner to ask the engineering team if they choose, it just does not require it. The executive in charge of the process was given Todd Little’s paper to read so they understand the nature of the estimates. The goal is not that they are right, it is that they are consistent in approach. The estimates are good enough to be useful to help identify constraints and form the backlog. No one cares if they are right or wrong.

Something about this made me stop and think about Cynefin. Much of my work recently has been assisted by understanding whether the person I’m dealing with operates in a “Complicated’ world where outcomes are knowable or whether they believe the work is unknowable/emergent in a “Complex” world. I’ve noted that certain words are useful cultural markers to help you spot which. Right and Wrong indicate certainty which implies a belief in expertise. Hypothesis, Useful, Better or Worse indicate an appreciation of the uncertainty inherent in the process. People are not computers, so it is common to find someone struggling to find the appropriate words to use.

So if you hear someone referring to estimates as right or wrong, then you know they are thinking about expertise. If they focus on the usefulness of the estimate and the context, they are thinking about complexity.

Am I right or Am I wrong? And is this useful?

Knowing where to dig.

I occasionally come across the attitude that the work I do has no value. Managers love the workers who have been digging like crazy, but they give less credit to advice on where to dig. This photo is of a hole in a car park in Leicester where a skeleton with a curved back was found. It turns out it is the final resting place of Richard III. There is little doubt in the minds of the general masses that the heroes of the story were the archeologists who told the driver of the digger where to dig. No one is filming documentaries about the driver of the excavator who dug the hole.


Everyone has heard the urban parable of the Captain who boiler breaks and he needs to call a plumber. The plumber arrives and takes ten minutes to listen to the boiler before hitting it once with a hammer. When the bill for $1,000 arrives, the captain demands that it is broken down. “Hitting the boiler with a hammer: $1. Knowing where to hit: $999″. Its a parable about the value of experience.

Most people working in Agile Management are advocates of the Theory of Constraints. I certainly am one of those advocates, although I rephrase it to more understandable terms (which may not be pure mapping to the original):

  1. Agree on the goal.
  2. Identify the constraint.
  3. Prioritise the constraint.
  4. Optimise the constraint.
  5. Add capacity to the constraint
  6. Rinse and Repeat. ( Goto to Step 2 ).

Steps 3 to 5 are really about digging ditches. Once you have identified the constraint, it is fairly straight forward to do the rest. They just require effort and application. Step 2 is about knwoing where to dig. As a consultant, its my role to help identify the constraints and then dig the hole. As a coach, its my role to help others to learn how to identify the constraint. As a participant of the Agile Project, I contribute those tools ( like radar and X-Ray ) that can be used to identify the constraints. The two most significant tools I’ve discovered so far are:

Staff Liquidity Skills Matrix – Identify individuals whose skills are a constraint to the team.

Quarterly Capacity Planning – Identify those groups who are a constraint to the organisation.

If you want me to pick up a spade I will do, however unless we have a constraint on the number of people are willing and able to dig, I’d rather help people learn how to find the right place to dig.

Examples that break the model

Break the model is a process to identify a representative set of examples. The process involves creating a model through an evolutionary process of describing examples that otherwise would not fit in the model and effectively break it.

There are two types of example that break the model:

1. Examples that are different but have the same description in the model.

2. Examples that do not fit in the model.

To explore this concept, lets consider the inventory system for a comic book shop (like Stewie’s in big bang theory)

Our model for the description of a comic book consists of:

a. The “Title” ( e.g. Amazing Spiderman )

b. The issue Number ( e.g. “1” )

c. The price.

Examples that are different but have the same description in the model.

Consider the two photo’s below. They have the same description according to the model. Are they the same comic?


The answer is no. We discover that the condition of the comic is important. This is actually an extreme example. The comic on the left sold for $104,200. The one on the right sold for $2,750. These examples would break the model. We would need to include a condition indicator ( or Grade ) on the comic description. The model helps us compare examples. It allows us to sort the examples into piles. We can then compare the examples in the piles to see if any of the examples are different. The comparison of the examples often needs the expertise of the subject matter expert. The subject matter expert can tell the difference between two examples that a lay person may not be able to detect. The subject matter expert also knows where the bodies are buried. The SME knows the examples that are likely to be overlooked. They are aware of those examples that look the same but need to be treated differently. To illustrate this point, compare the two comic books below.

Spiderman 94 92

The one on the left is the same one with a grade of 9.4 and sold for $104,200. The one on the right is ever so slightly poorer condition with a grade of 9.2, and sold for $57,523. Only a trained expert can tell the difference. A difference worth $50,000. As fields develop, they become more sophisticated. The rare comic book industry now compares comics of the same grade. Two 9.4 comics might be judged as having “white pages” or “off-white pages” which can also have an impact on the price.

Another important point is that the differences we find between the examples are orthogonal to the model. They are things we never considered.

Examples that do not fit in the model.

Some examples do not fit in the model at all. These we have a tendency to ignore. In software systems, we would develop a manual or spreadsheet work around outside of the system. Typically this involves shoe-horning the example into the system and then managing the differences off-line. Once again, our subject matter experts will be able to tell us where the bodies are buried. From the systems perspective, it is blind to the examples that do not fit into its model.

As we are developing the model, we may explicitly exclude examples that do not fit the model. This can be risky as we may exclude examples that should be included. It is better to include them in the learning model but exclude them from the implementation model. This way we can better understand the implications of changes to the requirements.

Non-Software Models.

Not all models exist in software systems. Some exist in people (cognitive models) and some exist in markets. Making our cognitive models explicit can help us spot the differences for things we consider the same. The interesting examples are the ones that do not fit our cognitive models. The examples that have no value to us. How many of you have walked past a shop / bar / building for months or years and only notice it when you need what it sells, or a friend points it out. How often have you said “I did not realise you were here!”.

Not only does this apply to shops and the like, it also applies to people. Who is that world renowned expert who sits two desks away, but in a different team or department? The examples that make it through our filters of perception (model) have much to do with the value we ascribe the examples. As we receive information, or learn more (our filters change), we change the value we ascribe to things.

An open letter to Jabe Bloom about Purposeful and Value

Dear Jabe,

Thank you for sharing your keynote with me last week. I think we were both lucky to have JB and Greg providing questions, insight and context. I want to pick up on one aspect of the talk. The use of purposeful instead of value. I understand that the general understanding of value cannot help your studies much, but I think the more rigorous definition will be useful to you. It is the rock that Real Options was built upon.

Here is the definition of value from finance.


This simple and elegant formula (definition) tells us that Value ( V ) is a Filtration ( Backwards F thing ) on an Information Set Io to In. You will note that it has no units. The units can be financial such as US Dollars or Scottish Pesos ( Had to make it topical ). Currency is useful as a means of exchange. As a means of transferring something from one entity and another.

The units could also be something internal like the “Jabey”. The “Jabey” is an internal currency that is never articulated. The “Jabey” is not used to exchange things between entities. We use the Jabey (which does not really exist) to make internal decisions, often subconsciously. What is it worth to speak to a loved one in “Jabey”?. It costs $5 to call that loved one. What’s a “Jabey” worth in US Dollars? The exchange rate between the “Jabey” and the US Dollar is constantly in flux, though we may fix some exchange rates. The constant flux is from the arrival of new information ( Io to In ) but also from changes in the way we think and feel ( changing of the Filtration Fn ). My goodness, this value concept even incorporates behavioural economics.

This constant changing of the filtration function means that the value can change even if the information set is the same. This means we have to modify our equation to cater for this shifting filtration function.


What is most glorious about this equation is that the filtration function co-evolves with information as it arrives. The purpose of Feature Injection is to spot information that should change the filtration function… but doesn’t.

The great thing about this formula is that it can be plugged into an infinitely complex network. Inefficiencies in the network will be revealed as arbitrage opportunities.

This equation is a hop, skip and a jump away from the formal definitions of Real Options and Feature Injection. < Editor’s note: You have to invent a new mathematical term… “Is better than” to describe Real Options >

So tell me, can “purposeful” give you all of this richness?

Your friend



Get every new post delivered to your Inbox.

Join 69 other followers