The question of using product owners is something that has plagued me for some time. I’ve always thought that there’s something not quite right about the concept and through my experience with this over several years, I have come to try and avoid formalising the product owner role where I can. When I say product owner, I mean it by the term used in scrum (see the scrum guide), as distinct from a product manager.

Some of the key problems I have with it include “The product owner is one person, not a committee”. What I often see is that this becomes (whether rightly or wrongly) a central point for decision making. Often this is a bottleneck and can start to disable flow in uncertain situations. For example, what happens when the decision maker takes leave and goes on holidays for a few weeks? What if this is unexpected medical leave and there’s no handoff? Usually what happens is decision making is greatly reduced or stopped and the organisation suffers from this.

Furthermore, I often consider “what if the PO is wrong” – what happens in this situation? I’m reminded of David Marquet’s work in this area where he encouraged leadership at all levels and decision making was more distributed to where the appropriate amount of information to actually make that decision resided.

Another issue that I have with it is at the adoption stage – in order for scrum to be effective they need experienced product owners. These kinds of people are not necessarily grown overnight and really need some intrapreneurial tendencies. It can often take several years to grow a good product owner. With many organisations, I often see people granted the “Product owner” role, but they don’t have any, or very little, understanding of what this is and how to make it a success. Often organisations pour a lot of time and money into this, which although it may payoff in the future, you are likely to have better spent that money improving the products and services for customers and getting them out to market more rapidly.

Another problem I have seen is the “part-time” product owner. If they are chosen from the business they’re often given these duties in addition to their “day-job”. Teams rarely get enough time to discuss things with the product owner and often their absent for most of the time. Teams flounder like a rudderless ship in a storm. In order for new product owners to learn they need to immerse themselves in their product initiative and take some of their day job tasks away. There is a balance here, because you want them to continually be in contact with the broader aspects of the business, but their focus needs to be correct.

I guess another thing to consider is whether to bring in outside help. In which case you have to deal with the fact that the folks coming in likely know how to be a product owner, but don’t understand your business. It will take them some time, perhaps a year in larger companies, to form relationships in your organisation and be able to understand the inner workings of your product or business. There’s an up front investment here and you have to wonder if the pay off will justify the outlay.

In larger organisations, particularly when you look at organisations that adopt SAFe or other like scaling frameworks, you tend to find that the product owner at the team level does not really resemble what scrum had intended for this role. Essentially, there’s little decision making at this level as things are usually sliced at a higher level. I’ve found that often in this context you’re better off making sure you’ve got a good Agile BA who understands the domain and can detail the work coming into the system who can work collaboratively with stakeholders around prioritisation.

Additionally, the statement “For the Product Owner to succeed, the entire organization must respect his or her decisions” is often hard to achieve. Many organisations appoint puppet product owners with no real authority, or what authority they have is often overridden.

Another point about the product owner is they often become a proxy sitting between the team and the customer(s). Although POs are intended to be this, which can work in some circumstances, it’s still good for the team to get out and interact with users and customers. Again, the PO is a single point of failure and only applies their own single lens to information coming through the system. Having different perspectives for customer / user / stakeholder interaction can provide a richer feedback loop and allow you to pick up on nuances and opportunities you would otherwise miss. I recall the XP framework being big on ensuring the team are talking to the customers / users. I think this is important and often a product owner, especially if they’re learning the role, may get in the way of this.

Are product owners a broken concept? In view of their implementation is often very problematic, enough for me to question the benefit of and avoiding their introduction wherever possible. I’m not saying the “committee” is the right option either – I really think you need to consider other options. If you haven’t introduced them, it might be worthwhile considering first ensuring your decision making policies are explicit and pushed down to the appropriate level in the organisation. See how distributed decision making can work and enhance you overall organisational agility before centralising it and introducing a product owner concept.

RETURN TO BLOG

Backlogs often become a dumping ground for ideas. Some of those ideas are good, others might need some exploration before we understand if they’re worth it or not, but many of them are often not worth pursuing. After some time, it can be cumbersome to start to trawl through an ever increasing backlog to find the right value item that you should start to explore.

If you’re using a backlog and not thinking of them as options, please refer to an earlier blog post that talks about using options instead of a backlog (from here on, I’ll refer to them as options):

https://evogility.com.au/use-options-instead-of-backlogs/

Options have a value at a point in time. Generally they have a cost of delay. There’s also a cost of retaining options for too long – think about a options list that has a thousand items in it, how long is it going to take for you to find the top 10? You need to regularly trim your options list to make sure it’s lean and gives you insight into what are real options you need to spend your time on.

Put it another way, if you’ve had an option in your list for a year and haven’t taken it up, how likely is it that you’re going to take it up in the next year? For that matter, if you’ve had an option in your list for six months and not proceeded, how likely is it that you’ll take it up in the next six months? Or three months? If you’re thinking to one / all of these that it’s not very likely, then you’ve really just hit on your option expiry date. After a certain amount of time those ideas have expired.

Think about your answers to those questions. The one that’s the shortest to which you answered “unlikely” is your option expiry timeframe. Record the date that an option enters your pool of options. After the amount of time you discovered above (say it’s six months), that becomes your option expiry date.

Periodically remove those options that have exceeded that timeframe. Just throw them away. Even better, if you have an electronic system, set a rule to do it for you. Don’t worry, if it’s really important it will come back and you can create another ticket.

Doing this will save you time and help keep you focused on things that are important right now.

RETURN TO BLOG

Earlier in my journey as a coach / delivery consultant, I thought that agility can be achieved through a “high performing team”. Many agile coaches, scrum masters, delivery leads / managers etc have tried to achieve this kind of thing through making a great team. This might work really well in a small organisation, but once you get to medium to large size organisations, this is not necessarily where the key problem is.

In more recent years, I’ve observed how critical it is to bring various groups together to achieve an outcome. The solutions to some problems are larger than just one or two teams and create interdependencies for delivery. Often, the points of waiting and even friction occur where these interactions are necessary.

Problems with “High Performing” teams

A high performing team works great when all of the dependencies are contained within the group. This could be a single team or a “Service Team” which I see as a larger group or “team of teams” providing a service (eg five 10 person teams working together). Often this team have optimised the interactions within the group and have a fairly well known way of working.

Where this group needs to interact with others in the organisation, it can run into problems. Other groups may have their own way of working which may be similar but is often times different. Relationships between members of the different groups may not be very deep or perhaps non-existent.

Additionally, I’ve seen in the past where teams are “high performing” this can increase the silo mentality and start to create a blame culture. That is, they don’t want to be seen as a non high-performer and become insular and in some cases arrogant. They can call blockers out up and downstream, but don’t want to spend their time being “unproductive” by relieving the blockers. If it goes unmanaged, you can see them pull in more WiP in this circumstance while they wait , which creates further problems.

It may be that they don’t have the skills to go upstream / downstream to help relieve the overall system. Thus they continue on with solving “their part of the problem”, but the overall tends to suffer.

Take, for example, a mobile development service team. They may make regular (eg monthly) improvements to the mobile application / device for your organisation which they can do entirely by themselves. Then at some point your organisation wants to launch a whole new feature not previously seen. You want to showcase this at an upcoming trade fair to generate the largest possible market interest in a short amount of time. Your mobile team will need to work with the marketing team and sales teams to ensure you can maximise the revenue opportunity at the trade fair. They may have rarely done this before, thus the interaction is unusual but critical for the overall business success.

Nature of work in large organisations

Your organisation is a network of interdependent services that act together to serve your customers. This is really an adapting, changing, organic ecosystem if it’s running effectively. External stimuli (customers, markets, competitors) will place new demands on the ecosystem and it’s long term success is based on it’s ability to adapt to that stimuli.

In larger organisations, there may be some interactions between groups that are consistent / regular (work together on many / most initiatives), others may be occasional (eg once or twice a year) and others may be a “one off”. For those that are consistent or occasional, you may be able to predict this to a certain extent. Even if you can predict the frequency of the interactions, the nature of the individual interactions may be quite different.

Oftentimes, the really high value work will mean that this kind of work likely doesn’t have much / any connection to previous work so you’ll need to establish some relationships from scratch.

Possible Solutions

Understand the network

Sometimes to get this understanding you may need to visualise the work and “how work works” as it traverses the organisation.

Where it is at all possible, it would be worth gathering some data about the network to understand the interactions. You can see where the common links are that you want to strengthen and how you may wish to make changes. You may also wish to gather data on where wait states and blockers are in the overall workflow. You may wish to introduce a cadence like Kanban’s “Operation’s Review” to continually monitor and adjust.

Protocols

The internet is a classic example of a network that grows and changes over time, but the fundamentals of how nodes communicate with one another is governed by some simple protocols. You can set this up as basic systemic policies to allow for simpler communication and coordination around the network.

Cadences

Sometimes cadences can work to help with synchronising groups. However, beware of this becomes sometime they can be a source of waiting / waste. For example, if you have a quarterly planning cycle, you may not want to wait that long for a new, urgent piece of work.

Reorganise teams

This really isn’t really viable in the short term – with different work coming from different sources it often doesn’t make sense to continually reorganise. Furthermore, there are costs associated with doing so – there will be a period of inactivity, plus you’ll lose the benefit of previous metrics for that team as it establishes it’s new identity / way of working. If in the longer term you see a continuing pattern of teams working together, you may want to take action at that point – just wait until the reason is compelling enough to justify the cost.

Remove dependencies

This is something that you should always consider, however in larger more complicated work, this is not always practical or possible. You may achieve this by slicing work into more narrow / succinct areas of scope to avoid the immediate need for a dependency. This can also be achieved by changing a technical need for the dependency.

Coordination specialists

Some people are natural connectors in organisations, knowing who to contact / bring together to help solve problems. You can use these folks to help guide work through the network, facilitating the creation and maintenance of connections where required.

Team Member Swap / injection

While complete reorganisation of teams may be too disruptive, you may wish to consider injecting a member from one service team to another to act as a bridge for a particular initiative. This could also take form of a swap where team members are exchanged from each group. This will help build a deeper understanding of the other groups context which will make this and future interactions smoother.

Stimulating the organisational network

There are a couple of spins to this from my perspective – one is the effect you get from large group events where there is lots of interaction. Meeting new people and understanding who is who can help to start to bridge the gaps of connectedness – this can often occur as part of a regular planning or other similar cadence. The other way is a deeper understanding is through other techniques like Cognitive Edge’s Social network stimulation.

Conclusion

As your organisation grows, the complexity of how it solves problems will likely also change. When you get to a certain size, having a “high performing team” will not necessarily be enough – you will need to tune the entire network of services to be able to adapt appropriately.

This is not a simple problem to solve, so it’s best that you don’t act too simplistically. Furthermore, as the organisation and environment continually evolves you will never be “done” with this – you’ll always need to monitor and make continuing adjustments.

As I mentioned in my recent post on Kanban books, I would recommend Klaus Leopold’s book on this topic: “Rethinking Agile: Why agile teams have nothing to do with business agility”.

RETURN TO BLOG

I’ve heard this being said a number of times with teams and it often reminds me of the story the Jeff Patton told in his book “User Story Mapping” when he was talking about requirements. In that story, when he was trying to get a better understanding of the underlying need being requested he was told “They’re requirements” – to which he likened to being told to “shut up”.

When I hear the term “It’s on the backlog” I think that’s another way some agilists are telling others to “shut up”, or at the very least “go away”. Often it’s not followed up with more honesty like “we don’t intend to build that”, or at the very least “it’s not likely to be built in the near future”. Sometimes this is a way of saying “No” or “Not yet” where it can be difficult to say this flat out, but is it the most respectful way to treat people?

Again, this is the problem with using the term “Backlog” instead of “Options”.

How about instead try something along the lines of “we can add a ticket to our pool of options, but it’s not likely to be implemented anytime soon, if at all”. You might find that this change in terminology gives your stakeholders greater respect and builds on the trust and transparency that you need to build a more stable foundation for a longer lasting relationship. Also, you’re starting lean towards the use of language that supports probability / likelihood rather than absolute certainty. This incremental step can be built upon later with greater use forecasting.

RETURN TO BLOG

I’ve recently been thinking about a number of experiences in my career where organisations who have a bias for delivery have uncovered options that were not previously available to them. I’ve also seen others who had a tendency to delay delivery (or at least deployment) to when their customers are “fully ready” for it.

This predominantly happens in organisations that have traditionally had long lead times for delivery. Often the transaction costs for delivery are quite high, but other times it may be that the process and thinking over time has solidified such that the delivery managers don’t consider other options.

Some of the arguments I’ve heard include the following (along with my counter arguments):

That’s the way we’ve always done it” – That’s a Kodak moment waiting to happen. You can bet you’re bottom dollar that if you’re not looking to improve, then your competitors are. How long do you think that will last?

It will cost too much” – This is often in the context of the cost of deploying without delivering – there is a run cost to have the hardware / systems there earlier. However, I would counter this by saying the hidden costs you’re not considering are:

  • Lifecycle vs Project costs – if you deploy regularly during the project, you can test the deployment automation mechanism and be confident that it works at the push of a button. Delaying this often means costs are pushed into BAU where later releases are still manual and are longer, costlier and riskier
  • Opportunity cost – by sticking to long cycle times, you are cutting yourself off to potential other opportunities that you’re not aware of yet
  • Transaction costs are high – well, if we don’t do something about it earlier they will always be high. Maybe there are some ways that you can start to reduce these transaction costs that you haven’t thought of – perhaps start here.
  • Have you fully considered the overall cost of delay if you get into a “large batch death spiral“? This is quite likely if you stick to this.

Our users are not ready for it yet” – Perhaps, but have you considered all of your user groups? I’ve seen opportunities where you can do early releases to your staff / operations team often referred to as “Eating your own dog food” (a common practice at Microsoft). This is a great way to reduce overall delivery risk – particularly if you have a large delivery footprint.

What are some of the results we’re likely to see?

Some of what I’ve seen before are a combination of things, the key one is:

New opportunities – This is often not thought of and the value here can be enormous. I’ve seen organisations try to release a new product and it doesn’t go exactly as expected. However, by getting something out earlier, it’s given them a new capability / offering that has allowed for exaptation / transforming into other products or parts of products. By getting something out early they have created a new foundation for future revenue.

Other reasons for taking a bias to delivery include:

  • Reduced delivery risk – particularly around timeline. Getting things out early and regularly so at least someone can use it helps validate if you’re really on track (even if it’s not your final target user group).
  • Reduced costs – In some instances I’ve seen clients say “This often takes 12 months and can often fail – let’s see if we can get something out in 3 months”. It gets really hard to spend a lot of money in a smaller timespan.
  • Stopping – There’s often an OPEX / CAPEX problem if you haven’t actually produced a usable asset. Some organisations, are reluctant to stop the large batches because it will switch spend to date to OPEX from CAPEX which will have deeper ramifications for the organisation and their customers.
  • CAPEX depreciation – If you can start depreciating an asset in 3 months rather than 12, there are potential financial benefits to this that you otherwise wouldn’t have

How do we get started?

In a word – Leadership. By this, I mean someone has to have the vision and courage to see what is possible and make a change. This does not necessarily have to be done at the top level – I would encourage all Delivery Managers, Project Managers etc to consider this on their project.

If you’re working in a space and see this happen, try arguing with some of the reasons above and probe to understand why people might not wish to try it. It may just be “too different” to what they’re used to. You may need to break through any fear there in some way – you might want to create a greater fear in maintaining the status quo with the reasons above to create that movement.

RETURN TO BLOG

Often we become constrained in our thinking by the language we use – a good example is the use of the term “backlog” instead of “options”. Quite often if you say to someone “It’s on the backlog”, the perception is quite often that although I might not get it now, it will become available sometime. However, in reality this is often not the case – or should not be the case. If we change the wording we use, we’ll create a more accurate representation of what is actually, or should actually, be happening.

Definitions from the Cambridge dictionary:

Backlog: “a large number of things that you should have done before and must do now”

Option: “one thing that can be chosen from a set of possibilities, or the freedom to make a choice”

Commonly, the term option is used in the context of the stock market, where you can have an option to buy shares (or not). You have the choice – it’s not an absolute.

As you can see from the basic definitions above, they are quite different and the impression that they can give stakeholders, also, would be quite different.

The above definition of backlog implies a fixed scope – “must do now”. However, to truely be agile we shouldn’t be committing these kind of things up front as we’ll learn along the way and what should be done will change as we learn.

Try to stop using the term backlog, and instead replace it with the word(s) “Option” or “Pool of Options” and see what effect it has to the conversations with your customers and stakeholders. You’ll be able to defer commitments to a more reasonable point in time and have that process better understood. Additionally, you’ll likely find that you’ll have earlier conversations as to whether we should discard some options, rather than keep maintaining the illusion that something may get done.

RETURN TO BLOG

I’ve been doing this retrospective format for a number of years now and it’s been very useful. Given that we’re moving into Spring here in Melbourne I thought it would be a fitting time to publish this as we prepare for the Spring racing carnival.

For those of you who don’t live in Melbourne, or don’t know what the Melbourne Cup is all about, this will help set some background. Here in Melbourne the first Tuesday in November is a public holiday for the Melbourne Cup. The Melbourne Cup is a horse race – yes, we actually have a public holiday just because of a horse race! It’s more than just a horse race, it’s actually part of the culture here in Melbourne, there’s also the all the fashion, food, wine and socialising that goes on during the what is known as the “Melbourne Cup Carnival” – with events on throughout the week.

This particular retrospective format I’ve derived from the event is actually a “futurespective” – it’s useful to use it at the beginning of a project or product development initiative. It’s really a useful way to start to talk about risk, but to come at it from an oblique angle so that you can explore it openly without a great deal of negative fallout.

I start out with asking participants – “If this project were a horse in the Melbourne Cup, what odds would you give it?”. I ask that the participants write down their answers on a card fold it up and throw it into the middle of the table / room. I then pick up the cards and put them on the board ranking them from shortest to longest odds.

Once the values are on the wall, you can see the variety of responses. Sometimes they are clustered, sometimes they are very well dispersed. I really like it when you get a lot of very different responses, because it will add to the later discussion. One of the first times I ran this, I got one response of “2 to 1” and another of “100 to 1”.

This was actually a very small team with only a few people, so it was interesting to see those responses. When I probed some more “what made you give 2 to 1?”, I got the response “Well, the sponsors really want this to happen, so that will ensure that it’s seen through to conclusion”. Then I asked about the 100 to 1 and got a response along the lines of “The technical implementation has quite a few unknowns – I’m not sure when we hook these things together, if we’ll get it to work”.

So, very quickly we came to understand that our stakeholders are not necessarily going to be a risk, but an asset in seeing this done, but the technical implementation may pose some problems. Very different risk areas and very different responses – which was great!

Now, the next step is to get a better understanding of the risks – I often use the likelihood / impact model for this. I write up a card for each type of risk from the discussion and get the team to decide on where it would fit on the chart:

Normally as part of a retrospective you’ll want to take away a few improvements / countermeasures etc to take away and action and this retro is no different. With the above chart we can decide where we want to spend our next focus for improvement – usually start with the High Likelihood and High Impact and then go from there. There may be several risk mitigating / avoidance actions that you’ll need to take, so discuss how you’re going to do this with the group.

You can add these actions to your Kanban board for follow up in the upcoming days and weeks.

The Melbourne Cup retro is a great way to obliquely address upcoming risks in a forward looking retrospective. It’s not something that you necessarily need to do very often, but you might find it a valuable addition to your retrospective repertoire. If you like this idea for a retrospective and give it a try, please reach out to me (dploeg@evogility.com.au) and let me know how it goes.  

Feature Image:

This image was originally posted to Flickr by PreciousBytes at https://www.flickr.com/photos/72562013@N06/10705862835 and is distrubted under Creative Commons Attribution 2.0 Generic License.

RETURN TO BLOG