I typically hear this kind of question from a number of agile coaches and those supporting “agile transformation” activities. The reality is that most agile coaches are not equipped to do this kind of work as they’re used to dealing with team level problems. The so called “frozen middle” are the layers of management – so in order to unlock them, we’re going to have to start to talk about how to “manage” teams and organisations in an agile way.

First of all, let’s set some context. This approach is really focusing on organisations that focus on “knowledge work”. That is, they’re using what I refer to as the “neck-top computer” to solve problems, create products and provide services for their customers. This is human centric and although we may use computers & technology to solve the problems, the key is the people creating those solutions. Usually, this is in the form of intellectual property and involves the creation or modification of various forms of intellectual property. For those in other industries that predominantly involves the physical aspects, such as construction or manufacturing, this does not necessarily apply to that kind of work (but it may apply to those aspects of the business that involve knowledge work – eg finance, legal, HR etc).

The management layer, particularly in medium to large organisations, has been created and evolved usually over many years or decades. Many of the processes and practices were put in place at some point in time for good reasons that may still be valid. First of all, we need to understand the context and the problems that you’re trying to solve – but we need to put this in the perspective of those in this management layer. How do they set and meet expectations? What are they being measured on? What management levers to they have to pull? Many agile transformations start with reorganising the structure of the organisation, however this is usually counter productive because you’re not necessarily dealing with the underlying problems that created the “frozen” aspect. Indeed, if you do a large reorganisation, you’re competitors are probably smiling thinking “they’re going to be busy distracting themselves for the next 6-12 months, we can take advantage of this”. If you’re undergoing this kind of change right now, come back to this in 12 months or so because I’m guessing you’ll still be facing these issues.

If you start to talk to the management layer about their specific problems and start to address them, you’ll both gain credibility and also have some practical benefits from the changes. But you’re probably thinking “how do I do that?”. This is the first step of any kanban implementation – understanding the points of dissatisfaction and addressing them. This is how to start thawing out the frozen middle. Often times there are problems like:

  • I can’t see / don’t understand what’s going on
  • I’m not sure of the team / group’s capacity
  • Are we predictable in our delivery?
  • Can I make reliable commitments?
  • There’s an existing policy / rule we have to follow

The next thing you need to know as a coach / transformation agent is that there are a lot of management practices that are firmly rooted in the 19th & 20th century. They’re not really designed for 21st century knowledge work. The key to this is that you need to be able to connect with managers of this understanding an alternative way to manage – the way they can “manage flow”. Many of the techniques are quite different and when you use this lens you’ll note that a number of the older practices are part of the reason for the existing problem and why the middle has become “frozen”. Through this, you’ll start to see where the problems / bottlenecks / blockers are to your organisations delivery capability. Seeing and improving this will lead to greater organisational agility. We cover this off in our Kanban System Design and Kanban Systems Improvement courses in more detail.

But why should the manager’s listen to you with this new management style? You need to understand what their motivations are – and it will be different for different managers. Understanding their motivations and giving being able to answer “What’s in it for me” for each of them is key to continuing to thaw out that permafrost. You can’t change everything overnight, but you can start to move them to a greater level of maturity more gradually. You just need to understand the change levers that are at your disposal. The reality is that it’s taken years / decades to create the existing system of work – you’re not going to be able to change it overnight, but it can start to evolve. We cover off these topics in the Kanban Maturity Model course, where you can learn how to help managers enable greater flow and maturity through their organisation.

For any agile coaches out there, if you’re coming across a “frozen middle” problem, please consider how agile management should really work. If you’re going to go into this space you really should be equipped with the at least the Kanban Management Professional if not the Kanban Coaching Professional capability to help you navigate those frozen seas. For those of you who wish to learn more about how Kanban can help you unlock the frozen middle, please sign up to our newsletter.


If you’re a Project or Program manager and you haven’t had much experience in agile delivery, this can be a daunting experience. You probably don’t know much of the lingo and you’re probably not sure of how you need to operate. More than that, you probably don’t know what on earth the team is doing or how you can understand it.

There are several possible ways you can go:

  • Get out – find another project that doesn’t have all this “Agile” stuff going on. Go somewhere else where you can be comfortable with the delivery techniques.
  • Bluff – you can try to pretend you know how to do this, perhaps trot out a few buzzwords and try and fly under the radar.
  • Revert – declare that agile doesn’t work and “we’re going back to waterfall”. That way you don’t have to change, you just need to get everyone else to do so
  • Learn how to manage an agile project / program – this may at first seem outside your comfort zone, but chances are no one else there’s knows how to do it, or do it really well – otherwise they wouldn’t have asked you.

Get out

Sometimes discretion is the better part of valour – you may need to make a tactical withdrawal at this point. There are likely plenty of “traditional” or waterfall projects out there that you can contribute to. You won’t learn as much or challenge yourself in a new context, but that’s ok, you can reliably deliver the kinds of things you have in the past the way you know how to do it. There’s still value in that for certain contexts through this delivery mechanism – so look for something that suits you.

It can be quite frightening going into an agile context if you’re not used to it. Things seem out of control – you won’t have your trusty schedule and other tools that you’re used to to rely on to see things through. You might not know how to communicate with the teams – how to understand the risks / issues and get the information you need to do you job.

If this is you, then I thank you for understanding where you want to be and not trying to fake your way through agile delivery and deciding to bow out. So many program / project managers pretend to understand and don’t really change any of their behaviours for this new context and they’re better off not getting involved – it will just lead to failure.


In this option, you may not understand agile delivery – or you may think you do and just don’t want anyone to notice. You decide to bluff your way out of it – or “fake it till you make it”. It’s a nice idea, and you might get away with it for a little while. If you pick up on some of the buzzwords and kick off a few basic ceremonies, no one will notice that you really don’t know what you’re doing……will they?

This is a great option if you don’t want to change your behaviour too much. The teams can go “agile it” over there, but I’ll manage it with my traditional tools and techniques across all of that. What could possibly go wrong?

In the context where a number of people are new to agile and don’t know any better, you’ll probably get away with it, until it becomes noticeable. Essentially, the dynamics of the two paradigms will start to contradict each other and you may actually have to switch your approach to “Learn” instead. In which case, will you have made the switch in time or is it too late? It’s likely that if you’ve left it till this point in time, there’s some kind of problem that surfaced and you’re getting called upon / called out to fix it.

If people in this program actually have some agile delivery / management experience, they’ll probably call you out on it. When this happens, you can try one of the other options – “Get out”, “Revert” (perhaps you might need to remove / silence the agile delivery manager to do so) or “Learn”.


This can often happen – particularly if you’re not well experienced / trained for this kind of delivery. What happens is that often your traditional project / program managers come into the agile context when they probably should have gotten out. Often these are the fakers that don’t understand what it takes to manage agile delivery, thus they don’t set things up for success from the beginning. Eventually, you’ll see the program / project starting to go off the rails.

If the scenario is one where everyone is entirely new to agile delivery, you would have had to set up a lot of support initially for this to occur. Both at the team level and the management level – there are different techniques and practices that will need to be in place. You’ll have a lot to “Learn” – plus you may need to bring in outside help to coach and / or recruit some more experienced practitioners and inject them into the team. But fundamentally, at the program / project level if you’re in this circumstance then you’re probably lacking agile management skills. Often, those that tend to revert miss this point – so to avoid reverting, you’ll need to look to “Learn”.

Often things go off the rails when things start to work at scale – when we had one or two teams working in an agile way, things were fine and we could manage it in that way. When you have to scale across multiple teams, perhaps multiple vendors and bring things together across an organisation, this is often when things start to go wrong. However, at this level it’s not a team problem it’s a management problem. Guess who’s going to get called upon?

Or, another scenario is that you tried to move too quickly too fast. You just can’t get to agility overnight – it takes time to get to a decent level of maturity. If you planned that you’d be “agile” instantly, or very quickly, then you were probably planning to fail from the beginning.

You probably knew this would happen – they should have just done things the old way from the start. In which case you declare “We’re not doing agile anymore, we’re going back to the way we used to do things”. I dare say that things haven’t really changed to begin with – you’re likely using you’re old practices because you haven’t supplemented or replaced them with 21st century knowledge work management techniques. Perhaps you weren’t sure how these could work together or haven’t seen them used successfully.

In this case, you may have a group of really talented agile practitioners at the team level. In this scenario “reverting” will mean they might need to change their behaviours and practices. They likely won’t want to do this and will either resist or leave. In any case, you’ll suffer from an alignment problem or you might stall because the skills have left the organisation. Either way, things are going to get worse before they get better.

If you’ve gotten to the point of reverting, then there was probably already a problem from the beginning and perhaps you should have tried one of the other options such as “Get out” or “Learn”.


If you’ve selected this option – congratulations, you’re about to venture into a new world where you’ll have new skills and understanding of how to manage knowledge work. But the good news is that you don’t have to throw away all of your existing skills – things like risk management & vendor management are still very relevant to agile delivery, it’s just that we view these through a slightly different lens.

You will need to give yourself time and space to learn – you won’t be an expert overnight, so make sure you plan to have the capacity / time to be able to learn. If you’re considering taking on an agile project / program in the future, then this is the optimal time. You’ll have some time to learn what you need to do for day 1 when you land on that program. Often managers new to this type of delivery, don’t set things up from the start. You’ll know from you’re existing skill base that anytime this happens, regardless of the method, you’ll be behind the eight ball from the start.

If you don’t give yourself the time and space to learn, effectively you’re really in the “Bluff” space, you just don’t know it yet. Often people talk about learning, but their actions clearly don’t give enough time and investment in learning so they might not realise that they’ll need to resort to the “Bluff”. If you’re in the learn space, please make sure that you’re actions match your intent, otherwise you might find yourself in a world of pain and stress.

If you don’t have time before you start you’re next assignment, you’re probably going to need some help right away. Find an experienced agile manager / consultant / coach and bring them on to set things up that you’re not aware of. Watch what they do, be curious and ask them along the way why they’re doing what they’re doing – you’ll learn a lot this way.

If others on the program are new to this way of working, you might need to organise similar support / capacity for learning for their roles as well. They’ll be supporting you along the way, so you need to make sure you’re all on the same page.

You’ll need to get an understanding of how to manage down as well as manage up. How do you understand what the teams are doing and how it all comes together towards the aligned goals. Plus, how do you ensure that you make reliable commitments to your stakeholders and customers in this kind of world? You’ll need to understand how to manage these expectations in this different paradigm.

At some point in time you’ll want to understand for yourself how agile systems of work can be created and improved on. Your best bet for this is to actually get some formal training on this, sooner rather than later. To really get the most out of this, you should consider becoming a Kanban Management Professional. This is made up of two courses (Kanban System Design & Kanban Systems Improvement) which will give you a practical foundation from which to manage knowledge work and achieve real agility.


If you’re a project / program manager and you’re new to agile delivery you have some options open to you. However, in the end the only two real options are to “Get out” or to “Learn” – the others are only temporary stop gaps. Although there are many different pathways to learning, you may want to learn about Scrum or XP to understand the things going on at a team level. You may also be in an organisation that practices SAFe, in which case its program and portfolio layers are Kanban anyway, however they tend not to go into enough detail about the particulars of how to do this. Plus, you might have other teams working in non-technology based areas and you need to bring them all together. Kanban can do this for you, so why not go to the source and achieve true agility. Read more about in our blogs, or check out our training programs.


This is something that I’ve been thinking about over the last several years. After experiencing / running some of these events and having seen them played out with various clients I had an instinctive reaction as to the waste behind PI planning. I haven’t had the full language to express exactly the problems with this and how it fits into the overall organisational maturity and growth up until now. Recently, I attended an Okaloa flow simulation on multi-team flow and after stewing on the insights from that for a week or so, whilst planning an inception (I didn’t want to use the PI planning words), I realised a number of connections that I’d like to share with you.

Firstly, as if to contradict what I’ve just said above, even though PI planning is ultimately waste, it can be a useful stepping stone for chaotic / lower maturity agile implementations. I think this is similar to many things in SAFe – some of the practices are useful to begin with, the painful part is when they get hardened and become the norm rather than looking to rise above and find better ways to work. Let’s consider some of the useful points of PI Planning first:

  • It gets alignment (across leadership and teams)
  • It gets the teams to think about their capacity
  • It can help bootstrap the upstream (described below)

Bootstrapping Upstream

This is worthwhile expanding a little. For some teams, they haven’t yet developed or seen emerge Upstream Kanban. The PI Planning event can actually help bootstrap this if it isn’t there. However, often many agilists (yes, even those who consider themselves coaches!) don’t have knowledge of Upstream Kanban, so they miss the subtleties that occur upstream and how it is different to delivery. What is important to understand is that work flow through your overall system – some aspects prepare work for delivery and discard poor options, whilst others build / deliver it. Where flow doesn’t exist, the PI planning event (being large and expensive) creates an impetus to make sure “features” are prepared enough to run through during the event. Often what happens is that during PI planning teams commit to features to deliver, but also determine which features they want to “shape up” for the next event for delivery. This is one of the downsides if you’re not careful – it locks you into a 6 month lead time for features (is this agile!?!). But importantly, teams are concurrent thinking of getting items ready whilst they’re delivering other ones.

Where PI Planning comes unstuck

One of the key parts of where this comes unstuck is that this is usually held every three months. That’s problematic because what occurs at this time is that teams align and commit to a number of work items every three months. The result is that you essentially only get 4 of these per year. Is 4 points per year to plan / change course agile? This is really a large batch transfer that get’s underway and it undermines the continuous flow that was starting to emerge through bootstrapping upstream mentioned above. Agility comes from fast feedback and having only 4 pivot points per year where you can adjust the work based on feedback is the opposite of what I believe the agile manifesto authors were trying to achieve.

Other examples of where I have seen waste with PI planning is when an assumption during planning turns out to be false. I’ve seen this happen within 2-4 weeks of the PI planning exercise and teams in those instances dove back into a PI planning process. There’s a lot of cost involved in getting these PI planning events up and running – when a few assumptions learned down the track causes the whole process to come unstuck, I’ve got to question whether it is the right process.

Whilst working within a “train” is part of the PI Planning, if you have to synchronise work outside of your train then more coordination is needed. I think this comes down to the mechanistic nature of SAFe itself that denies the complex and somewhat organic nature of the organisational network. Although you may be able to predict the nature of interdependencies and organise around that, there’s always going to be new demand that will create new connections in the organisation that you have to deal with. Now we’re talking about pre and post PI planning events to ensure items are synchronised across streams. Again, these are often large events with a multitude of people involved. A couple of problems with that are that, once again, plans can change and you need an intervening process to keep things aligned once underway. Is there a way to achieve the outcome without the large cost of these events?

One key theme from all of this is that we’re committing too early. Whatever happened to the lean thinking that talks about committing at the “last responsible moment”? Now I’ve heard arguments that PI planning isn’t about “committing” but about planning and that plan will change. However, I don’t think that’s in practice what most people take away from it. Particularly so when teams do the “fist of five” – it seems like they’re “committing to the plan” (although the usefulness and safety of this technique is questionable). Alternatively, this perhaps could be argued to be a reversible commitment – that things later in the planning can change. But what’s not readily apparent is the abort costs and other potential waste of this behaviour.

If we were instead to defer commitment until we have capacity to be able to fulfil the order / option, then we have greater flexibility to deal with unexpected events with greater clarity for all. Oftentimes, we see urgent work enter the system after PI planning – this causes other work to either be paused, postponed or even aborted. All that time we spent planning and now we have to replan for this new item. We also have to reset expectations about when those other items will get delivered. Perhaps we shouldn’t do such detailed planning for items down the road, perhaps there’s another way to schedule / commit to work.


Replace “Plan” with “Forecast”

I think that the word “Plan” inherently has issues with it. When people hear the word “plan” the often associate it with a commitment. This gets the expectations around the event confused and misunderstandings will arise. Instead of using “Plan”, use the word “Forecast” and give a likelihood of something being done. For example, say something along the lines of “on average our features take 65 days to deliver, and we can deliver 90% of them within 110 days”. Note the difference between the average and the 90th percentile – it allows for the potential that an urgent item might slip into the flow and delay it – and there’s also a chance that it can take longer. This also requires teams to capture some basic flow metrics – again something else that might need to be bootstrapped through the process before you can rise to this next level. However, this gives stakeholders a much clearer understanding of when something will actually come their way.

Enable flow

Once the upstream has been bootstrapped, you can start to move away from the “stop/start” nature that tends to occur with PI Planning. This tends to be more of a batch transfer than flow and will start to impact the organisation’s real agility. Start to look at your flow and impose some WiP limits around the parts of the process – batch transfers happen when there are no WiP limits around those parts. Doing so will create a more sustainable pace for your teams and allow you to defer commitment until you need to make those decisions.

As your deployment practices mature, you’ll find that you’ll be able to start to deploy on demand. It begs the question why you can’t replenish on demand in the same way. Why would you want to wait for the 3 monthly cycle to pull new work in? The answer is that you probably shouldn’t – the problem is that the transaction costs of replenishment via PI Planning are now too high, so it’s probably best you avoid those costs and find a better way.

Continuous improvement inherently built in

One of the other problems with PI planning cycle is the “Planning and Innovation Iteration”. This totally goes against the ideas of flow and continuous improvement. Using the last iteration of the PI for this is inherently bad. What tends to happen in practice most times is that this gets left out when initiatives run into risk / dark matter expansion and have to fill it with work anyway. Also, leaving all innovation to one single point in time seems contrary to how innovation actually works.

Instead, plan in time along the way to do the preparation of new items and to include innovation as a matter of course – part of the weekly workload. At the team level, you can allocate capacity to intangible class of service items on the board to cover off innovation items as they’re needed (usually it’s own card colour or swimlane).

Tokens guide capacity

An alternative that was made clear to me through Okaloa flowlab simulations, was that you can use tokens to guide capacity and commitment. Teams understand how many features they can build concurrently and offer that many tokens. Let’s say it’s 4 concurrent features. They work on 4 features and when one is done, they have a free token. This token is then available for new commitment. When a new feature is ready that requires the token (usually it needs tokens from a few teams) that new token can be allocated to the feature and it can be started (once tokens from all teams required are available).

This is a simple solution to allowed deferred commitment and reduced transaction costs from PI planning and will ultimately help the agility of the organisation. Oftentimes, teams in SAFe style arrangements don’t have a very good understanding of their capacity – or they have to do lots of estimation and need other details to understand it. The tokens provide a simple way to understand capacity without the need to go into detailed estimation.


PI Planning builds in large transaction costs and creates batch transfers which are waste. Both of these effects can impact your organisation’s agility in the long term. These events can be useful in the short term to provide alignment and help bootstrap flow. You should avoid hardening in such costs and anchoring your agility and instead take it to the next level by concentrating on how to enable real flow in your organisation. There are other alternatives and you should look at how they can be implemented to help your people, your customers and your organisation’s strategic objectives.


This is a format of retrospective I first started using in around 2013 and still use it today to help teams understand their work and the system of work in more detail. It’s particularly useful for teams starting out with Kanban and can be used as not just a reflection point for the team, but one for coaching and learning. It’s fairly simple and doesn’t need a lot of preparation – you can just go with this on your next retrospective.

It’s called the campfire retrospective because essentially the team gather around the board like a campfire and tell stories. You look at the board and prompt with questions like “what’s going on here” and let the team tell the story. I also often ensure that key data such as lead time distribution / scatterplots are to the side of the board so we can discuss this in relation to the stories on the board. After telling a few stories and understanding some more of what’s going on, you can start to adjust your board right there in the retrospective. Here are some things you can look out for / prompt for:

  • Does the workflow look correct or should we adjust it?
  • How are the WiP limits going – do we need to adjust?
  • How’s collaboration – are people helping each other to achieve better flow?
  • Are any items blocked and what’s causing it?
  • Are we seeing some key repeating dependencies?
  • Are there any new work item types or classes of service emerging?
  • Are the policies working or do we need to update them?
  • What is the data telling you?
  • Are recent changes working as you expected or do we need to adjust again?
  • What are the customer expectations and interactions around the tickets?

There are so many things that you can look at and talk about around the Kanban campfire. Importantly, once you discuss these issues, you should look to make improvements. Some you can make straight away – for example to adjust the policy just do it there and then on the board. Others you might need to add a task to the board to track a larger improvement body of work.

This is a simple form of retrospective that often provides a great way for the team to collaborate and improve. Often they may start this with improving the system to help the team, but over time, you’ll find you can shift this to help them focus more on the customer outcomes with their Kanban system. The other thing that’s great about this is that you don’t need a permission to get started – you can just schedule this for your next retrospective and watch the team take ownership and leadership. Have you tried the Kanban campfire retrospective yet?


Something that I hear quite regularly, even throughout the agile community, is the perceived need to get better at estimation. Often in responding to areas of uncertainty, we attempt to add some level of control or certainty – particularly to delivery. I think that in many cases when I hear this, we’re actually solving the wrong problem.

Firstly, to the problem – do we actually understand the problem we’re trying to solve? In many cases this is a key point – any estimate will be based on the understanding of a problem and oftentimes, we don’t understand the problem well enough to be able to do this with any accuracy. In those circumstances, it’s not really worth estimating because we need to explore the problem space some more. Perhaps it’s a case that you’ve prematurely converged into the solution domain and need to get back to the problem domain. Often this occurs, because answering the questions in the problem domain are hard – perhaps it’s more about what experiments / spikes / customer trials should we run next to understand the problem some more before considering estimates.

In exploring the problem domain, it’s likely the case that you haven’t sliced the problem enough to be able to create focus and understanding. This makes it increasingly difficult to provide estimates because the domain is so broad. Spend more time creating alignment and focus on a more narrow scope and the estimation will inevitably be better as you have less uncertainty.

Estimates are often given as a single number – “it will be 6 months for 3 teams” or something of that nature. It doesn’t take into account or demonstrate the uncertainty in the domain – both in terms of problem domain and complexity of coordinating through the organisation to deliver the outcome. What if it was something along the lines of 4-8 months for 2-4 teams. Or perhaps something like “there’s a 80% chance of finishing within 6 months with 3 teams and 95% chance at 8 months with 6 teams”. Using a single number cuts down the conversation around risks and lulls stakeholders into a false sense of security. Starting with understanding and dealing with key risks up front gives you a greater chance of achieving the outcome – or stopping early if the outcome is not a viable option.

Furthermore, even in delivery maybe your estimates are not your largest issue. Quite often, I find in terms of medium to large organisations, there’s generally a low flow efficiency. Estimates usually pertain to effort rather than lead time. If you have a flow efficiency of 10%, then how much better off are your really by trying to get a better understanding of the 10%? There’s a point of diminishing returns and in this case it’s basically straight away for that kind of activity. You’re better off spending your time dealing with the blocking / wait states that are impacting the 90% of your lead time than getting better at estimates.

I often hear the cry that “we have to get better at estimates”. However, this is usually a symptom and the cause is likely elsewhere in your system of work. Take some time to get to understand the system of work and be more specific about the problem you’re undertaking to solve and you’ll likely avoid the discussion about estimates altogether.


Story points is a journey that I started about 15 years ago. For teams starting out with agile, many think that you have to use story points as a “sign” of “doing” agile. I’m not so sure that’s the case. I first started with story points years ago, but over the last 5+ years I’ve started to stray away from them. I question the value of this technique and so should you.

Story points are relative values of sizes of work – an estimated value. I like to go back to some old texts like Mike Cohn’s “Agile Estimating and Planning” when understanding what were some of the original ideas behind story points where he talks about a “A user story estimated at ten story points is twice as big, complex or risky as a story estimated at five story points”. This implies that “size” in the estimate includes not just how big it is, but how complex something is and if there’s any / how much risk is associated with it. Now we’re dealing with multiple dimensions in the one value – this overload of meanings can often lead to issues.

The other point that gets me is that story points is an estimate. It’s our best guess at what might happen. When you’re measuring velocity your counting up how big “you thought things were”, not how big things actually were. All the bias and unknowns your team can’t see don’t factor in at all. For me, I’d rather deal with the actuals that describe team capability rather than guesses when making commitments.

There’s also another level of indirection with story points – at the end of the day your customers don’t care about how many points something is. They care about how long it’s going to take and / or how much it will cost. To figure out duration (and ultimately cost), you need to use something else known as velocity – ie how many points the team can get through in a given timebox. If you’ve been around agile teams for a little while, you’ll notice that their velocity is often not constant – you can often get a “saw tooth” chart if you track velocity per sprint. So how do you figure out what the estimated velocity is? Well, often teams take a “3 sprint rolling average” to figure that out. My big concern is that there’s so much indirection going on here that it can be hard to predict accurately using this mechanism.

Where I find story points valuable, is where teams, particularly when they’re just starting out, talk about the work and get an understanding of how big items are and “where the dragons are”. The conversation and understanding is valuable, the estimate becomes fairly meaningless after that. Indeed some teams I’ve worked with who were already using story points, all I cared about is that they wrote a number on the card. To me, that was a signal that they had that valuable conversation.

So what should you do instead? Perhaps just count the number of done stories or work items per timebox. Perhaps you don’t need to use the quasi-standard 2 week sprint boundary either – count items per week or per month. That’s what’s known as throughput or delivery rate. Getting an understanding of throughput and how to use it can be useful, because you get away from the agile abstraction theatre and start talking about things in the same language as your customers. Some time ago, Neil Killick stopped by the Melbourne Kanban Meetup to talk about slicing heuristics – you might want to consider this in lieu of doing story point estimates.

Should you be using story points? If you get some value out of them, then yes go right ahead. But please don’t do it because you think you have to in order to “be agile”. Here’s a safe to fail experiment to try – don’t change anything except look at you throughput count over the last several time periods. If you don’t have that data collect it for the next month or so. Compare that to story points – if you think you can predict through throughput, or lead times for forecasting, then perhaps you don’t need to estimate in points, you can use your actual data!


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.


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):


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.


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.


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.


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.


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”.


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.


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.


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.