This leaves us with a hole in the ground, in the shape of a tree. Tunnels where the roots used to be but with no obvious reason to be present. If you hadn’t known that a fire had come through, you wouldn’t understand why this hole was there or what the tunnels were for.

This particular picture was taken a year after a forest fire had raged through the Kelowna area, where I live. All that’s left is the hole, although you can see that nature is returning and that some flowers are now growing where the tree used to be.

Organizations leave the same kind of imprints. When a process, a system, or a person is removed, the shape of what was there often remains as review steps that nobody questions, signoffs that slow everything down, and manual steps that everyone agrees are unnecessary but nobody is willing to automate.

The most common cause I’ve seen is some kind of production outage. Something goes wrong, people panic, and a gate gets added. A mandatory sign-off. A required review. A checklist before deployment. These gates are designed to prevent that specific thing from ever happening again, and in the immediate aftermath they make good emotional sense (although often not logical sense).

The problem is that they’re rarely revisited. The incident fades from memory, the people involved move on, and the gate remains, and nobody remembers why.

Sometimes the gate was never really about the risk at all. It was about a specific person who got burned, or who got yelled at by their boss. The process existed, in part, to protect them. When they leave, the emotional logic of the process leaves with them but the hole remains.

I was once in a meeting of senior people at a bank, discussing whether physical signatures on paper forms could be replaced with electronic ones. The legal team had already weighed in: electronic signatures provided just as much legal protection as the physical ones, and yet nobody in the organization was willing to sign off on dropping the physical signature requirement. There was too much personal risk for the person who would make that decision.

If you remove the requirement and nothing goes wrong, nobody notices. However, if you remove it and something goes wrong, you are now the person who removed the safeguard. The fact that the safeguard wasn’t actually providing any protection is irrelevant to your career. So the rational move for each individual person is to leave it in place; even when everyone in the room agrees it serves no purpose.

This is how imprints persist.

If you’re experiencing unexplained friction in your organization, steps that feel like they shouldn’t be there, approvals that nobody can justify, processes that seem to exist for their own sake, it’s worth asking what used to be there. There’s usually a hole in the ground. Sometimes there’s a tree still smoldering. And occasionally, if you look carefully enough, you can find someone who remembers the fire.

If you’re in a position to remove these imprints, the good news is that in my experience it rarely backfires. The processes are usually not doing what people think they’re doing. The harder problem is getting anyone to accept the personal risk of being the one who removed the safeguard. That often requires someone with enough organizational authority to absorb the risk, or enough credibility to make the argument that the risk was never real to begin with.

The flowers in that photograph are growing where the tree used to be. Nature isn’t sentimental about the hole, and we shouldn’t be either.

There is one big exception to this approach however, and it just came up in a conversation.

That’s when we’re trying to fix a morale problem. Many companies will start by trying to visualize “team happiness” with something like a Niko-Niko calendar, and this can backfire spectacularly.

First, the companies that try to track happiness/morale, already know they have a problem or they wouldn’t have asked for this. Second, when the results come in and show that teams are not happy, management rarely does anything positive to address that. Why do I say that? Because the companies that already have a good plan to address morale/happiness, don’t start by asking people to quantify how they feel.

So now we’ve made it really visible that there’s a morale problem, and that we’re not willing to do anything about it, so morale drops even further, which gets even lower scores, which we again do nothing about.. and it spirals downwards.

So now when I hear a company say they want to start tracking happiness, I ask them what specific actions they’ll take when the results show that the teams are not happy. If they don’t have a solid plan already, I advise them not to track it at all. If you’re not prepared to fix it, don’t make it visible. That’s just going to make it worse.

We didn’t know how long we’d have before the approval arrived so we started with a bit of training on technical practices and then started working all together (ensemble work) on reviewing and improving their existing code. We refactored the code to make it cleaner and more maintainable, and improved the automated testing. We optimized their build pipeline and got them ready for continuous delivery (CD), something they hadn’t previously considered.

When the legal approval came along a few weeks later, this codebase was already in far better shape than when we’d arrived. The code was cleaner, there were fewer bugs, and all the team members had a better shared understanding of everything.

Additionally, this new service was released on a working CD pipeline, releasing to production on every commit.

How was this all possible? The most significant reason is that for the first time, they had no delivery pressure. Nothing was splitting their attention twenty different ways. Nobody was insisting that they work on multiple things at once, or watching to make sure they were busy.

Their only goal was improving what they already had. They had time to focus on the quality of the code. They had time to optimize their pipeline. They had time to learn new skills that they didn’t already have.

And then they delivered something amazing.

The most frequent objection that I get to new improvement activities is “delivery pressure”. We’re too busy to do that now. The problem, of course, is that no matter what we might tell ourselves, that pressure is never going away. We won’t have time to improve unless we make time.

If we don’t improve then we’ll continue to deliver at the same rate that we were delivering before. If we do improve, we’re likely to deliver much faster than that. There is a cost to not improving, and it’s one we often disregard.

If that team at the beginning hadn’t taken a few weeks to fix their system then they’d still be responding to quality issues the way they always had. They’d still be manually deploying the way they always had. They’d be just as busy, and as ineffective as they always had been.

They were lucky. A legal complication had given them an amazing opportunity to improve and they did. Other teams aren’t as fortunate and don’t have that slack time handed to them.

If we want to improve, we have to make the time for that, regardless of how much delivery pressure we might feel.

See also:

• Tom DeMarco’s classic book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
• Playing the long game

I expected to see a lot of answers along the lines of:

• I don’t know what that is or how it would help me.
• I know how to use the Monte Carlo but don’t understand the math underneath it and therefore can’t trust the answers. [How it works]

While I did see some of those, the answers were mostly full of people who very confidently said they understood Monte Carlo and then gave reasons for not using it, that clearly demonstrated that they don’t, in fact, know how it works.

ProKanban decided to debunk some of these misconceptions so earlier this week Colleen Johnson, Benjamin Huser-Berta, and I recorded a session together. I’ll link to that when it goes live.

First of all, let’s define what the problem is, that we would use a Monte Carlo simulation for. Monte Carlo itself is a general statistical tool that can be used for a variety of purposes. In this case, we’re using it to determine one of two things:

1. Given a number of work items, how long will it take to complete?
2. Given a defined end date, how many work items can we complete between now and then?

The Monte Carlo will use historical data to make a probabilistic forecast about the future. The fundamental assumption here is that the future is likely to look like the past. If we’re starting something now that is completely unlike what we’ve done in the past then that assumption will not be valid.

On the other hand, if we’ve been doing software development over the last three months and we expect to continue doing software development for the next three then the assumption holds and this can give us a highly accurate forecast.

Now what’s this probabilistic part? The answer that a Monte Carlo will give us is made up of a percentage and a range. “There is an 85% probability that we’ll be done on or before October 1”. The opposite would be a deterministic answer like “We’ll be done on October 1 at 3:05pm”. While our brains prefer a deterministic answer, the more accurate one is probabilistic.

Back to the Reddit posts

Too much work

A couple of posts stated that doing a Monte Carlo was too much work compared to estimation, and that you wouldn’t learn anything more than the estimation would give you.

First of all, nobody is ever going to calculate a Monte Carlo by hand. You’re doing to use a tool for it. If you’re using a built-in tool like ActionableAgile then it’s a small number of minutes to get the first results.

Even if you’re using a spreadsheet, like the one that Troy Magennis gives away for free, it might be half an hour to get the first forecast complete, as you’re having to copy data into the spreadsheet, and then a small number of minutes for each subsequent one.

Unless your idea of estimating is sticking a finger in the air to see which way the wind is moving, the Monte Carlo will always be faster.

Too much data required

There were a number of posts that incorrectly claimed that lots of different data points were required as input. Things like “average time”, “standard deviation”, and “correlation between each task”.

In fact, we need none of those. All we need is historical throughput. How many items did we complete last week? How about the week before that, and the one before that. All we need is throughput, although we do want enough data points. With eleven data points we have a fairly accurate forecast, although I usually aim for 15-20 data points.

Shifting priorities

One person said “priorities shift way too fast for the math to stay relevant”, which sort of misses the point of what any kind of forecast or estimate gives you. The forecast tells you how many items you can complete, not which specific ones you will do. Once you know how many, you still need to prioritize effectively.

Not culturally accepted

A couple of people brought up the perception that a probabilistic forecast may not be accepted by management as they want that deterministic answer instead, and that’s a valid point.

The probabilistic answer will be more accurate than the estimate, and less work to prepare, but if the culture in your company isn’t willing to accept it then you’ll need to fall back to the less accurate answer instead.

Conclusion

What I took away from this exercise is that there is an incredible amount of misinformation around Monte Carlo and probabilistic forecasting in general. It’s a lot easier than most people seem to think, requires less data than people assume, and is a lot more accurate than traditional estimates.

Is it always the right tool? Of course not, there is no tool that works in 100% of the cases. Monte Carlo does assume that we have a relatively stable system and that what’s happened in the past is a reasonable predictor of the future. If either of those isn’t true then it’s the wrong tool.

If we don’t have any of that historical data, then there are still other probabilistic approaches that might work however, like reference class forecasting.

I’m sure you’re thinking “but I can be angry or sad for hours or sometimes days at a time”, and what’s happening in those cases is that you’re continually retriggering those same emotions over and over again. It’s not the same chemical release over a long time, it’s a continual retriggering of those chemical releases.

What does that mean for practical purposes? It means that if we can interrupt the patterns that we’re following, we’ve got at most another 90 seconds to put up with those negative emotions before we start to feel better.

Why do I only mention negative emotions? Because I’m assuming that you have no interest in interrupting happy emotions. Let’s let the happy ones continue to run.

What could that interrupt look like? It could be as simple as the phone ringing and grabbing your attention. It could be movement to shift your state, particularly movement into a different environment such as walking outside. Just standing up and shaking your body can be a powerful interrupt.

For even more powerful interrupts, almost any of the techniques that I show in the Anxiety Reset will help here. I teach them in the context of anxiety but they’re powerful interruptions and will work in other situations too.

When you’re feeling those negative emotions for long periods of time, you’re just running habitual patterns in your brain, and those patterns can be interrupted.

What’s even better is that the more often we interrupt those patterns, the less we’ll run them. This is just another aspect of Hebb’s law: “Neurons that fire together wire together”. The more we run the same patterns, the stronger they’ll become. The more we interrupt them, the weaker they become.

A related trick is to label emotions when we notice them. The simple act of saying to ourselves “I am feeling angry” or “I am feeling sad” will weaken that effect on us. This technique is called “affect labeling” and is surprisingly effective.

“Behavioral and neuroimaging studies suggest that merely putting feelings into words can serve as a regulatory strategy”
— Levy-Gigi, E., & Shamay-Tsoory, S. (2022). Affect labeling: The role of timing and intensity. PloS one, 17(12), e0279303.

The key point here is that if we’re regularly feeling emotions that we don’t want to feel, there are ways to lessen that, and many of them are quite simple to do.

Standard disclaimer: There are no approaches that work for all of the people, all of the time. If what you’re trying isn’t working for you, perhaps you should seek out a professional to find approaches that will work in your context.

Make the hard decision. Either we’re going to fix it and we do it now, or we aren’t and we cancel it.

Letting that bug sit in a backlog somewhere in the hopes that someday we’ll have the time and interest to fix it is just delusional. We’ll never have time for low priority distractions, and keeping things around “just in case” is exactly that.

Most companies have hundreds, and I’ve seen systems with thousands, of bugs just like this. They’re noise that distracts us. We need more focus and clarity, not more distractions.

Fix the bugs, or accept that we won’t, and close them.

Indecision is waste.

Are you really going to look at fifty of those on a regular basis? You might for the first few days or even weeks, and then you won’t anymore.

I had an executive once ask me to email a freshly generated 250 page report every hour through the day to his cell phone, so he could keep an eye on things. It took far too long to convince him that this was not a good use of anyone’s time and that in any case, it was giving him entirely the wrong level of detail.

At the opposite end, I had one client that had automated six key metrics to be sent to all senior leaders every 45 minutes. Six simple numbers from which they could tell at a glance if everything was running smoothly or if they needed to refocus their attention.

Another client had a large wall of metrics and analytics on monitors beside the exit. Anyone leaving the building could see at a glance if everything was ok or if there was something needing their attention before they left.

These are all examples of realtime, or near realtime, metrics but not everything has to be that fast. If we’re looking at the speed at which a software development team is completing features, looking at metrics even once a week might be too often.

If we’re looking at value delivery and whether we built the right things for our customers, even quarterly might be too often.

So we need to consider not only what we’re measuring but also how frequently we review that data.

At a high level, there are three main groupings of metrics that I normally want to start with.

Flow metrics tell us if the work is moving through the system. I usually start here, partially because they’re the easiest to measure, and partially because they will uncover a huge number of the problems with little effort. If the work isn’t getting done then really nothing else matters.

Value metrics tell us if we’re spending our money wisely. Are we doing the right work? Are we doing it at the right time? Is it of the right quality?

Sustainability metrics tell us if we can continue at this rate indefinitely or if we’re just running towards a cliff and going to crash.

I tend to look at flow metrics regularly as they give me immediate feedback on the health of the system. Value and sustainability tend to be longer term views into the system. They take longer to collect and are reviewed less often.

What do I almost never care about? How busy we are. Busyness is not a proxy for either effectiveness or efficiency, and I’ve written about that before so I’ll leave it today.

So I start with “is the work moving well?”, followed by “is the right work?”, and finally “is what we’re doing sustainable?”

For each of these, I want to find a small set of metrics that give me a glimpse into the system. I don’t want too many different measurements as that becomes overwhelming and I don’t want to have too few because then they’re easily gamed.

Not sure what you should be measuring in your environment? Let’s talk.

My argument is that code coverage is a great negative metric, in that at low values, it tells you useful things and at high values it tells you nothing. So mandating high numbers is not giving us the benefit we think it is, and in fact is often causing people to game the numbers.

Fresh off that, I just made a change to one of my own source files that had 100% code coverage, and no tests broke.

No, this was not an attempt to prove anything. I was fully expecting one or more tests to break when I did this.

The fact that nothing broke is quite honestly shocking as I thought this code was quite well covered. It does prove my point though.

Code coverage is great feedback to developers; it’s an indicator of where they should put their attention. It should never be a target.

Update: And to the surprise of nobody who believes in good tests, as I add more tests around this particular code to cover the edge cases that were missing, I’ve just found a bug.

However, for the second tasting, the jams were switched and the subjects were trying the jam that they had rejected, not the one they had picked. Two thirds of the participants didn’t even notice that the jams were switched and happily justified why they had selected this new jam. This happened even when the flavours were as different as apple-cinnamon and grapefruit!

I’ve talked before about how “why” questions can be problematic and this is a perfect example. In this case, the people were doubling down on an answer that was completely wrong. This was not the jam they’d picked the first time, and yet they were completely convinced that it was, and were happy to provide justification for what they considered to be good decision making.

This particular effect is called choice blindness, and is defined as a cognitive bias where people fail to notice that the outcome of a decision differs from their original intention, often fabricating justifications for the manipulated result.

But it doesn’t stop there; the experiment had one more twist. When this was all done, they were given a questionnaire asking about their own decision making process.

“Among other questionnaire items, the subjects had to say exactly how they thought they would feel if they had participated in an experiment that tricked them in this precise way. Of course approximately 90% of the subjects said they would never fall for such a trick.”

Not only are we easily tricked, we’re highly confident that we can’t be tricked, and that blinds us to our own weaknesses.

If we want to make better decisions, we need to be very deliberate about that. It’s too easy to convince ourselves that we’re already great, and then to not notice when the decisions we made are actually quite poor.

Your first contact with details on sprints is likely to be in the issue history. In here, there is information about what sprints this issue is in.

What’s that you say? “How is it possible for an issue to be in multiple sprints?” If it doesn’t finish in one sprint and that sprint ends, its still considered in that one forever. Then you can add it to another sprint and now it’s in two. Repeat as often as you like for a never-ending set of sprints for a single issue.

I’ve seen issues that have been in over a dozen sprints because they never get finished and just keep carrying over from one sprint to the next. Yes, that’s completely dysfunctional and should never happen. Yet, it happens all the time.

The entry in the history might look like this.

{
  "field": "Sprint",
  "fieldtype": "custom",
  "fieldId": "customfield_10020",
  "from": "76, 79",
  "fromString": "Sprint 12, Sprint 13",
  "to": "76, 80",
  "toString": "Sprint 12, Sprint 14"
}

Field ID

The first thing you might notice is that there is a fieldId, which most history items don’t have. This is a reference to the custom field (in the same document) that contains more information about the sprints that are referenced. That custom field may or may not exist. If it does exist, it will list information about one or more sprints and the sprint that you care about may or not be in that list.

Got it so far?

If it does all exist, it will look something like this, and you’ll see that it contains some useful information about the sprint such as start date, end date (which isn’t what you think it is), and completed date.

You might think that endDate is when the sprint actually completed but no, that’s completedDate. endDate is the date that you anticipated closing the sprint at the time you started it. Why are there two? I assume it made sense at one point.

"customfield_10020": [
  {
    "id": 10,
    "name": "Scrum Sprint 10",
    "state": "closed",
    "boardId": 2,
    "goal": "",
    "startDate": "2025-03-12T01:36:46.600Z",
    "endDate": "2025-03-23T17:32:42.000Z",
    "completeDate": "2025-07-13T16:58:25.335Z"
  },
  {
    "id": 43,
    "name": "Scrum Sprint 11",
    "state": "closed",
    "boardId": 2,
    "goal": "",
    "startDate": "2025-07-13T17:37:23.922Z",
    "endDate": "2025-07-25T09:33:21.000Z",
    "completeDate": "2026-01-22T16:02:01.486Z"
  },

Multiple sprints at once

The next thing you might notice is that unlike every other history type, the from and to values allow for multiple values.

{
  "field": "Sprint",
  "fieldtype": "custom",
  "fieldId": "customfield_10020",
  "from": "76, 79",
  "fromString": "Sprint 12, Sprint 13",
  "to": "76, 80",
  "toString": "Sprint 12, Sprint 14"
}

You might think that this history entry is telling you which sprints this item has been added to or removed from and in a roundabout way, it does.

You can see in this sample that this issue was in sprints 76 and 77 and is now in sprints 76 and 80. It’s always talking about the current state so we can infer from this that…

• It used to be in 76 and still is, so nothing changed
• It used to be in 79 and now it isn’t, so it’s been removed.
• It used to not be in 80 and now it is, so it’s been added.

When you’re parsing those, it’s pretty easy to parse the from and to fields because they’re just numbers separated by commas.

The fromString and toString fields are harder though because it’s all concatenated text, and since commas are allowed in sprint names, you can end up with commas in the middle of a name.

“Surely they would escape the commas in the text so it can be easily parsed”, you say! They do not.

If you want unambiguous names, you need to parse the id and use that to index into the data in the custom field above. Of course, we’ve already learned that the sprint you want may or may not be there.

If it isn’t there then we have a separate API to get sprints, which is great. Except that it may not be there either. We’ll get there in a moment.

Remove before add

There’s a lovely gotcha where an issue can be removed from a sprint before it was ever added. This happens when the issue gets created within the sprint. Jira considers it to be in that sprint but there is no record of it being added in the history. Then if it’s removed from that sprint, you’ll see the removal all by itself.

The sprint API

This API will return all (mostly) of the sprints for the current board. /rest/agile/1.0/board/{boardId}/sprint

{
  "maxResults": 50,
  "startAt": 0,
  "total": 1,
  "isLast": true,
  "values": [
    {
      "id": 1,
      "self": "https://improvingflow.atlassian.net/rest/agile/1.0/sprint/1",
      "state": "closed",
      "name": "Scrum Sprint 1",
      "startDate": "2022-03-26T16:04:09.679Z",
      "endDate": "2022-04-09T16:04:00.000Z",
      "completeDate": "2022-04-10T22:17:29.972Z",
      "createdDate": "2022-03-26T16:03:49.814Z",
      "originBoardId": 2,
      "goal": ""
    }
  ]
}

I’m sure you’ve picked up by now that even this API doesn’t return all the sprints, although it often returns more here than we have in the custom field.

In my testing so far, it seems that it does return any sprint that actually has an issue in it. Any sprint that’s empty will not be returned, which is annoying.

Conclusion

So in conclusion, like all the other Jira API’s, there is useful data in here but its inconsistent, incomplete, and poorly thought out.

Other articles about the Jira API:

• Intro and authentication
• Issue history
• Statuses
• Board details

See also the JiraMetrics tool, which is the reason I’ve had to learn the idiosyncrasies of the Jira API. If you just want access to the data then let JiraMetrics do it for you.

The four flow metrics that we typically start with are Throughput, Cycle Time, WIP, and Work Item Aging, and all of them are measured relative to the start and stop points. Without clarity on those two points, none of the metrics will be helpful.

So where do we really want to measure those?

At a high level, there are two parts to the start point (Ready). Someone representing the business has agreed to spend money on this work, and the team understands what they’re being asked to do. It’s worth noting that the team does not need to understand how they’re going to do the work yet. Figuring out the how is part of doing the work and happens after the clock has started.

Our stop point is similarly simple, we aren’t coming back to this work. What does that mean? If it hasn’t been tested yet then it’s highly likely that we are coming back to it because we don’t know if it works yet. We stop the clock when we have a reasonable expectation that we are not coming back to this work.

Each team will likely have more specifics that they want to capture, to provide a checklist of the things required for each of those two points. Perhaps the code must be checked in, reviewed, and merged before we can say we’re doing. All of this is towards satisfying the high level point of we aren’t coming back to this.

A common mistake made with both of these points is that individuals think that the points are measuring them personally, when in fact the measurements are about the work. We don’t care that a developer finished coding, the work isn’t done until other people have done their work as well.

This also holds true for the start point. I’ve seen lots of teams count the work as started when a developer starts coding, yet the work usually started well before that. Has the team not already had discussions about this work during a refinement/planning meeting? The moment we committed to doing the work is when it started, not the time we touched some code.

Many people want to defer the start point as long as possible to make the numbers look good. What we really want to do is make the reality visible so that we can start improving it. If we held a refinement meeting a month ago and brought the work to ready at that time, then the work has been started for a month, whether or not a developer has touched it since.

We don’t like that because it makes the numbers look bad, but instead we should be happy that we’ve just identified problems in the workflow. Why did we refine the work so early? All we did is build up an inventory of tickets that we aren’t working on, and inventory is one of the classic wastes in Lean.

If the work has been fully refined, the clock should have started. If we’re not coming back to it, the clock should have stopped.

Always remember that we’re not collecting metrics for the sake of being busy. We’re doing it in order to make better data-informed decisions. Better decisions require a better understanding of the system, and that needs accurate measurements.

See also:

• If you’re trying to get flow metrics out of Jira, take a look at my own JiraMetrics.
• If you just want to learn more about these four metrics then check out my online course Flow Metrics Basics for Agile Teams

Frequently when I talk about that, everyone nods their heads and then immediately makes a target out of the measures they’re looking at. It’s harder than it sounds, to get this one right.

Let’s look at an example. Let’s say that’s we’ve decided we want better code coverage for our tests. We want the confidence of being able to make a change to the code and knowing that if we made a mistake, the tests will catch that. Having a safety net like that, has huge value to the organization.

So we might measure code coverage as a percentage. How much of the production code is executed during a test run?

That’s a reasonable measure, that we can then use to make some decisions. Not as many good decisions as people normally assume, but still a good measure.

The gotcha is that many people will then immediately turn it into a target. If we’re currently at 60% coverage then someone might decide that we need to increase that to 80%.

As a measure, it was great. As a target, it’s horrible as it now encourages people to add tests that increase the test coverage numbers, whether or not those tests improve the original goal of having a better safety net.

You might be thinking “nobody would game those numbers in my organization”. They will and they do. Code coverage in particular, is gamed everywhere.

Lou Gertsner, former CEO of IBM, has famously said: “People don’t do what you expect, they do what you inspect.”

What might it look like if instead of making code coverage a target, we’d left it as a measure?

We might have hypothesized that if we adopted Test-Driven Development, that might improve our safety net. So we could try that for a period of time and then looked at code coverage as an indicator of whether we were improving or not. Not a target, but an indication of the direction that we were moving in.

An interesting thing with humans is that the first problem we bring up is rarely the real problem. For the browser to have timed out, that means the user had probably already been waiting for five minutes. No wonder they were unhappy.

The fix in that case was to replace 4000 lines of Java code with a page and a half of SQL, taking the execution time from 5+ minutes to roughly a tenth of a second. While the technical details were interesting, for this post I want to focus on the framing of the problem.

They approached me with a problem that wasn’t the real problem. Had I just taken that at face value, we would have found some browser setting to make the timeout longer, and while that would have solved the immediate problem, it wouldn’t have made the users any happier.

Why do we do this? Why do we focus on the wrong problems?

There are a couple of reasons. One is what Daniel Kahneman called System 1 and System 2. Our brains have evolved to optimize for energy consumption and System 1 is very fast and uses very little energy. System 2, on the other hand, is much slower, uses much more energy, and is therefore less desirable. Wherever possible, our brains prefer to use System 1 to make decisions.

Unfortunately while it’s fast, System 1 is often wrong. The example above is a perfect example of System 1 thinking: “Let’s just extend the browser timeout”.

What I did in this case was to ask the kinds of questions that force us into System 2. “How could we shorten the entire time so that we don’t need to change the timeout?” Or “what’s the bigger problem we’re trying to solve?”

Questions that can be answered with yes/no, and questions starting with “why” will tend to keep us in System 1 so we want to avoid them. We want open ended questions and those often start with “how” or “what”.

The key to remember is that the first problem is rarely the real problem. Ask some questions. Dig a bit deeper. Force us both to use System 2, so that together we can find a better answer.

⮕ More on Systems 1 and 2

Another related reason for focusing on the wrong problem is called Attribute Substitution. It’s when we’re faced with a computationally difficult problem, and our brains unconsciously replace that problem with a computationally simpler problem and we solve for that instead. We’re usually not even aware that we’ve done this because it’s happened entirely at an unconscious level (System 1).

The good news is that the same questions that will switch us to System 2, will also help us identify that we’ve been tricked by Attribute Substitution, and will allow us to refocus on the real problem.

⮕ More on Attribute Substitution

In this particular case, we ended up with a solution that made everyone happy. That only happened because we were able to step back and see the problem through the lens of System 2.

Side note: I want to point out that while it’s phrased as being Scrum specific, this is equally applicable to a kanban team.

My immediate answer was yes, but it requires some context to understand why.

The daily scrum is without a doubt, the simplest of all the scrum meetings, and yet it’s one that’s frequently done very poorly. The question was specifically about a “mature” scrum team though, so let’s assume that they know how to do this meeting well.

What would this meeting look like if it didn’t need facilitation?

People would show up at the appointed time, they’d look at the board and decide which was the most important item. Then someone who knew about that item would talk about it and when they were finished, the team would move on to the next most important item and talk about that. When all the items had been discussed, the meeting would disperse. Nobody would have needed to be prompted. Nobody would have needed to be reminded to share the screen. Nobody would have talked too long, or drifted off topic. Any one of those things would have required facilitation to get back on track, and we’re talking about the case where a facilitator isn’t needed.

Is this nirvana even possible? Sure, I’ve seen teams do this for a couple of days, where they stay really focused and keep each other accountable. Then they get tired or distracted and start to let things slide. The key is that although it’s possible for a short time, it doesn’t last.

That’s why we need facilitation. There needs to be someone, or a couple of someones, to keep everyone on track, to move things along when they start to stall.

Does this imply that we need someone with the title of facilitator? No. When there is no designated leader, a natural leader will emerge from the group, and that person will either start facilitating themselves or will ask someone else to do it. This is normal team dynamics.

Interestingly, even when there is a designated leader, a natural leader will often emerge anyway, and sometimes that person does a better job than the person with the official title.

So back to “does a mature team need a facilitator?”, yes, although that person doesn’t have to have the title of facilitator. If we don’t have any facilitation at all, the meeting will very quickly lose any effectiveness that it once had.

A related question is “does it always have to be the same facilitator?” and that’s a resounding no. In fact, I recommend rotating facilitators, at least for the daily scrum, through all of that meetings participants. It’s been my experience that when everyone has a turn being that facilitator, the team takes the entire meeting far more seriously, and consequently does a much better job of it.

Let’s start by defining those two terms:

• A deterministic answer is precise: “It will rain at 3:05pm today.”
• A probabilistic answer contains some imprecision, despite being more correct: “There is a 80% chance of rain after 3:00pm today.”

Or in the case of the typical projects we’re working on:

• Deterministic answer: “We’ll be done on March 1.”
• Probabilistic answer: “There is an 85% chance that we’ll be done on or before March 1.”

The deterministic answer is far more satisfying to our brains, despite being both less accurate and often misleading. Our brains are optimized for energy conservation and want to use as little energy as possible for any decision. The precision of the deterministic answer is attractive as we can just use that without doing any processing of the answer.

Our brains have many shortcuts built-in to optimize for that energy usage, and these are generically called cognitive biases. We tend to lean on these even when we’re in a calm state and then when we’re under pressure, or feeling unsafe, we use them even more.

Precision Bias is when we believe that something more precise is automatically more accurate than the less precise answer. Stating that we will deliver on March 1 appears more reliable. It feels like a better answer, even when objectively, it’s not.

An 85% chance of meeting a date means that there’s a 15% chance that you won’t. The cognitive bias of Loss Aversion tells us that we’re more likely to weigh potential losses more heavily than equivalent gains, leading to biased decisions. We want certainty and even a 15% chance of failing will be given disproportionate focus. A deterministic answer does not trigger loss aversion.

Probabilistic forecasts make variability visible, and Illusion of Control wants us to pretend that we are in full control. In an environment of low psychological safety, an uncertain answer can be interpreted as weakness and therefore dangerous.

An interesting variation on Illusion of Control is that many managers would prefer to have a deterministic answer that they KNOW is wrong because feel that they still have control over that. “I know they won’t make the first scheduled date, but they might make the second.”

Probabilistic forecasts are inputs to decision-making, not decisions themselves. When leaders expect a single “right answer”, probabilistic data can feel like a refusal to decide, and that can backfire on the person providing the forecast. It’s often safer to provide a deterministic answer that’s wrong.

So am I suggesting that you should give up on probabilistic forecasting and provide deterministic answers instead? Not at all.

What I’m suggesting is that we should understand what’s getting in the way of us making effective decisions from accurate data. If we don’t understand our own biases, then they will continue to control us. In this case, not understanding will lead to poorer decisions.

We should also strive to increase safety across our organizations, for many reasons, but in this particular case so that we can make better decisions.

The interesting point, at least for this article, is how people developed one or the other of these mindsets.

They found that children praised on their intelligence (ie “you’re so smart”) developed a Fixed Mindset. They did more poorly on future tasks, gave up more easily and when given a choice of working on easy or hard problems, picked the easy ones.

Children praised on the effort they put in (ie “you really worked hard on that one”) developed a Growth Mindset. They were more successful, persevered more with challenging tasks and when given a choice of easy or hard problems, picked the harder ones.

As you’ve probably already deduced, people with a growth mindset significantly outperform people with a fixed mindset.

I was reminded of this when my friend Stacey made this observation on LinkedIn: I think I’ve gone from Sonnet telling me “you’re absolutely right” all the time to Opus telling me my ideas are “smart.”

Notice that in both cases, the AI is praising how smart she is, not how much effort was put in. This will directly encourage a fixed mindset in those who hear this messaging on a regular basis.

I would expect it to be fairly easy to tell these tools to not praise us in that way. The fact that this is the default behaviour is certainly troubling though.

The language we use is critically important, and affects us far more than we think.

It’s common that we start taking measurements before we even know what problems we want to solve for. We want to be seen to be doing something and measurements are an easy place to start.

At one client, there was a small team that had been tasked with collecting metrics around the agile teams. So they’d come up with a survey with questions like “does your team have a product owner?” and sent them out to a bunch of teams.

When I first engaged with this team, they already had survey results from a subset of the organization. They were able to show me pretty charts but unable to explain what any of the charts really showed or what kinds of decisions we might make from those.

One in particular stood out. It was a line graph for “do you have a product owner” where the Y axis showed the number of teams that had a dedicated product owner, and the X axis showing the week that was true. The line started from very low on the first week and growing upwards week over week.

The only reasonable interpretation of this graph is that very few teams had a product owner when they started and that every week, more of those teams received one. Although very odd to have that many teams without a product owner, it showed that the situation was very quickly rectifying itself.

On the surface, it appeared that they had a real problem and that it was being fixed quickly.

But then I started to ask questions and realized that this isn’t what the graph said at all. The real story is that every single one of the agile teams already had a product owner and that every week, we had more teams answering the survey. The numbers went up because there were more data points in the collected data, not because problems were being fixed. This graph didn’t show problems; it showed participation.

You may think that this is an unrealistic example and that it would never happen at any reasonable company. This example was from a bank and I’ve seen similar patterns at multiple highly successful companies over the years.

Companies where when I ask “what are we measuring and what decisions do we hope to make?” I get nonsensical answers. Perhaps they asked what they should measure and weren’t given an answer. Perhaps they just never asked. In almost every case, when they’ve presented those pretty graphs back to their management, everyone acts impressed and then moves on to something else.

I’m a big fan of metrics, and data-informed decision making so this is infuriating to me. Yes, we should be measuring things, but we should be measuring the right things and then making informed decisions from those measurements. If we’re not prepared to make a decision then don’t collect the data.

That doesn’t mean that we have to have absolute precision before we start measuring anything. Perhaps we want a few general metrics up front so we can determine where we want to place our focus. I will often start with flow metrics if I’m not sure how to improve a system, but I’m fully prepared to stop collecting those if I determine that this isn’t where the problems are.

Back to the start, if you get a request to start collecting metrics, always ask what decisions we hope to make from those. Only then will you know what things to measure and with what granularity.

I’ve been focused on wasting our time by measuring things that don’t matter. It’s worth calling out, however, that people will change their behaviour based on how they’re measured. Measuring the wrong things can actually result in the entire system becoming much worse. See perverse incentives for examples of the wrong metrics backfiring.

Shameless plug: If you want to pull metrics out of Jira then JiraMetrics makes it easy.

It wasn’t a large book, and I quickly read through all of it. Yet, while I now “knew” how to do it, I still couldn’t juggle.

I tried the things I’d read in the book and immediately dropped the balls. I picked them up again and this time I managed a few passes before dropping the ball. Over and over and over again, I picked up the balls and tried again. The more I practiced, the more the knowledge of juggling started to make sense. It became what we often call “muscle memory” but is really just unconscious programming. Through this constant practice, I was able to absorb the knowledge of juggling.

This is the essence of Tacit Knowledge; things that have to be experienced, rather than just read.

If I could have absorbed the lessons just from reading the book then this would have been Explicit Knowledge, but juggling isn’t that.

Why is important to distinguish between these? Because it takes very different approaches to learn tacit knowledge than it does explicit. All too often we think that any problem can be addressed by just watching a video or reading an article, and that’s not true. Some things need to be experienced to be understood.

Almost everything that gets written about here is explicit knowledge. While I can certainly write an article to tell you about the mechanics of juggling, until you actually do it, you won’t have learned what you need to know.

A more concrete example for my audience might be Clean Language. I’ve certainly written about that before and I’ve covered the dozen phrases and some of the mechanics, but unless you’ve actually used Clean Language to solve real problems, you haven’t really learned it. Clean is a tool for the client to find their own answers, not for us to find those answers for them.

At the end of a Clean Language session, we often don’t know what solution the client came up with, and sometimes don’t even know what the original problem was. We gave the client some structure, and they found the answers themselves. Try learning that from a book, without significant practice.

This brings us to coaching and training. There’s a difference between what I can write in an article here and what I can do with people who are getting active coaching or training. The latter is far more comprehensive, both in range and impact.

I’m glad that people read the articles I write. The next step is to experience some of that tacit knowledge, and for that we have to actually interact. I make some time available every week and you can book some of that here. Let’s talk.

In the chart below, we can see the total WIP per day grouped by whether it’s active (blue), stalled (light orange) or blocked (darker orange).

Stalled in this chart means that there has been no activity on the ticket in five days. No comments, no status changes, no subtasks moving. Most likely we haven’t had the time to work on these because we’ve been so busy with the few items in blue.

Blocked means that we can’t work on this because of some external dependency. Perhaps we’re waiting for a signoff, or an environment to become ready.

What we can see with this team is that with a WIP of roughly 15, only a few items are actually being worked on, on any given day, and this is typical in my experience. The higher the WIP is in total, the more of those items are stalled, or blocked.

The team I mentioned last week, with 227 items in progress, was adding value to almost none of those tickets. Almost everything was stalled.

The bottom line is that total WIP only tells us a part of the story. It tells us what’s started but not what’s actually being worked on at any time.

When the WIP is low, we can be fairly confident that all the started items are actually moving along. When the WIP is high, it only tells us that we’re busy, and little else.

Busy is not the same as effective. In fact, busyness and effectiveness are often inversely related. As we become better at one, we become worse at the other.

Starting work items that then just become stalled because we don’t have time to work on them, is not an improvement. That just creates waste and decreases our effectiveness.

Chart from JiraMetrics

It depends on the composition of the team, both size and skills, as well as the nature of the work that flows through the team. It depends on dependencies we might reasonably expect.

It also depends on the larger system that the team resides within, although that’s a much larger topic than I want to address right now. That gets into Systems Thinking or Theory of Constraints, and we’ll discuss them another time.

What do we know about work in progress for a single team?

We know that as a general rule, lower WIP across the team will result in work getting done faster and with higher quality, compared to higher WIP across that same team.

We know that there are very rare exceptions to this where WIP that’s too low can actually make things worse. Many teams are afraid that by lowering WIP, they’ll be affected by this, and so they’re reluctant to lower that WIP. Let me assure you that your team almost certainly won’t have that problem. Not for a long time, anyway

We know that it’s possible, despite what many people think, to consistently have a WIP of 1 or 2 across the entire team (see ensemble / mob programming, and those teams tend to be exceptionally effective.

We know that having a WIP that is measured in multiples of the number of people, is almost always a disaster (ie 20 items in progress for a team of 5). The worst I’ve seen was a team of 10 people with 227 items in progress. They spent all day either context switching or arguing over what was important. Nothing got done.

We know that having a WIP that’s too high will invalidate most of the business prioritization that you’re doing.

So what should the WIP be for your team? If you’re asking the question then almost certainly, lower than what it is now. Lower it and see what results you get.

Then lower it again. And again.

See also: the “lowering the water level” metaphor from Toyota.