You’ve seen this meeting.

The data is on screen. The signal is clear. The recommendation is specific. Everyone aligns quickly. The decision is made.

It felt right. It looked right. Three months later, it was wrong.

The data was right. The one thing that would have changed the outcome wasn’t in the data.

AI didn’t give leaders new decision problems. It gave their existing ones more speed — and more confidence.

Here’s the thing: confidence arrives earlier than understanding. And when it does, people commit before they’ve asked the questions that matter.

What Confidence Skips

The faster decisions move, the more they cost to reverse. Every decision after the first one gets built on the assumption that the first one was right.

AI accelerates this. It makes decisions feel more certain than they are. Clean signals, clear recommendations, specific numbers — and the conversation jumps from “do we understand this?” to “what do we do about it?”

The step that gets skipped is the one where someone asks whether the assumption behind the signal is actually true.

The Second Question

Every one of those decisions had a question that would have changed the outcome. A question about the assumption behind what the data was about to trigger.

Asking that question requires something that doesn’t live in any dataset: the experience of having been in this meeting before. Meetings with the same energy, the same premature certainty, the same silence where the hard question should have been.

Someone who reads the room, not just the dashboard. Who knows that alignment isn’t agreement. Who recognizes when urgency is coming from a sales commitment, not from actual capacity. Who understands that the strongest signal in a meeting is sometimes the question nobody asked.

That’s not an analytics capability. That’s judgment — built over years inside delivery systems, carrying context that no dataset contains.

That’s what an experienced agile coach brings — someone who has seen this decision before, and knows what comes after it.

Right now, most leaders making decisions at AI speed don’t have that person in the room. They have the signals. They have the confidence. They have the speed.

They don’t have the person who carries what the data can’t.

From the inside, what AI makes possible for coaches feels like empowerment — more reach, more evidence, more impact than they’ve ever had.

From the outside, it’s risk management.

The leaders paying attention aren’t asking whether they still need coaching judgment.

They’re asking how fast they can get it.

— Sonya

The post AI Made Your Organization Faster. Not Smarter. appeared first on Nave Blog: Expert tips and guidelines for agile teams.

For a long time, the agile coach’s job has been one of the hardest jobs in the room.

Not because the work is unclear. Not because the system can’t be understood.

But because insight always arrived late.

The meeting came first. The question came first. The pressure came first. And only then did the real work begin, reconstructing what was actually happening inside a complex system, fast enough to influence a decision that was already forming.

Coaches learned to survive in that gap.

They became experts at reading between charts, filling in missing context, and compressing hours of analysis into a few sentences that might hold long enough to prevent harm. They learned how to slow decisions without appearing obstructive. How to protect teams without losing influence. How to say just enough, but not too much.

That skill has been essential.

But it was never the point of the role.

The Moment the Role Starts to Change

Now imagine opening a dashboard and the story is already there.

Not just what moved last week, but what is changing underneath. Not just what looks risky, but what is working well and should be protected. Not just signals, but implications.

The coach doesn’t walk into the meeting hoping to assemble meaning fast enough.

They walk in knowing what decisions are on the table.

For example, cycle time still looks stable. On its own, that would normally calm the room. But alongside it, you can already see work aging in one stage, arrival rate outpacing departure rate, and a narrowing window before delivery starts slipping. You can also see that flow efficiency hasn’t degraded, which tells you something important: this isn’t a team problem.

That story doesn’t need defending. It doesn’t need translating. It’s already coherent.

The conversation doesn’t start with “what’s going on?”

It starts with “what do we do, and what do we explicitly not touch?”

That’s a different kind of conversation.

What the Coach Becomes in That World

When insight arrives before the meeting, the coach stops being the person who translates data under pressure.

They become the person who shapes how decisions are made.

They don’t spend their energy explaining charts. They spend it framing choices. They don’t argue for nuance. They make tradeoffs visible. They don’t protect teams by slowing everything down. They protect teams by helping leadership see consequences early enough to choose deliberately.

This is the part that’s easy to miss.

The value of the coach doesn’t decrease when the system gets clearer. It increases.

Because when decisions are grounded in reality, judgment matters more, not less. Someone still has to see across teams, across time, across second-order effects. Someone still has to connect decisions today to outcomes three months from now.

That’s not automation.

That’s amplification.

Why This Is an Opportunity, Not a Threat

There’s a fear underneath many conversations right now. A fear that if insight becomes easier to access, the role that provided it disappears.

What actually disappears is the most exhausting part of the job.

The frantic reconstruction.

The late-arriving clarity.

The constant tradeoff between integrity and influence.

What emerges instead is the work coaches have always been moving toward.

More time spent on strategy instead of synthesis.

More attention on systemic patterns instead of isolated metrics.

More conversations about what to protect, not just what to fix.

The coach becomes less reactive and more consequential.

Not louder in the room.

More central to what happens next.

This Is What the Role Was Pointing Toward All Along

This isn’t a better version of the same job.

It’s the job operating at its natural center of gravity.

For coaches who have spent years carrying the system in their heads, racing the clock, and absorbing the downstream impact of rushed decisions, this shift is about finally doing the work they were trained for.

The work that shapes outcomes instead of chasing them.

The work that guides decisions instead of translating after the fact.

The work that makes leadership better, not just faster.

That’s not the future replacing the coach.

That’s the coach stepping fully into their role.

This is what becomes possible when insight arrives early enough to matter. Learn more at getnave.com

Sonya

The post The Next Evolution of the Agile Coach Role appeared first on Nave Blog: Expert tips and guidelines for agile teams.

There is a specific kind of exhaustion that does not come from working too hard.

It comes from knowing exactly what will go wrong, seeing it clearly ahead of time, and still being unable to stop it.

Enterprise coaches and transformation leaders live in that space more often than anyone admits. They are asked to own outcomes they do not fully control, explain systems they cannot fully surface, and absorb the consequences of decisions made faster than understanding can keep up.

Over time, that does something to you.

The Invisible Work That Makes Transformation Exhausting

Most of the work that burns people out in transformation roles never appears on a plan.

It is not the workshops or the roadmaps or the Jira boards. It is the constant internal work of holding the system together in your head.

You are tracking funding models, intake volatility, architecture constraints, dependencies, compliance gates, staffing changes, tooling friction, leadership behavior. You are watching how all of it interacts, where pressure is building, and where the next break is likely to happen.

You’re answering questions while mentally running the consequences ahead.

That mental load does not switch off when the meeting ends. It follows you into the next conversation, the next decision, the next moment where you realize you are carrying more context than the room can hold.

When Responsibility Outruns the Ability to Act

The hardest moments are not the dramatic failures. They are the routine ones.

The dashboard goes red. A metric moves the wrong way. An executive asks a simple question and expects a fast answer.

You know the real answer exists. You also know it cannot be compressed into the format you are being given. You can already see how a partial explanation will turn into a directive, how a guess will become policy, how teams will feel the impact tomorrow.

And still, you are expected to say something.

This is where it starts to feel heavy, in the small decisions you make again and again.

How much do I simplify. How much context do I withhold. What do I let slide today so I can still have influence later.

None of the options feel clean. All of them cost something.

One compromise does not break you. But they accumulate.

Each time you oversimplify, you give up a little integrity. Each time you hold back context, you lose a little trust in the process. Each time a rushed decision creates downstream harm you could see coming, you carry it with you.

Eventually, many people stop pushing as hard. Not because they stopped caring, but because caring costs too much when responsibility keeps outrunning authority.

Why This Wears People Down Before Anything Breaks

What drains people over time is being accountable for outcomes they can’t fully shape.

Good analysis takes time. Decisions are made in seconds.

What’s happening in the system is non linear, even though the conversation pushes toward a simple cause and effect story.

People are then held accountable for outcomes without being given consistent authority over the conditions that produced them.

That gap creates chronic tension. And tension without resolution does not turn into growth. It turns into withdrawal.

People adapt in predictable ways.

Some disengage emotionally. They still show up, but they stop carrying the system in their head.

Some simplify more than they should. They give the room what it wants and deal with the consequences later.

Some retreat into the process. It feels safer to manage frameworks than decisions.

Some leave.

Not because they failed, but because they could no longer live inside the contradiction.

When that happens, organizations lose more than talent. They lose early warning signals. They lose decision quality. They lose the ability to see second order effects before they happen.

What remains are dashboards and confidence, but less understanding.

A different future is possible here.

The answer is changing the conditions under which decisions get made.

What would change if analysis could keep up with decision speed. If system level insight did not have to be reconstructed under pressure. If coaches did not have to choose between integrity and influence in every meeting.

That shift does not remove the need for judgment. It gives judgment something solid to stand on.

And it gives the people doing transformation work a way to carry responsibility without carrying it alone.

Burnout in transformation roles isn’t a personal failure. It’s a sign that responsibility has grown faster than the ability to act.

The real question is not how much longer people can endure the tension.

It is what becomes possible when they no longer have to.

Ready to see what decision speed analysis looks like in practice? Learn more at getnave.com

Sonya

The post What It’s Like Being Responsible for Outcomes You Can’t Fully Control in Transformation appeared first on Nave Blog: Expert tips and guidelines for agile teams.

You’re in the quarterly portfolio review. The dashboard is up on the screen.

Active initiatives: 47. Up from 38 last quarter. Average cycle time: 12 weeks. Up from 9. WIP across teams: at capacity.

Everyone sees the numbers. The discussion goes like this:

“We’re spreading too thin.”
“Cycle time is climbing.”
“We need to focus.”

The meeting ends. You’ve aligned on the problem. But no one paused three initiatives. No one resequenced the roadmap. No one made a call.

I’ve watched this exact scenario play out in six leadership meetings over the last two quarters. Different companies. Different numbers. Same outcome: consensus without consequence.

Here’s the thing: you’re treating these numbers like status reports when you need to treat them like action triggers.

Because action triggers are what demand answers.

Here’s What’s Missing

Most organizations have portfolio dashboards. You track active work, capacity, cycle time, throughput, flow efficiency. You have the data.

Here’s what’s missing:

“[Metric reaches X] → [We do Y]”

Without that sentence, every review becomes an interpretation exercise instead of action.

Let me show you what I mean.

Let’s say you’re managing 47 active initiatives across six teams. Over three consecutive quarters, active work grew 24%. Cycle time increased 33%. Team capacity stays flat.

Here’s what the rule should have been:

[Active initiatives exceed 40] → [Leadership pauses the bottom 5 until capacity is back to normal]

That’s it. One sentence. If that rule had been defined before the meeting, the first quarter would have triggered it automatically. No interpretation needed. No 45-minute discussion about whether there’s a problem. The number crossed the threshold, the rule activates, leadership chooses which 5 to pause.

Without the rule, quarter after quarter they reviewed the same growing numbers, discussed the same problem, and made no progress.

Data does not create action. Decisions do.

The Signal-to-Action Map

For transformation to work at portfolio level, every number needs three components:

1. Signal: What Changed
The quantifiable change that requires attention.

Example: “Cycle time increased from 9 weeks to 12 weeks (33% increase)”

2. Choice: What Leadership Must Determine
The specific call leadership needs to make in response.

Example: “Whether to stop new intake, add capacity, or reduce WIP”

3. Action: What Gets Changed
The concrete stop, start, pause, or resequencing that happens.

Example: “Stop new intake for 2 sprints. Resume when cycle time drops below 10 weeks.”

This strategy is what makes your numbers actionable.

Leaders don’t need more metrics. They need to be able to make decisions with the data they already have.

Most portfolio systems focus on improving visibility.

That’s not the constraint.

The constraint is this: when the number changes, what specific action do we take?

If you struggle to answer that question, that’s your problem right there.

Your 15-Minute Test

Pick one portfolio number you review regularly. Complete this sentence:

“When [metric] changes to [threshold], leadership [takes specific action]”

Examples:
– “When active initiatives exceed 40, leadership pauses the 3 lowest-value initiatives”
– “When average cycle time exceeds 10 weeks, leadership stops new intake for 2 sprints”
– “When flow efficiency drops below 30%, leadership eliminates the most impactful bottleneck”

Bring this to your next portfolio review. Ask: “Do we have rules for our key numbers?”

If the answer is no, you’ve just identified the gap.

Start tomorrow.

Pick one number. Complete the sentence. Bring it to your next leadership conversation.

This is how data becomes actionable.

—Sonya

The post One Sentence Every Portfolio Metric Needs (And Probably Doesn’t Have) appeared first on Nave Blog: Expert tips and guidelines for agile teams.

Often, managers use average delivery times to make future predictions. Even though this method is intuitive and widely spread, making delivery commitments based on averages is not reliable. Let’s explore the challenges that come with this approach.

What Are Delivery Times Averages?

When we talk about using averages to make delivery predictions there are three main values we refer to – the mean, the median and the mode.

The Mode is the easiest average to calculate – this is the number that appears most often. Since that’s the most commonly occurring delivery time, if you ask a team how much time they usually need to complete a task, this would be the answer.

The Median shows the middle number of a data set. It denotes that half of the tasks completed so far have taken less than the median value to be finished. However, the other half have taken longer to complete.

The Mean is the average calculation that you are most likely to be familiar with. This involves adding up all of the values and dividing them by the number of instances in the data set.

Most often, the average we use to make a delivery prediction is either the mode (the most common value) or the mean (the arithmetic average).

Why Using Averages to Make Delivery Predictions Will Land You in Hot Water

Making predictions based on an average is highly likely to land you in hot water. Delivery forecasts based on averages only make sense if you know something about the shape of the underlying distribution of your delivery times.

Let’s explore a couple of examples.

This is a Cycle Time Histogram exposing a high-variability delivery workflow. The Cycle Time Histogram shows the frequency distribution of the completion times of the tasks in your workflow. The vertical axis displays a frequency and the horizontal axis shows your cycle times.

A Cycle Time Histogram with a big hump on the left and a very long tail to the right indicates that your cycle times vary significantly. This means that your process is inconsistent and you’re maintaining an unpredictable system.

Here, the mode points to 1 day, the median is 9 days, and the mean –  21 days. The most popular delivery time is 1 day, and the tail extends all the way up to 130 days. If you were managing this team and you were about to commit to the average value (the mean), you may end up with a delivery time that is 6 times higher than what you’ve promised to achieve.

If you don’t know the distribution of your delivery times, there is no way that you can give a probability of where the average falls. If you don’t know the probability, then you cannot make a reliable delivery prediction. There could be a 20% or 50% or 80% chance of meeting your commitment.

Would you commit to a delivery date if you know that there is only a 20% chance to keep that promise? Probably not, right? It certainly wouldn’t be something that we’d recommend doing.

Using the Frequency Distribution of Your Delivery Times Effectively

Now, assume you know the frequency distribution of your delivery times. Let’s analyze the following example.

Here is the cycle time frequency distribution of a mature team that maintains a stable system.

A key point to note here! The more stable your system is, the more predictable it becomes. And predictable systems produce more accurate delivery predictions. If you’re interested in adopting the practices and the proven strategies to establish a stable system using a step-by-step roadmap, we couldn’t be more thrilled to welcome you to our Sustainable Predictability program.

In the example above, all the averages are very close to each other – the mean is 7.20 days, the median (50% of the cases) points to 7 days and the mode is 9 days.

Using their frequency distribution, this team can say that there is a 50% chance of finishing any work item in less than 7 days.

By committing to that delivery prediction, what they say is there’s an equal likelihood that they’ll either make it on time or not. There is a 50/50 chance of making that happen. The risk is considerable.

In order to provide a reliable commitment, what you need to do is to come up with a set of delivery times and the probabilities that come with each of them.

Using the example above, what this team should do is to deliver a probability forecast that looks like this:

Now, it’s up to your customers to decide the level of risk that they are willing to take, and which probability they feel most comfortable with. When you’re maintaining a stable system, that decision will be quite an easy one, as the values that come with each probability will be very close to each other.

It’s important to remember that your forecast is a living thing – it will change as you discover new information, so it’s crucial to reevaluate it on a regular basis. You will need to adjust your course accordingly to be able to hit your goals.

Switch to Probabilistic Forecasting As Soon As You Can

Let’s make this clear, what we are saying is that using averages to make delivery predictions is not a reliable approach, not that it’s not applicable at all. If you’ve been relying on estimating and guesswork so far, this method is something you can transition to as a starting point. However, strive to switch to probabilistic forecasting as soon as you can.

Using averages to estimate your work can land you in hot water, as this method communicates one single certain commitment. To produce a reliable forecast, you need to provide a range of delivery times and the probabilities that come with meeting each of them. That’s the most reliable way to establish realistic expectations and deliver on time!

Alright my friend, I hope you found this piece of content valuable! I’ll see you next week for more managerial goodness. Bye for now.

The post Why Using Averages to Make Delivery Predictions Will Land You in Hot Water appeared first on Nave Blog: Expert tips and guidelines for agile teams.

It’s been a busy year for us here at Nave, so it’s time to let our hair down, have some fun & celebrate the end of a successful year. But, none of it would have been possible without your trust and help. To that end, we’d like to extend a big thank you to everyone who supported us during this incredible year!

To Our Customers

We have always put our customers first, which is why we’ve worked hard to bring you a solution that helps improve your workflow and make your processes more efficient. Not only are you the driving force behind everything we do at Nave – you’re the very reason we exist. Right from the start, our goal has been to bring value to you as soon as possible. Thank you for your trust! We won’t let you down!

To Our Team

Any successful project is driven by the power to collaborate and communicate without limitations and across geographical boundaries. We would like to say special thank you to our team all around the world. Thank you for your motivation, hard work and dedication. Our success wouldn’t have been possible otherwise. Thanks guys – you’re amazing!

To Our Partners

We’d also like to thank all agile coaches who have believed in us and shared our success story over the past year. With your help, we’ve managed to transform Nave into a respected brand and a trusted provider of solutions for agile teams everywhere. Thank you for the reliable team work!

To the Teams Behind the Platforms We Integrate With

Without the people behind all the products we integrate with, our solution simply wouldn’t make any sense. That’s why we’d also like to thank you for building the platforms that our dashboards work with. Your products help agile teams stay organised and collaborate effectively on any project. Together, we provide the ultimate solution for successful teams to deliver value as quickly as possible. We are happy to work with you! Keep up the great job!

To the Kanban Community

We developed our product to drive success among software development teams across the globe. We’d like to thank the Kanban community for their insights and support and their ability to drive the trends shaping our solution. To all those who share knowledge and help us keep our sense of direction, thank you for your help!

To Our Families

Over the past year, we’ve been working hard to build our visual analytics tool to help agile teams across the world increase their productivity, improve workflow efficiency and become faster, smarter and happier. It has cost us a lot of time, energy and dedication. We’d like to say a warm thank you to our families for being so patient while we’ve worked long hours to make that possible. We love you more than anything, and we wouldn’t have been able to make it without you!

What to Expect in 2026

Our job is never done. We’re here to deliver continuous value to our customers by listening to their feedback and focusing on their needs. That’s why we’re working hard to constantly improve our product. Our roadmap for 2026 includes releasing our brand new planning & forecasting, and prioritization & dependency management modules. Stay tuned and let us know which integration you’d like to see next in the comments below!

Wishing you great success in achieving your goals and dreams in 2026!

Merry Christmas and Happy New Year!

The post A Big Thank You from Nave! appeared first on Nave Blog: Expert tips and guidelines for agile teams.

The new year is just around the corner, so now is the perfect time to stop and reflect on your goals and the next steps you plan to take. With that in mind, I’ve put together a motivational reading list of 5 of my all-time favorite blog posts.

With the holidays upon us, it’s that time of year where you get to take a break and feel proud of what you’ve accomplished.

You’ve certainly earned it.

It’s also a great time to reflect about whether you’re on track with your goals so far. And whether there’s anything you might want to change – or improve – in the coming year.

To give you a head start, I have come up with a shortlist of some of my most favorite articles.

There are several managerial lessons that I feel are so essential that I decided to create a “holiday reading list” to help you gear up in 2026.

So go ahead and grab a warm mug of your favorite holiday beverage, find a cozy spot, and let’s dive right in.

#1 What is Flow and How Can I Measure It?

What does the concept of flow look like and what are the metrics for it? Here’s an excerpt from the article:

“When your customers make a request, there is a process that you will follow in order to achieve the delivery of that request. Essentially, flow in knowledge work is the movement of the requests through your process.”

“And our ultimate goal is to optimize flow so that we can improve the way each piece of customer value moves through our system so that it can be delivered to our clients in a more efficient, predictable manner.”

When you think of flow, think of the last time you were in an airport. There’s a whole process for getting through security: show your passport, walk up to the conveyor belt, put your items on the belt, walk through the scanner, then pick up your items on the other end. Any delay with each of these steps slows down the whole process (as I’m sure you’ve experienced yourself while traveling).

In a similar fashion, flow is moving a customer’s request through a process of steps. And in order to ensure that you deliver results in a consistent predictable manner (rather than getting sidetracked and bogged down like you might at airport security), you need the right metrics in place. These metrics determine how efficient your system is.

Here are the 4 main metrics you need in order to measure flow and maintain an efficient system →

#2 Your Board Design Can Make or Break Your Team Performance and Here Is Why

You know the old saying, “it’s all about perspective”? Nowhere does this apply more than in project management. From the article:

“Ultimately, achieving sustainable predictability begins with a shift in your perspective from managing your workers to managing the work itself. And the approach you use to visualize your work has the potential to make or break your improvement efforts.”

How you choose to visualize the work on your board affects the way your team members will perceive it. And the way they see it will affect their decisions – not just consciously, but also subconsciously.

Think about it: if the columns on your board represent specialties, it becomes natural for each team member to focus on “their column,” “their specialty,” and “their work.”

But as a manager, you want your team to work as a team, rather than each worker holed up in their own lane.

Here’s why it’s so important to rethink your Kanban board design →

#3 How to Turn Daily Meetings into Outcome-Driven Events

Your daily meetings are an important part of your managerial rituals. That’s why you want to make the most of them. Here’s an excerpt:

“When we perceive our daily call as a status update meeting and ask people, what’s the status of their work every day, the interfering spark of micromanagement starts to build. Slowly, but surely.”

“The team’s engagement and motivation levels go down and with it, the daily call starts to feel like another thing that’s distracting people from doing their work.”

“So, you should ask yourself, “Is a status update appropriate in the first place?

Your Kanban board is your ultimate source of truth for checking the progress of your workflows – not your daily calls.

Imagine how much time it would take if you spent each meeting asking each team member about the status of their work – trust me, it adds up fast. What’s more, no manager wants to feel like they’re looking over someone else’s shoulder.

That’s not what the purpose of your daily meeting is. On the contrary, the main goal here is to move your focus from your workers to the work itself and start managing it effectively.

Here’s how to streamline your daily meetings to be as efficient as possible →

#4 Why You Need Probabilistic Forecasting as a Manager

If you’re not using probabilistic forecasting, make 2026 your year to start. From the article:

“Probabilistic forecasting changes the game because it’s fast, cheap and most importantly reliable.”

“The more predictable your delivery system is, the more reliable probabilistic forecasts it will produce.”

“You’re effectively taking out the guesswork and you’re managing risks effectively. You are empowered to choose which outcome makes the most sense for you, based on the % of risk you’re willing to live with.”

I’m a passionate believer in using probabilistic forecasting. Why? Because this approach gets us closer to what will actually happen in the future.

Alas, magic crystal balls unfortunately don’t exist and knowledge work is notoriously tricky.

In my opinion, probabilistic forecasting is the next best thing because it allows you to come up with multiple outcomes (based on your own past data) with the % likelihood of each one becoming a reality.

You can never know 100% whether you will be able to meet a deadline. But knowing that you have an 85% likelihood of delivering before date X compared to, say, an 80% likelihood of delivering before date Y empowers you and your teams to decide how much risk you’re comfortable with.

Learn more about why you need probabilistic forecasting – and how to use your historical performance data to make delivery commitments →

#5 How to Enable a Stable Delivery System in 2 Easy Steps

Even with the best strategies in the world, you won’t get far without a stable system. Here’s a sneak peek from the article:

“The main requirement to producing reliable probabilistic forecasts is to enable a stable delivery system. In fact, if you don’t maintain a stable system, nothing will work. You’d be better off buying a pair of dice and rolling them. You would have the same probability of achieving your goals.”

How’s that for perspective?

You may wonder, “what exactly is a stable system?”

Answer: it’s a delivery system that enables you to make reliable data-driven decisions and produces accurate probabilistic forecasts. In other words, it’s a system that helps you deliver results consistently (and no, you don’t need to have items of the same size to make this work!)

And the good news is, it’s not hard to set up. In fact, you can get started in just two steps!

Here are the 2 easy steps for a stable delivery system →

Putting It All Together

Put all these concepts together, and you have a strong foundation for achieving big results in 2026.

And if you’re ready to take it a step beyond that, now is the perfect time to check out our Sustainable Predictability program. This course will show you exactly how to manage your workflow so that you get predictable results that enable you to deliver your work on time, every time.

Better yet, you can check it out with no obligations – you can get a free sneak peek of the first module, to make sure it’s right for you.

I hope this holiday reading list inspired and motivated you for how to meet your goals in 2026. If you know a fellow manager who would also find this reading list helpful, please share it with them on your favorite social media platform.

In the meantime, I wish you a Merry Christmas, Happy New Year and all the rest! Please enjoy your time off to the fullest and stay in touch. I’ll still be here every week as always, same time, same place.

The post Your Holiday Reading List: Strategy, Inspiration and Management Insights appeared first on Nave Blog: Expert tips and guidelines for agile teams.

When it comes to introducing probabilistic forecasting, it is paramount that you tackle any resistance head-on.

Do you have kids? My son David is 4 years old, and my daughter Louise is now 6. She will start first grade in September. She used to have a Teddy Bear when she was little and she was crazy about it! She slept with it, she ate with it, she couldn’t leave it, not even for a second. When it lost its plush hand for the first time, she was so devastated that I had to needle it at 10pm in the evening.

Now (a few years later), she is much more interested in counting the number of dresses she has in her wardrobe and trying to figure out creative ways to get into my make up. But, the Teddy Bear still sits on the corner of her bed. Even though she is not interested in playing with it anymore, she still wants it in her life. She feels safe and comfortable by having it there, by her side, all the time.

Embracing Change Management

Looking after our kids has a lot of similarities to change management. When it comes to introducing new practices to your team – with the aim of improving your performance and delivery speed – you need to approach the situation with empathy. That’s especially true when it comes to changing the way you make delivery predictions. The traditional methods of estimating have been so widely used and they’ve been the same for so long, that this approach (even though it is flawed) has become deeply ingrained in the way we manage our work.

When introducing the probabilistic forecasting method, don’t be surprised if people resist. And, if you don’t meet that challenge in the most effective manner, you’ll put your entire transformation initiative under threat. 

By imposing a new way of doing things, you run the risk of communicating that whatever your team has been doing up to this point no longer makes sense, that it is not worthwhile anymore. 

This would come across as a direct attack on their personality. What you essentially do here is take away the Teddy Bear from their lives.

People Don’t Resist Change. They Resist Being Changed

Change management is about helping people adopt change on both an emotional and psychological level. Most commonly, we change because of how we feel, rather than because of what we think.

People don’t resist change. They resist being changed! — Peter Senge

When faced with a decision, most of the time, how we feel about the matter determines our final choice. The data and analysis will frequently narrow down the choices, but at the end of the day, we choose to change (or not to change) based on how we feel about it.

As a manager, your decisions can’t be effective if others aren’t following them. And others will (or will not) follow based upon how they feel about what you’re proposing to them. It’s as simple as that. 

The process of change management is very different from the process of project management. One of the qualities that the most successful leaders have is their ability to put themselves in their workers’ shoes, in order to better understand how change impacts their individuality.

So, how can we work around the resistance to change? How can we make sure that our transformation initiative succeeds when we introduce the new approach to probabilistic forecasting?

Introducing Probabilistic Forecasting

When you introduce the probabilistic forecasting method, you’ll naturally meet resistance. You’re calling the way things have happened so far into question (even though they have been a major source of inefficiency and unreliability).

To smooth the transition, what you need to do is to keep the Teddy Bear (estimation). Let everyone keep making estimates, and introduce the probabilistic forecasting method in parallel. 

At the end of the day, it takes just a couple of minutes to come up with a delivery prediction. The results that it produces will be just as good (or even better) with much less time and effort spent.

Keep both of the approaches in parallel, and regularly reevaluate your forecasts. Report the results and let your team see (on their own) which approach is more reliable. 

People need to understand that this method is actually a better one, in order to develop trust in it. The numbers will provide the evidence and at some point, it will become obvious which one provides the most accurate results.

Here is your action item: If you haven’t created your dashboard just yet, now is the time! Go ahead and connect your management tool with Nave, it’s free for 14 days, no strings attached →

Even though the Teddy Bear might not be useful anymore, it needs to stay there until the new toy replaces it naturally. The most important thing to always keep in mind is that change will not occur by forcing it, it occurs because people feel that they don’t need the Teddy Bear anymore. 

That’s the smartest approach to introducing probabilistic forecasting without resistance and allowing for reliable delivery predictions, without wasting time and effort.

I wish you a productive day ahead and I’ll see you next week same time and place, for more managerial goodness! Bye for now.

The post Keep Your Teddy Bear! Introducing Probabilistic Forecasting to Your Team appeared first on Nave Blog: Expert tips and guidelines for agile teams.

Introducing WIP limits is one of the most powerful approaches to reduce delivery times by aligning demand with capacity and keeping the focus on the most important work. 

Often though, introducing WIP limits meets resistance from within the team. People naturally tend to stick to what they’ve always been doing: just starting more work. When the focus is on getting more work started, rather than finishing old work, the consequences can be disruptive.

How can you address this problem? Ultimately, the first thing to do is to truly understand the challenges that you might be dealing with. Instead of enforcing the practice regardless, you first need to evaluate the current state of your workflow and the maturity of your team. This will enable you to proactively avoid resistance.

Adopting WIP Limits Is a Real Game Changer

There is no doubt about it, WIP limits are the ultimate game-changer. In one fell swoop, this practice relieves overburden, eliminates multitasking and prevents context switching. Delivery times also rapidly go down, which is one of the strongest motivational boosters. What’s more, now that there is less of it at a time to handle, you’ll find that work is being done with more precision and delivered at a higher level of quality.

You can see how this works on a conceptual level by looking at Little’s Law. Little’s Law equation connects the three main flow metrics – cycle time, throughput and work in progress, and the way in which each component influences the others is self-evident: 

Cycle Time = WIP / Throughput

The Law states that, in order to decrease cycle times, you need to either increase throughput (which normally comes with a cost) or decrease the work in progress, which is usually a much more convenient step. 

Implementing WIP limits is certainly worth the effort. So why is it so hard to get started?

The Challenge of Introducing WIP Limits

The main goal of having WIP limits in place is to stop starting and start finishing. The idea is to reduce the demand to a level that aligns with the team’s capacity. This way, the team is only working on as many items as they can handle at one time, which prevents ongoing work to age artificially.

When your work in progress has a limit, your team won’t be able to pull in new work until an outstanding work item has been completed. That way, the idle team members have to focus on tackling the rest of the work in progress in order to be able to deliver sooner.

Where does the challenge come from? What if you are maintaining a highly specialized team with individuals who are unable to handle each other’s work? What if there are dependencies outside the team’s control that block the work from moving further? What if there is no clear Definition of Ready, Definition of Done and Acceptance Criteria and there is no clear understanding of what needs to be achieved overall?

If that’s the case, introducing WIP limits will probably make things worse, as it will only force the team to remain idle while still nothing is getting finished. 

Why would the team resist? Often, this would arise as a result of a lack of confidence to take the initiative and work on outstanding tasks. We, as managers, are responsible for encouraging leadership at all levels, growing autonomous teams and enabling our workers to do their jobs.

Instead of jumping into introducing WIP limits right away, you ought to ask yourself whether you’re ready to adopt that practice. Before you start designing your new Kanban system, you first need to have a conversation with your team.

Begin your initiative in the most transparent manner possible. Step by step, explain to your team your goals and intentions and what might be the challenges for all of you. Emphasize why it’s worth it and how their work-life will become much more successful. Introducing WIP limits represents the means to achieve your goals, the practice is not the goal itself. 

If you are striving to enable stable delivery systems that produce consistent business outcomes, I’d be thrilled to welcome you to our Sustainable Predictability program!

So what’s the effective approach to introducing WIP limits, without putting your team on the offensive?

Switching the Direction of the Conversation Altogether

A smart way to approach the situation, before you even start to talk about implementing WIP limits, is to lead your team towards a mutual agreement on the way they select what work to take on next. For a development process, it could be an explicit policy that looks like this:

Once a piece of work is finished, instead of immediately pulling a new item from the backlog, first, go through the cards on the board. Start from the far most right side column (the one before Done), then go towards the beginning of the workflow.

Look for items that are not assigned to anyone, any issues that need to be fixed (even if they are not assigned to you), anything that’s waiting for code review or implement feedback from code review.

A new item of work should only be started if there is literally nothing that you can do to help the ongoing work items move forward in the process.

Essentially, that practice is already shifting the focus to stop starting and start finishing, except it doesn’t artificially reduce the number of the items available at any one time. The goal is not to enforce the practice but to evaluate whether your team is handling this approach well and whether they are actually capable of delivering outstanding work on their own.

If that’s not the case, then your focus should switch to resolving the obstacles that prevent your team from finishing their work and preparing the ground for further improvements.

If it is, then you should probably move forward and start slowly by introducing WIP limits on a personal level and as your team matures, switch to per-column WIP limits and eventually place a WIP limit on the entire system. The most important part here is to introduce one change at a time and measure the impact. If it works, move on to the next practice. If it doesn’t – revert it back, evaluate what caused the practice to fail, and work upon its prompt resolution.

Focus on the Outcomes

To that end, you can make that first step effective by focusing on the desired outcomes, rather than jumping straight in and forcing the WIP limit practice artificially. As managers, our job is to provide teams with clear guidelines about how to handle the work to be able to achieve better outcomes.

By focusing on finishing the outstanding work before starting new work, we can effectively limit the amount of work in progress, without implementing the practice explicitly. In turn, teams are likely to respond with much less resistance and you’ll be able to focus on the impediments that would otherwise create tension and poor results.

Even though we may not be putting static WIP limits in place right away, and the amount of WIP will fluctuate a bit, this doesn’t really matter. What’s more important is that, in this first step towards successfully introducing WIP limits, you will already see significant improvements to your team’s performance. It’s a great way to achieve impressive results, without taking the risk of failing your entire improvement initiative.

The main takeaway is that you should always consider your own context and you shouldn’t get too obsessed with practices. You can achieve just as much success by focusing on the outcomes and embracing the results. Ultimately, there are no best practices in this business. There are only good practices – success lies in starting with what you do now and focusing on what works best for your teams and your business.

I hope this was helpful! See you next Thursday, same time and place. Bye for now!

The post Are You Ready to Stop Starting and Start Finishing? The Smart Way to Introduce WIP Limits appeared first on Nave Blog: Expert tips and guidelines for agile teams.

Getting started with Monte Carlo simulations as an alternative approach to making delivery forecasts can be challenging, especially if you’ve been stuck estimating your work using story points (or hours) for quite some time.

Over the past few months, I’ve received a lot of questions from our audience about this topic and so I thought it would be useful to bundle the 10 most frequently asked ones together and answer them for you.

The Monte Carlo Simulation Explained: How to Leverage the Most Reliable Approach to Forecasting

Today, we’ll explore the top 10 frequently asked questions (and answers) about Monte Carlo. Let’s dive in!

What is Monte Carlo simulation?

In project management, the Monte Carlo method or Monte Carlo simulation is a mathematical technique used for forecasting which takes into account risk, uncertainty and variability.

It runs a large number of random trials using your past throughput data to predict the throughput for a future time frame.

You define the start date and the number of tasks, and the simulation provides a range of delivery dates and the probability that comes with each date. For any date in the future, it uses the throughput of a random day in the past to simulate how many work items are likely to get done.

For example, say on February 14th you’ve had a throughput of 3 tasks. The simulation takes this number and assumes that this is how many tickets will be completed on February 22th. To project the probable throughput of February 23th, it takes the throughput of another random day in the past and so forth.

Тhe simulation is repeated tens of thousands of times before the results are presented in the form of a probability distribution with percentiles increasing from left to right. It provides a range of delivery dates and the probability that comes with each of them. The Monte Carlo simulation produces a probabilistic forecast based on your past performance data.

When to Use Monte Carlo Simulations?

With regard to forecasting, Monte Carlo simulations come in two forms: calculating the delivery date of a number of items to be completed, or the amount of tasks to be finished in a given period.

We use this technique to answer the two most challenging questions in project management:

• “When can we finish X number of tasks?”. Monte Carlo will give you the delivery date of your project and the level of certainty that this will happen. Let’s say that you know (at your best) that the scope of the project is about 100 tasks. You can use the Monte Carlo simulation to give your client a probable delivery date and the confidence level to hit that target.
• “How many tasks can we finish in X number of days?”. With Monte Carlo, you will be able to decide how many items can be completed within a certain timeframe. For example, say you know your next release is planned for June 15th and you want to know how many new features will be ready by then. You input your start date and end date and the simulation will give you a range of outcomes and the probability that comes with each of them.

No guesswork or subjective estimating is involved – just data-driven probability-based future predictions calculated using your own historical performance.

How to Interpret Monte Carlo Simulation Results?

Monte Carlo uses a computational algorithm to simulate the process thousands or even millions of times. The result is a histogram showing all the possible outcomes and the likelihood that each outcome will occur.

So, how do you read that histogram?

In this example, we set a backlog of 40 tasks and we want to start working on it on March 1st. The simulation tells us that there is an 85% probability that we can finish all the backlog items by July 5th. The further you go in time, the greater the certainty of completing all the tasks.

Are we saying that these exact 40 tasks in our backlog will be delivered by July 5th? No, we aren’t. What we are saying is that we can deliver any 40 work items by July 5th and there is an 85% chance that we can meet that goal.

Probabilistic forecasting enables you to make reliable delivery commitments using your own past performance data. The question, “When will this be done?” is not that interesting anymore. The charts already provide that answer. The question now becomes, “How much risk are you willing to take?”.

Are you willing to commit to the delivery date that comes with the 50th percentile (which, by the way, comes with the same confidence level as flipping a coin)? Or, would you prefer to make a commitment with more confidence and go with the 85th, even the 95th percentile so that you increase the probability of delivering on time?

With Monte Carlo, you don’t have to estimate the relative complexity of your work anymore! The only thing you have to do is decide upon the level of risk you’re willing to manage.

Do You Need to Slice Your Items into Even Sizes for Monte Carlo to Work?

Story sizing into even pieces is a widely-spread activity, which is often considered to be a prerequisite to making reliable future predictions. This is one of the biggest Monte Carlo misconceptions out there.

The size of your work items doesn’t affect the reliability of your forecast because your historical data (the basis of your forecasts) contains work items of different sizes.

The main prerequisite to making accurate delivery forecasts lies in maintaining a predictable workflow.

In a predictable system, we only choose the level of confidence we want to work with. If you know that the nature of the work is complex, there are plenty of unknowns and you have never done this kind of work before, then commit to a higher percentile (95%, 98%). That way, you have a high probability of meeting your goal.

If the work is easy, your delivery workflow is stable and you don’t expect any obstacles along the way, go with a lower percentile (70%). Remember, forecasting is all about managing risks effectively and it is up to you to decide what’s the level of risk you’re willing to live with.

The size of your work can only be a prioritization criterion and it doesn’t impact the accuracy of your forecast in any way.

Does Monte Carlo Account For Story Splitting Altogether?

Let’s take a step back. Just because you have 100 stories in your backlog, this doesn’t mean that these exact 100 stories will be delivered on the date you’ve committed.

That’s not what the Monte Carlo simulation is telling you. What the simulation is telling you is “If you have 100 items, they will be done by date X and there is Y% certainty that you’ll hit that target”.

You’ll probably split your stories, some of them will drop off, more will be added, you’ll discover defects and additional work will inevitably come in between. You can take any 100 items you want, the result of the simulation will still be valid.

Story splitting is about determining whether something is more complex than we initially assumed. If you split your initial story into 4 other stories, that doesn’t necessarily mean that you’ll work on all 4 new stories.

What Monte Carlo is telling you is that you have 100 free slots to deliver on your commitment. Now, it’s up to you to decide, in a continuous manner, how to best fill these slots to meet your customer’s expectations.

Does the Method Consider Your Current Work in Progress?

Yes, absolutely. Monte Carlo doesn’t explicitly specify whether or not your 100 stories have been started yet. These 100 stories may include the work that’s currently in progress as well.

Remember, the Monte Carlo method doesn’t tell you which items will be delivered. It is up to you to prioritize the work effectively, ideally based on cost of delay.

Often, I see teams who work towards a release date use Monte Carlo to figure out how many work items in progress will make it by the deadline. They use this analysis to prioritize the work that brings the highest value and they deprioritize tasks that won’t be delivered in the current release anyway.

The number of items you add to the simulation accounts for both items already in progress and items that haven’t been started yet.

What Data Is Needed for Monte Carlo Simulation to Produce Reliable Outcomes?

The fact that probabilistic forecasts are based on your past performance doesn’t mean that you need a ton of data in order to come up with reliable delivery predictions. Whether you have been collecting data from the very beginning of your board creation, or you are just getting started with new teams, this is beside the point.

If your delivery system is optimized for predictability, then you won’t actually need any more than 20 or 30 completed items to come up with accurate results. It’s not about quantity – it’s all about taking control of your management practices and ensuring you deliver results in a consistent manner.

More importantly, you need to use data from the past that reflects your current conditions. If you’ve recently changed your system design, introduced new process policies, or if there are new people joining or leaving the team, then you have to observe how these changes affect your performance.

And if the impact is significant, then it would be better to only work with the data collected after the changes have been implemented.

How Does the Scaling Factor in Monte Carlo Work?

Now, what if you don’t have data that reflects your future conditions? Let’s say that you need to forecast the delivery date of a project that takes place in December when everyone is taking time off for the holidays, and you don’t have data that accounts for that situation.

If that’s the case, the best thing that you can do is scale down your daily throughput accordingly, so that the simulation accounts for the changes in your performance.

This is where the scale factor in Monte Carlo comes into play.

The scale factor is used for high uncertainty scenarios where you expect drastic changes in the performance of your team, but you don’t have data to account for that.

A 0.5 scale will mean that you anticipate your daily throughput to be twice lower, 2.0 means twice as much as the typical throughput rate.

In the example above, we expect the throughput to decrease by 20%, so we set the scale factor to 0.8. The simulation now tells us that if we have a scope of 20 tasks and we initiate our project on December 1st, there is an 85% chance of delivering on February 7th.

Remember, only use the scale factor if you don’t have the data to work out your scenario. If you do and it represents your current setup, by all means, use that data instead.

Should We Filter Out Certain Data When Running the Simulation?

Here is a $700/hour consulting answer. It depends.

Let me explain. The main goal of the Monte Carlo simulation is to answer the question: “When will this be done?”. This is a customer’s question. In order to provide a reliable answer, you need to think about your work from a customer’s perspective.

How do you define the work that you’ll deliver to your client? If you only have tasks in your system, and that’s how you define the concept of customer value, then you shouldn’t filter out any data.

However, if your scope is defined in terms of stories, and your customer expects a commitment on a story level, you should filter your data by stories to generate the forecast and leave out all other work item types.

What Are the Assumptions Required to Be Made in Monte Carlo Simulations?

The size, nature or complexity of your work doesn’t affect the accuracy of your forecast. The amount of data you have collected is not a factor determining the dependability of the Monte Carlo method.

The only prerequisite to producing reliable delivery forecasts is to optimize your workflow for predictability.

The sole requirement for Monte Carlo (and any other approach to forecasting) to work and give you reliable answers is to use the data produced by a predictable delivery system.

It’s all about taking control of your management practices to ensure you deliver customer value in a consistent manner.

If your delivery system doesn’t produce the results you are hoping for and you’d like to explore the proven roadmap to optimize your workflows for predictability, I’d be thrilled to welcome you to our Sustainable Predictability program!

So, these were the questions that I’ve been asked about Monte Carlo simulations the most often. I hope the answers will help you leverage this fantastic approach to making reliable delivery commitments.

And if you have any others, don’t hesitate to post them below. I’ll address each and every one of them. I wish you a productive day ahead!

The post Monte Carlo Simulation Explained: Everything You Need to Know to Make Accurate Delivery Forecasts appeared first on Nave Blog: Expert tips and guidelines for agile teams.