Within about twenty minutes, I and my co-facilitators were receiving panicked messages from managers who had not been invited to the retrospective. They were telling me to stop the conversation and leave it alone. It turned out that people inside the retrospective had felt so uncomfortable just talking about this subject that they had reached out to their own management to get it shut down.

An interesting point is that by the end of the retrospective, everyone inside the room was calm and feeling good about the outcome of the meeting.

Outside the room however, the panic continued for weeks. Various levels of management pulled me into meetings to discuss what had happened. What could have been a clean two-hour retrospective became a weeks-long organizational disruption, triggered not by anything that happened in the room, only by the alarm signals that had spread outward from it.

So what was actually happening?

Neuroception

Dr. Stephen Porges, a neuroscientist who spent decades studying the nervous system, coined the term neuroception to describe something that happens constantly, below conscious awareness. Your nervous system is continuously scanning the environment for signals of safety or threat, and it makes that assessment before thought, before language, before any conscious decision. By the time you are aware of feeling unsafe, the call has already been made.

This is distinct from perception, which involves conscious awareness. Neuroception happens underneath it. And critically, it doesn’t evaluate logic or intent. It evaluates signals: tone of voice, facial expressions, the predictability of your environment, whether the people around you seem calm or alarmed. A well-reasoned argument arrives too late. The nervous system has already decided.

What this means in organizations

The people in that retrospective weren’t being obstructive. Their nervous systems had detected threat signals before anything particularly alarming had been said. The topic itself, psychological safety, in a department where safety was already uncertain, was enough. They responded to the signal the context was sending, not to the content of the conversation.

When they reached out to their managers, they became threat signals themselves. The managers outside the room had no direct experience of what was happening inside it. Their nervous systems received an alarm and responded accordingly. The panic propagated through the organization, not because the situation was actually dangerous, only because the signals indicated it was.

This pattern shows up constantly in organizational change. A leadership team announces a restructure. They communicate clearly, hold town halls, answer every question, explain the rationale. Yet, the team still can’t focus. Still seems unsettled weeks later. Still isn’t performing the way it was before.

This is not stubbornness, or apathy, or unprofessionalism. It is neuroception having made a threat assessment, and no amount of rational communication reaches the system that made that call.

The implication

For leaders and coaches, this matters because it reframes the problem. If you believe that felt safety is primarily a communication problem, you will keep reaching for communication solutions. Clearer messaging, more transparency, better town halls. And you will keep being puzzled when it isn’t enough.

Neuroception tells us that felt safety is a nervous system problem. The signals the environment sends matter more than the logic it offers. Resistance to change isn’t stubbornness. Disengagement isn’t apathy. Persistent anxiety after a well-handled announcement isn’t irrational. It’s biology doing exactly what it evolved to do, in an environment it wasn’t designed for.

Understanding what’s actually happening is the first step toward addressing it effectively. This is the kind of work I do with teams and organizations. Let’s talk.

See also: Polyvagal Theory

As I was coming back down from Carrot Mountain (picture), it occurred to me that this is an excellent example of tacit vs explicit knowledge.

When we’re first starting to hike on surfaces like this, we’re sliding regularly but it doesn’t take more than a few hours of this before we’re sliding less. Before we get to a point where we know which rocks are stable to put our weight on and which ones will slide.

And yet, even now if you were to ask me where you can step, even though I can point out the rocks that will hold my weight, I often can’t tell you how I know that. It’s not that the rocks necessarily look that different. I just know¹.

This is tacit knowledge. It’s not something I learned from a book, or that someone showed me once, it’s knowledge that I absorbed through doing. In fact, it’s information that cannot effectively be learned without actual practice.

How is this relevant here? A lot of the information that we need in order to do our jobs really effectively is that tacit knowledge. It’s not something that we can learn from a book, or from a lecture. It’s something we have to do. This is why so many trainings are experiential - if you’re not actually doing the skill, you can only learn the explicit portion of it, not the tacit portion, and the tacit portion is usually the more interesting.

When I teach classes, they’re always deeply experiential. If I’m teaching development practices, we’re actually going to write code together. We’re doing to do simulations and exercises because this is how we absorb tacit knowledge. If you want to know how to not slide on the shale then come hiking with me and step where I step.

This is also the value in coaching. Not reading an article and expecting to have gained all the knowledge, but working with a coach as you’re going through the work. Getting corrections in the moment.

There are many things that you can learn from a book or a video (explicit knowledge). There are an equal number of things that you can’t (tacit knowledge), and for those you need to try something different.

I can help with that. Let’s talk.

See also: Tacit knowledge

So when I hear crazy things like “agile isn’t needed anymore because of AI”, I have to ask:

• Do you no longer care what the customer needs or about the value you’re delivering?
• Do you no longer care about the quality or reliability of the product?
• Do you no longer care if you’re able to sustain what you’re doing into the future?

Sure, some of the specific practices are going to change, but agile is a set of values and principles and those haven’t changed at all. Improving the way we deliver value to our clients is still critical.

Want to hear more? Let’s talk.

By the second week, the support team had stopped calling the developers and when we checked in with them, they said everything was going great. So we rolled out to the entire user base of 10,000 people.

Fast forward a couple of days, to discover that there were lots of problems, and had been problems all the way through the support period. The gotcha is that the support team had found workarounds so they had stopped reporting those problems. Once they’d figured out a workaround, they just walked users through that, rather than reporting it. Problem solved, or so they thought.

Until they were now supporting 10,000 people who all needed that workaround at the same time. All of a sudden the support team didn’t have enough capacity anymore, and it was a full panic. All hands on deck, and development in full fire fighting mode.

Where do we even start to unpack this?

Did we have quality issues? Obviously, yes. The fact that so many significant bugs had even been found, shows that there were quality problems.

Did we have a problem with support stopping with a workaround and not digging deeper to find the underlying problem? Again, yes. While this could have been a conscious choice (Satisficing Decision), it was most likely a cognitive bias (Einstellung Effect) that led them to stop looking for a better solution.

Did we have communication problems between development and support? Yes. The fact that development wasn’t even aware that things were breaking, was a significant problem.

Did we have problems with management not seeing the whole picture? Again yes. Despite the focus on wanting this to go smoothly, they didn’t have any of the overall picture. Each group was continuing to work in their own silo, and optimizing for their own behaviour. Looking at the bigger picture is a management responsibility, and they had abdicated that to the individual teams, telling them to figure it out on their own. Teams that were not in the habit of working together, and had never built up the skills or processes that would have made this effective.

When we see a significant failure, it’s rarely because one thing went wrong. We can usually correct for one mistake being made. The significant failures are due to a cascade of failures, as in this case.

It wasn’t just that there were bugs. It wasn’t just that support stopped reporting problems when they had a workaround. It wasn’t just that groups weren’t talking to each other. It wasn’t just that management had taken their eyes off the ball.

All of these things had happened at once, and it was a disaster. Had only one thing happened, we likely would have compensated for it. The fact that they all happened at once made that impossible.

What made this a cascade rather than a recoverable problem was that each failure cut a feedback loop. Bugs had been reaching us through support calls, but once the workarounds were in place, we stopped hearing about them. We relied on support to escalate problems to development, but support had stopped calling. We expected management to track rollout health through what development reported, but we had nothing to report. Each failure silenced the signal we would have needed to catch the next one.

Each team was solving their own problem: support kept users moving, development fixed what they heard about, management tracked what development told them. Nobody was watching the whole system. Checking in with each team and hearing that everything is fine is not the same as understanding the health of the rollout. Silence is not a signal of success. Ask instead whether the feedback loops are still intact.

How could we have identified the individual problems before we had a cascading failure?

For people internal to the system, that’s the main point of retrospectives. Reflecting deeply into what’s going on and surfacing problems before they fail. If we’re only having superficial conversations then we won’t uncover these things, but if we’re having the right retrospectives, we will. See my course Retrospective Magic for more on improving your retrospectives.

The other option is to bring in someone from outside the system, as it’s often easier for an outsider to see things that the insiders have learned to ignore. That’s not a criticism of the insiders, but rather an acknowledgement of the way human brains work. The more we ignore a thing, the less chance of that thing even being brought into conscious awareness - we literally stop seeing it. Refer to the reticular activating system in this article on poor code

If you’d like help with either of those then let’s talk.

See also:

• Cognitive Bias
• Rapid feedback
• Optimizing for our own effectiveness

You may have heard that this happens because the unconscious mind can’t process negatives, and while that’s a common belief, the truth has more nuance to it. The unconscious mind can process negatives, just not always as fast or as effectively as we need it to.

In order to process a negative, we first need to bring up the positive. If I say “Don’t think of a purple elephant”, what’s the first thing that pops into your mind? A purple elephant, of course. Then you try to push it away or distract yourself with other thoughts so that you can NOT think of that.

The key point is that when processing a negative, we do it in two steps. We first bring up the positive, and then as a second step, we try to not do that thing.

So if both of us are relaxed and I hand you a glass of water and calmly say “don’t spill the water”, your brain will first consider the actual spilling and then will realize that it’s a negative and not do it. So far, so good.

The gotcha is when we’re stressed or things are happening fast around us. In this case, our brains start to prioritize all the items coming at us and it gives a higher priority to the first part (spill the water) than to the second (don’t do it) and it becomes possible for other items to get in between them. We’re reacting so fast that we finish processing the spill before our brains realize that the “don’t” is coming.

Now we’ve got water all over the floor and we’re left wondering why we did that.

How is this relevant in an office environment? High stress or anxiety causes exactly the same problems, and many workplaces are hot-beds of both.

If people are calm and the pace is slow then it doesn’t matter how you phrase things, but you don’t know what other people are dealing with. They may be stressed for reasons unrelated to the current situation.

When giving instructions, say what you want, not what you don’t.

That then led to the obvious question of why is it ok for an agile coach to work with four or more teams at once but not for a SM? After all, there’s an awful lot of overlap between the skills required of both roles.

The key differentiator is that the SM is internal and the Coach is external.

The SM is a part of the team and contributes to the teams goals; they are embedded and doing the work of the team. The coach, on the other hand, is always trying to disengage from the team. They’re building up capacity, and teaching skills so that the team becomes self-sufficient and doesn’t need them anymore.

The coach is always planning to leave, the SM is planning to stay. That focus is quite different, and the results from having each is quite different.

So when I hear “one SM for four teams”, that either means that someone is using the wrong labels and what they really want are teams without SM’s at all, and a coach that floats between them, or they fundamentally don’t understand what an SM does for the teams. I find it’s more often the latter.

⮕ Building it right: Do we have strong technical practices? Are we able to quickly and reliably get features built that will then run with high quality in production? If we can’t make a change without breaking something else we’re not winning.

⮕ Building the right thing: Building the wrong thing fast, helps nobody. Are we actually building the right thing at the right time? Are we validating that what we built did meet the clients needs?

⮕ Building it sustainably: Are we able to maintain the current pace indefinitely or are we burning our people out? Are we balancing out long term need against short term need to avoid taking too many shortcuts?

All too often we focus on just one or two of these. The hype around AI is a perfect example. Yes, it makes us able to write code significantly faster, but are we building the right things and doing it in a way that we can sustain? Are we building a foundation that we can keep working with, or are we making a lot of short term decisions that are going to come back and make our lives miserable later?

In some cases, I see teams that are successfully achieving all three with the use of AI and getting amazing results. In others, I see them deliver the wrong things faster than ever before, and in ways that will come back to haunt them.

It’s worth asking: are we keeping an eye on the bigger picture or are we hyper-focused on the shiny new toy?

Let’s start with the problem first. What decisions am I trying to enable by visualizing WIP in this way? There are a couple:

1. First, are there WIP limits on all the active columns? For a kanban team there absolutely should be and for a scrum team, it’s still a reasonable practice, even though scrum manages WIP through the timebox.
2. Are the limits set at a reasonable place? They should be low enough to force us to do the things we don’t want to do, and yet high enough that they aren’t constantly getting in the way. Even when limits are in place, most teams don’t have them set at reasonable values.
3. Are there patterns in the WIP data that could identify obstacles?

The Y axis shows how many items were in progress (WIP). This is measured by counting all the items that have started but not yet finished at any point in time.

The X axis shows the active columns on the board. Active meaning that items were in these columns while the work was considered started. You won’t see “to do” or “done” columns here because the work was not active at that time.

Then within each cell on this chart, there is a rectangle that tells us how much of the total time that items were in the column, was spend at this WIP level.

From this diagram, you can see at a glance that the design column almost never had any work it it; that most work skipped right over it. Even in the rare case that something was here, it was only ever one item at a time.

You can also see that while the UAT Testing column occasionally had more than 4 items in it, that was exceptionally rare.

Next up, there are potentially three dashed lines in each column, labelled min, max, and rec. The first two are the minimum and maximum as configured in Jira so you can see at a glance how often we’ve exceeded either limit. The third is a recommended maximum that is calculated based on the distribution of data. If your max is set to the recommended level then you should hit the limit occasionally but not constantly (roughly 15% of the time).

In the example here, you can see at a glance that the max of 11 in the ready column is ridiculous as we haven’t even gone past 1 in the time period we’re looking at. That number should be lowered and the recommendation limit is 1.

What about patterns in the data?

We can clearly see that almost no work enters the design column. Do we still need that column or could we just remove it? If it’s not delivering value to us then it’s just noise. Noise slows us down.

We can also see that the development column is never empty and rarely has fewer than 2 items. If this is a scrum team then this could indicate that we’re not actually finishing the work at the end of the sprints.

I’ve seen one data set where the in progress column alternated wide and narrow bars as they WIP went up. A wide bar for a WIP of 3 and a narrow bar for 4, then a wide again for 5. That could suggest that we have some kind of phase gate that only operates on alternate days. There’s nothing conclusive in the pattern but it does help us frame the questions we should ask.

Like this chart? It’s now available in JiraMetrics.

If you’d like help making better decisions from your teams metrics then let’s talk. I’m available to help.

The first was a video, that I didn’t save and can’t find again, talking about call centres and how automating away all the simple calls, meant that the call centre staff no longer had any real downtime. Instead of getting a mix of easy calls and difficult calls, now they get nothing but difficult calls with no gaps between them and this makes the work significantly harder. They used to get a bit of a mental break when handling the easy calls and now that’s gone.

The second was this article by André Meyer, showing the same idea but expressed in different terms. [This is his diagram, not mine]

Yes, AI is allowing us to move much faster through the easy work but is at the same time taking away those opportunities for our brains to pause for a moment. Now the work is much more demanding, all the time, and if we don’t force ourselves to stop periodically, this will ultimately lead to burnout.

Update 2026-05-03: Another article on LinkedIn by Jürgen De Smet, framing trunk based development as a cognitive load practice, rather than an engineering practice.

So you’re thinking “how can I tell if it’s visible on the board?” and that’s more complicated than you would think.

If you only care about whether it’s on the board right now then there’s an API for that.

GET /rest/agile/1.0/board/{boardId}/issue

Unfortunately, if you need historical data, as I do, it’s much messier.

Kanban board in a company-managed project

If we’re looking at a Kanban board in a company managed project then it’s pretty straightforward. We look at the board details to see all the visible columns and from there, we find the statuses mapped to each of those columns. If the issue is in one of those statuses, it’s visible.

The only gotcha here is that we have to look at status ids, not status names because we might have multiple “In Progress” statuses and the one mapped to the board may not be the one in the issue. I’ve seen cases where a single issue has historically been in four different statuses all called “In Progress”, and only one of those is mapped to the current board.

Scrum board in a company-managed project

For a scrum board in a company-managed project then the issue will be visible on the board if the statuses map in the same way as for kanban above AND this issue is in a currently active sprint. Not just “in a sprint”, it must be in a sprint that is currently active.

A team managed project with sprints enabled

If it’s in a sprint then it’s eligible to be on the board but still must be mapped to a status that’s on the board.

A team managed project with sprints not enabled

This is the case where the board behaves mostly but not entirely like a kanban board in a company managed project.

The status mappings are the same as the kanban described above. What’s different is that the issue must also have been moved to the board in the backlog view. It’s easy to tell in the UI if it’s been moved, but that information is not exposed in the API.

When you drag the issue upwards in the UI, we do get a Ranked higher entry put into the history, but that does not tell us if it was moved out of the backlog to the board or just higher in the backlog.

So how can we tell if it’s visible? We can’t.

In a team managed project with sprints not enabled, there is no way to tell if the issue had been visible. The best we can do is call the API at the top to see if it’s currently visible.

This is unfortunately not too surprising. Team-managed projects seem to consistently be an afterthought, and that’s one of the reasons I suggest that people avoid them.

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.

When I teach refactoring, one of the exercises I use is a kata for scoring a tennis game. I give the attendees some working code with reasonably good tests and the instructions to refactor the code to make it better. I tell them up front that the goal is improving the code, not just moving things around, and that I’ll be asking them during the debrief how they made that code better.

Even though the code isn’t very large, there are enough problems with it that you could spend multiple hours cleaning it up.

This particular kata illustrates so many teaching points but there’s one in particular that I want to talk about today.

I’ll split the group into pairs and have them work on the code-base with their pair. Inevitably at least one pair, and sometimes the whole group, will stop about ten minutes in and say “there’s nothing else to fix so we’re done”.

They made a couple of superficial changes and declared that everything left was great. Why is this?

It would be easy to say that these people are lazy or unmotivated and yet that’s rarely true. The real problem is that just don’t see what was right in front of them.

Our brains receive billions of bits of information every second, and our conscious minds are able to understand almost none of that. Research shows that an average person can hold 5-9 (often described as 7±2) chunks of information in our working memory at any time. Only the tiniest bit of that information that we receive every second actually makes it to our conscious awareness.

The part of our brain that decides which bits are important enough to bring to conscious awareness is called the Reticular Activating System (RAS) and it has some fairly simple rules that it follows, that revolve around survival, personal relevance and beliefs, your goals and intentions, and various emotional cues.

The key bit here is that the RAS re-tunes itself constantly based on what you tell it is important.

Have you ever found yourself looking for a new car and when you select one, now you start seeing cars like that one everywhere you go? That is your RAS tuning itself for that particular make of car. Those cars were always present but you didn’t see them until the RAS decided that they were important.

How is this relevant to the original point of people not seeing poor quality code? It’s because the people who aren’t seeing the problems in the code, have never trained their RAS to look for problems in the code, and so they honestly don’t see them. “The code all looks great to me”.

This is why we continue to propagate poor code - because we can’t fix what we can’t see.

As a quick aside, you may be thinking that AI tooling will solve this because it will write better code. AI is a fantastic amplifier - if you’re already writing great code, it will help you write lots more of that. But if you’re writing lots of poor quality code, it’s going to help you do that really fast too. And you won’t be able to correct the AI if you can’t see the problems with the code that it’s generating.

So how do we train our RAS to identify that poor code? The real answer is repetition. We need to spend time looking for problems in the code. Perhaps we’re doing katas to actually improve that code or perhaps we’re doing things like Code Smell Bingo where we make a game out of identifying problems. We need to train our brains to recognize problems so that our RAS starts to help us rather than hiding the problems. Doing that requires repetition.

Can we train our RAS without doing katas? Certainly, we could focus on that through more disciplined code review. That’s just going to take a lot longer, particularly if we’re doing individual and asynchronous pull request reviews, rather than actually talking through the code as a group. Then in the meantime, we’re continuing to add poor quality code to the system.

Want to help your teams improve their ability to find and fix problems in the code? Let’s talk. I’ve been doing this for decades now.

See also: This article on how we often don’t see blockers which can be caused by exactly the same problem.

The benefits to keeping the code clean should be obvious, so why do we see this reaction so frequently?

There are several reasons, including a misunderstanding of what refactoring even means¹. One I’m going to talk about now is that these these people often don’t spend time improving their skill in a safe-to-fail environment. They only ever work in critical production systems where mistakes have consequences.

How do we get better at anything? By doing more of it. If we want to be able to make safe refactoring to keep the code clean, we need to do lots of it. The more practice, the better we’ll get. Except we won’t get that practice if we don’t have a safe-to-fail environment to practice in.

This is where coding katas come in, or coding dojos. Times and places where we can do deliberate practice to hone our craft. Safe-to-fail environments where we can safely learn from our mistakes and improve our skill.

So now the question is why do so many developers not do coding katas? Why do they not do deliberate practice, to hone their craft?

If we feel that we can’t safely refactor the code then we should ask why we never took the time to develop that skill.

If you’d like to be doing deliberate practice but aren’t sure where to start then let’s talk. I teach classes where we do this, and facilitate sessions on it.

It’s a great chart, packed with useful information, but its only helpful if we know how to read it and most people don’t. I deliberately put off adding a cumulative flow diagram to JiraMetrics for years, for this exact reason. [Spoiler: it’s there now]

Then to make it worse, there are many poor implementations of CFD’s (ie Jira) that inaccurately render the diagram so even if you do know how to read it, the information is wrong.

The fundamentals

Let’s start with the fundamentals. What is it graphing in the first place?

We’re showing how many items were in each workflow state (typically columns on a board) at any given time. Ignore the crosshatching for the moment - that’s a subtlety that not all CFD’s will show.

In this board below, we can see that there are five workflow states ranging in order from Ready to Done.

We can see that the Done section is steadily growing, which is good because it shows that we’re actually completing work. The slope of the line tells us how fast we’re completing things.

The thickness of each of the bands above Done tell us where the work was piling up. We can see, for example, that at the beginning, we had far more items Ready than we had in active development and that indicates that we’re planning further ahead than perhaps we need to. This same team later reduced that Ready band, showing that they were beginning to operate more in a just-in-time fashion.

Is that necessarily better? No, the data tells us what’s happening but not why. It’s generally better that we have a smaller Ready band, but that isn’t always going to be true. The CFD provides no judgement of what’s happening, only visibility.

Arrival and departure rates

The CFD can show us the arrival and departure rates as seen by the red and green dashed lines that move from bottom left to top right.

The arrival rate and departure rate lines tell us respectively the rate at which work is arriving in the system and the rate at which it’s leaving. If the two lines are parallel then we have a stable system. Things are leaving at the same rate as they arrive.

If the lines are diverging then we likely have a problem. We’re taking on more and more work and as our Work In Progress (WIP) increases, we’re going to get worse in almost every measurable way.

If the lines are converging then we are lowering our WIP and are likely getting better at everything. Again, the CFD provides no judgement. The lines tell us what is happening but not why.

Getting into Little’s Law

The three key flow metrics of WIP, Cycle time, and Throughput have a clear relationship as defined in this formula that makes up Little’s Law.

$$\mathrm{Average\; Cycle\; Time}=\frac{\mathrm{Average\; WIP}}{\mathrm{Average\; Throughput}}$$

We can see this relationship visually in the CFD as shown by the black triangle in the diagram below.

• For any point in time, the total WIP is the distance from the top of the highest band to the top of the lowest band (usually “done”).
• From the top of that line, if we draw another line horizontally to the right until it crosses the top of the bottom band then this line measures the approximate average cycle time. Why approximate? We’ll come back to that.
• Then if we complete the triangle by drawing a line from the bottom of the WIP line to the far right of the cycle time line, we get the average throughput.

If you’re watching closely, you’ll have already noticed that the triangle isn’t exactly Little’s Law. The law is a relationship of averages of all three and the triangle has absolute WIP as one of the sides. They’re not exactly the same and yet the triangle is still a helpful indicator.

Also note that Little’s law has four key assumptions that must be true for the relationship to hold.

Flow debt

I said we’d come back to the approximate average cycle time that is the top line of the triangle. If we were processing all the work in a perfect first-in first-out order, the assumption is that this would be exactly the average cycle time. Unfortunately, that doesn’t happen with any team that I’ve ever seen. We reorder the work. We do one thing earlier than another because it’s easier or some resource is available now that won’t be available later. Sometimes we give preference to starting new work over finishing work already started, and every time we do that, we interfere with the steady flow of the system. We introduce flow debt and that flow debt causes the calculation to be ever so slightly off.

The cross hatching

Let’s come back to the cross hatching, and at the same time to why the Jira CFD is broken. Note that the cross hatching is something specific to JiraMetrics and is not part of a standard CFD.

A Cumulative Flow Diagram by it’s very definition is cumulative; it can only go up. Yet, the Jira CFD sometimes goes down. What’s happening there?

Jira’s approach seems to be to count WIP in each column at any point in time and graph that. It sounds like a reasonable approach on the surface, but it doesn’t take into account that tickets are allowed to move backwards on the board. When a ticket moves backwards, their implementation now shows the “cumulative” flow going down.

To draw the CFD properly, we can’t allow the lines to drop down, and yet we have to accept the fact that people are still going to move tickets backwards and make a mess of the data. That’s where the cross hatching comes in. If the fill colour for that part of the board is cross hatched, it means that we had to fudge the data to account for people doing things they shouldn’t have done.

Conclusion

The CFD is a powerful tool, packed with useful information, and its worth learning how to read. Just be aware that if you show it in a presentation, you’re likely to lose most of your audience.

With all these things wrong with it, why am I explaining this one in so much depth? Because it’s the one chart that people keep pulling out, and so it’s worth understanding.

See also:

• For a more in depth look at flow metrics, see our Flow Metrics Basics course.
• The JiraMetrics tool and specifically the CFD that it generates. All the images in this article came from that.
• The four key assumptions for Little’s Law

See also: Why people don’t use Monte Carlo from a few weeks ago.

1. Only talk about things that are finished. If it’s half done, it’s not ready for a demo.

2. Ony talk about the value delivered, not how you got here. The audience doesn’t care that you were busy. They care about the things that they can now do that they couldn’t do before. They care about things that used to annoy them and don’t anymore.

If you’re an amazing storyteller then you can probably break both these rules and still have a riveting demo. Most people can’t do that. Stick to these two points and your demo will improve right away.

The first question I always get is “what if we don’t have anything that’s finished or anything that’s valuable?” Cancel the demo. You aren’t ready, and you’d just be wasting everyone’s time.

If you want a third tip, it’s this…

3. Show actual working product, not a slideshow. Nobody wants to see a slideshow.

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. Watch it here

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.