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.

Once upon a time, I decided to join a digital signage startup.

Back then, Nave was a software development agency and our purpose was to help startups drive their development efforts in the right direction.

The company was aiming to deliver the first streaming service for public displays. Developing a cutting-edge digital signage solution that aims to disrupt the status quo is a big deal, especially if your entrepreneurial initiative is just starting out.

The problem with the current value propositions on the market was that they didn’t provide the possibility to present real-time content. The startup recognized this opportunity and they were very well-positioned to make a huge impact in the digital signage industry.

The cross-functional team consisted of 5 people, who were managed directly by the two founding partners of the company. And what the partners wanted was to have full confidence in the team to hit their targets.

A Sneak Peek Into The Reality

Let me give you some more context.

The demand was overwhelming. Every day a new priority emerged and it wouldn’t necessarily follow any established approach, or aim to bring either customer value or transparency to the decision-making process.

The team had adopted Scrum, but the implementation of the framework was really poor. The thing is, teams can only experience the full benefits of Scrum by understanding and adhering to the values and principles the framework promotes. And here, that simply wasn’t the case.

This is what a typical business day looked like: the managing partners came up with an idea, it felt interesting, and so it was pushed onto the team while they were in the middle of a sprint. There was no attention to the amount of work the team was already handling, and so tasks that were already in progress were constantly being interrupted. And finally, there was an expectation that all of the work should be delivered within the current sprint.

The team was constantly switching their context, suspending what they’d been working on, and starting the new idea that had just arrived. They stayed up till 5 in the morning to be able to meet the impossible deadlines. But, despite their efforts, they were always late. A huge amount of the scope of the current sprint was being moved to the next sprint, and that was happening over and over again.

And the fact is, they simply did not have the capacity to handle the constant stream of new requests. At one point, things became really tough. The managing partners were feeling super frustrated, because the team never managed to deliver the work they’d committed to on the release date, the quality of the deliverables they managed to finish was quite poor and the development cost went through the roof.

I assume it’s needless to say that the engagement and the motivation levels of these people were really low. Fingers were being pointed at each other all the time, the working environment was toxic. The team felt like their work never brought any value. There was no appreciation, trust, or respect. One after another, they started to resign.

It’s Time for a Change

Something had to change immediately! I was actively exploring the Kanban Method at the time, and it felt like exactly the approach we needed. All the concepts behind the method resonated with our current situation.

And probably the main strategy that sold me on Kanban was the data-driven approach to decision-making that it recommended.

It was time to bring some order to the chaos.

Back then, we used Trello to track our work, and there was no Kanban Analytics solution on the market that integrated with this platform. Switching to a Kanban tool was out of the question, so we decided to build our own internal solution. The star of Nave was born.

As we kept building more and more Kanban analytical charts that enabled us to analyze our performance and understand the root cause of the problem, it became obvious that the team needed to align the demand with their capacity and focus on finishing the outstanding work, rather than starting any new work.

At the very beginning, the first thing we did was discard all the aborted work items on the board. This was incredibly difficult for the team; they’d spent their nights and weekends working on these tasks, and it felt like all their effort was for nothing. But, they knew it was the start of a new beginning, so they were still really open-minded about the change.

The next step was to limit the work in progress and implement a Kanban pull system. Let’s dive deeper into the message our data communicated, and how it enabled us to head in the right direction.

Your Data Is Talking to You, Listen

To optimize your workflow performance, you need to break down your delivery times and evaluate the improvement opportunities. This is best achieved by using the Cycle Time Breakdown Chart.

The chart displays the cycle times of your completed tasks split by process state. By analyzing the different sections on the bars, you can assess how the time spent in each state affects the overall time needed to finish your work.

For example, here the data is split by week. In the week Jul 16th – Jul 22nd, tasks spent a significant amount of time in the light pink zone, corresponding to the Code Review (Done) state.

Following on from this analysis, there were two main objectives for the team that came up.

1. They knew that a tremendous amount of the time their work spent in Development was actually caused by suspending what they’ve started. They decided to stop multitasking and only start new work when they had finished their old work.

2. There was an obvious bottleneck in the Testing state. 1 QA was definitely not enough to handle the work produced by 4 developers. As a result, the work was piling up in front of the Testing state – which explained the huge amount of time the work items spent in Code Review (Done).

They decided to allocate multiple developers to the testing phase, so that they could handle the demand and enable the work to move forward. The focus was set on finishing the work, rather than starting new work. And from the beginning of August, you can see the results – these sections were reduced by about 4 times. And that was a huge motivation boost for the team.

You can see what the Aging Chart of the team looked like back in June 2018. There was a high number of aging work items either being blocked by an external dependency or simply being neglected, due to another high-priority item.

And this is what it looked like after we started managing the flow of work effectively. Essentially, what we did was keep track of how much time each work item spent in progress to monitor their WIP age and then follow up on anything that went above the 70th percentile.

The results? A steady flow of work and no more aborted tasks in the middle of the workflow. The entire workload was positioned below the orange zone, which meant our current work took less time than 85% of our previous work.

I want you to take a moment and acknowledge how the ultimate performance improvement that we’d managed to achieve actually had nothing to do with how individuals were performing. It was all about resolving the obstacles that prevented us from delivering on our commitments.

Our throughput became much more consistent, too. Let’s analyze the Throughput Run Chart.

The chart displays the throughput of your team for a specific time frame – you can group your data by day, week, 2 weeks, or month. The horizontal axis represents a timeline, while the vertical axis shows your throughput. Each bar consists of colored sections representing the type of completed work.

Here, we see that up until the end of July, the throughput of the team was very inconsistent. For many weeks, they only managed to keep it at a high level because they were working overtime and pushing themselves beyond their limits to be able to deliver.

After they limited their work in progress and adopted a pull system, the overburden was eliminated and the team went back to normal working hours. The workload was aligned to their capacity. The total working time reduced and as a result, the development cost reduced as well. Their throughput, though, increased and it became much more consistent and predictable.

I have to tell you, at the beginning of all this, the two founders felt really uncomfortable. Knowing that everything was delayed, they felt the urge to push even more work to make up for the delays. Now, they had to put a stop which, naturally, met resistance.

They only managed to shift their mindset once they actually saw the results – the reduced delivery times, the increased throughput, and most importantly, the predictability and the consistency we managed to achieve. Finishing work in progress before starting new work was fundamental for the business.

These approaches were so successful, and they led to such an amazing improvement in the team’s performance and the organizational culture, that I decided to move on and fully dedicate my time and energy to developing the concept of Nave and providing a bespoke value proposition to the market.

You Have the Power to Make a Difference

And this is what I really want you to understand.

If you are struggling to deliver on your commitments, if you want the process of estimating to be easier, less time consuming and to actually work… If you wish to deliver results in a consistent predictable manner, without overburdening your teams…

If you’re tired of the overwhelming stream of incoming requests… If you see how your team falls into the throes of full-fledged burnout while trying to meet impossible deadlines… If you’re looking for reliable approaches to set up and manage realistic goals… It’s time for a change!

It’s time to take control of your management practices and start making reliable decisions!

If you’re willing to explore the proven roadmap to building predictable delivery workflows, I’d be thrilled to welcome you to our Sustainable Predictability program!

You have the power to make a difference. Use that power!

Start as early as tomorrow morning. Don’t delay! After all, continuous improvement builds over time, with one small win following another.

Commit to promoting evolutionary change and a culture of continuous improvement. Commit now. What is the next small step you’ll take to make a difference?

Thanks for checking in and I look forward to seeing you again next week, same time and place for more managerial goodness! Bye for now.

The post This Is My Story… What’s Yours? 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.

It’s that time of the year once again. As we celebrate the close of one year and look towards the beginning of a new one, we’re all inclined to make a little bit of a recap. It’s a fresh new start, filled with exciting new opportunities and the perfect chance to learn from any little slip-ups (after all, we can leave these firmly back in 2025). 

We’ve all made a promise to our business and our teams. We’ve made a commitment to continuously improving our outcomes and changing how people feel about their work. We’ve been optimizing our workflows the whole year long; we’ve been increasing our performance and decreasing delivery times to grow loyalty and building up even more trust with our customers all the while.

But first, let’s go forward by taking a step back. Do you remember why you wanted to improve in the first place? What were the drivers that fuelled your decision to take on that transformation initiative?

Often, with all the energy and effort that goes into each day, we forget to think about why we’re putting in all this work. But you know what? That’s ok! Today, with the new year just about to start, we’re going to return to our initial purpose and remember why it was so important for us.

For those of us who can’t stay still for a second, forgetting why we’ve started is easy.

Let’s try to remember why we wanted to change. Was it because there is too much work to handle at a time? Or was it due to seeing our teams falling into a full-fledged burnout while working hard to meet unrealistic expectations? Did we struggle to hit our targets? Was it because we’ve lost the trust in our team’s ability to deliver or probably we were tired of always being late? Was it because we wanted more transparency, more predictability, more time to spend with our families, more joy of doing what we’re doing…

These are meant to be your reasons for starting down this path of change. But do you still remember them?

Today, we’re going to make a commitment together to stay present and show up differently in 2026.

Let me give you some personal context. Last week, I was reviewing a new digital course and suddenly I found myself opening a bunch of browser tabs. And then, I found myself looking at LinkedIn on my phone. And then my husband Hristo came in while I’m trying to listen, he sat down on the chair right in front of me and he wanted to chat. 

Wait for a second! I was supposed to be present in that session, and in fact, my mind was going in 20 different directions instead.

At that moment, I snapped out of it. I said to myself “this is not how I’m supposed to do things”. I will not be able to achieve what I wanted if I allow this to keep happening. I need to stay present, I need to remember my why. Every time I do something that’s taking me away, I say “today, I’m going to stay present, I’m going to show up different!”. 

When I go to my phone (cause I’m addicted), pick it up and start scrolling, what I remind myself is “I’m going to show up different today”! Just today, and I’m reminding myself that every single day.

Don’t lose yourself in multitasking or forget what’s important. Start being present. Do it once and you’ll feel so proud of yourself. What’s more, you’ll have accomplished so much more by the end of the day by just snapping out of it quickly and keeping your goals at the forefront of your mind. 

And yet, remember that we’re only human, so it’s ok to behave like one. 

When I feel nervous or overwhelmed by the day and this negativity gets stuck in my head, when Hristo sees it, he’ll say to me ‘Sunny, come back here!”. Right away, he snaps me back into the present. He pulls me out of this mind trap back to the present.

What I want to say today is “Come back here!”. You could have lost yourself somewhere along the way, but this is your invitation to remember your why and show up differently today. Play full out! Show up today. That’s my commitment that I’m going to make for myself and I want you to make it for yourself as well.

Embrace your goals once more and start making them come true!

You can’t imagine how much time and energy we waste by wondering and hesitating, searching for excuses, or letting our own insecurities take over. Instead – just be brave and make a difference.

Remember your motivation. What does success mean to you?

Is it more money? That’s fine, I’ve got nothing against money! Maybe it’s to manage happy and engaged people, maybe it’s to make realistic commitments and meet them every time, maybe it’s to do the right things the right way, or to leave the company culture a little bit of a better place than how you found it.

Think about what success means to you, and continue asking yourself that question throughout the year. Although your answer may change over time, do yourself a favor – whatever your answer is, don’t do anything that will jeopardize your goals. 

For the start of the new year, our message to you is this: 

Be present and always remember your why! 

From all of us at Nave, we wish you great success in achieving your goals and dreams in 2026

Merry Christmas and Happy New Year!

The post Our Christmas Wish For You! 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.

Today, I want to share some insights on how to improve your flow efficiency analysis as a Kanban practitioner. If you’re keen on identifying the bottlenecks with the highest impact on your performance, keep reading.

Here’s the thing:

When we try to detect bottlenecks in our process and identify opportunities for improvement, it makes sense to look at the tickets with the lowest flow efficiency.

And we’d use the Flow Efficiency Chart for that purpose.

Agile teams use the Flow Efficiency Chart by Nave to track how much time their work is staying and waiting in their process. Give it a try now, it’s free for 14 days, no strings attached →

The histogram is very useful to see the work items with the lowest flow efficiency. But often, cards with low flow efficiency also have very low cycle times.

For example, imagine a card with a cycle time of only 2 days. If it was waiting for 1 and a half days, it would show 25% flow efficiency. That’s not particularly interesting for the team to improve.

What’s more interesting is a card that has 25% flow efficiency and a cycle time of 8, 10, or 15 days. So, how do we filter out cards that have lower cycle times?

Here’s How to Improve Flow Efficiency Analysis

When performing flow efficiency analysis, it’s important to focus on the tickets with longer cycle times and low flow efficiency.

And the easiest way to achieve that is to convert the histogram to a scatterplot.

Use the switch button on the top right side of your chart at Nave to convert the Flow Efficiency Histogram to a Flow Efficiency Scatterplot!

The Flow Efficiency Scatterplot shows Flow efficiency % on the X-axis and Cycle time on the Y-axis. Now, with that visualization, you can cross-reference a task’s flow efficiency and cycle time.

The work items on the top left part of the screen are those with the highest cycle time and lowest flow efficiency. These are your best opportunities for improvement.

By enabling the scatterplot feature, your teams will be able to address opportunities for improvement quickly. At the end of the day, taking action is what matters the most.

Take your analysis to the next level!

Once you have identified the key areas for improvement using the scatterplot, the next step is to implement changes and track their impact.

Once you prioritize the work items in the top left quadrant of your scatterplot, discuss what caused the long cycle times and low flow efficiency and brainstorm potential solutions.

Put your initiatives into practice and use Nave’s analytics suite to monitor the impact over time. Adjust your strategies as needed.

One last tip:

Don’t forget to celebrate your wins. As you see the needle moving in the right direction, make sure to celebrate these milestones with your team. Recognizing success keeps everyone motivated and committed to continuous improvement.

Join the Community of Agile Teams

You’re not alone in this journey. Over 7,000 agile teams are already benefiting from the powerful insights provided by Nave. By leveraging these tools, you’re setting your team up for success.

Ready to get started? Go ahead and give the Nave analytics suite a try now. It’s free for 14 days, no strings attached →

So that’s it, my fellow Kanban practitioners. If you want to elevate your flow efficiency analysis, consider this feature. And if you found this useful, please share it with your team or anyone else who might benefit.

Thanks for tuning in, and I’ll see you next time! Have a great day!

The post Kanban Practitioners, Here’s How to Improve Flow Efficiency Analysis appeared first on Nave Blog: Expert tips and guidelines for agile teams.

It’s astonishing to see in practice how a simple pull strategy can improve the predictability of your delivery system so significantly, even after just a couple of months.

The Wizards are a development team, working for a start-up digital signage company, which delivers the first streaming service for public displays. Developing a cutting-edge digital signage solution that aims to disrupt the status quo is a big deal, especially if you’re just starting out with your entrepreneurial initiative.

The problem with the current value propositions on the market is that they don’t provide the possibility to present real-time content. The Wizards’ company recognized this opportunity and they were very well positioned to make a huge impact in the digital signage industry.

The Wizards are a cross-functional Scrum team consisting of 10 people, delivering batches of work every 14 days to their stakeholders. The stakeholders review the deliverables and provide feedback to adjust the course of action accordingly. The Wizards were proficient in implementing the Scrum framework and they were widely considered successful because they delivered a consistent velocity on a sprint-to-sprint basis.

However, from a flow perspective, there were inefficiencies in the Wizards’ development process. The fact that their delivery workflow didn’t operate effectively hindered both their delivery times and their predictability and the Scrum velocity metric would not have exposed this.

The stakeholders wanted to have high confidence that the team would be able to achieve their goals. And it was a matter of applying a simple pull strategy that led to a tremendous improvement in their predictability, all in just 2 months.

Analyzing the Predictability of the Wizards’ Delivery System

One of the most suitable approaches to demonstrating the predictability of a delivery system is using the Cycle Time Scatterplot.

The dotted horizontal lines stretching across the graph are called percentile lines. They represent the time taken for past work to be completed. In the Wizard’s diagram, the 50th percentile points to 10 days. This means that half of the work has been completed in less than 10 days. The other half though has taken up to 130 days to be finished. In 95% of the cases, the team needed up to 76 days to deliver the work they had started.

If you’re running 14-day sprints, these numbers are quite bad. If in 50% of the cases the work was finished within 10 days, this means that stories that started at the beginning of a sprint only had about a 50% chance of being completed within that same sprint. This is not a predictable system.

If you look closer at the values that come with each percentile, you’ll notice that there is a significant gap between them:

The closer the cycle times on your percentiles are, the more predictable your system is. So, the main goal of the Wizards was to reduce these gaps.

Looking into their Scatterplot, the team started to dig deeper into the root cause behind their long delivery times. It turned out that they were pulling the smaller, quicker work items first, while the bigger, more complex items artificially aged within the process. There was no pull strategy in place that would have enabled them to prevent that behavior.

Applying a Simple Pull Strategy Tremendously Improved the Wizards Delivery Times (in Less Than 2 Months)

The team decided to introduce a pull policy that dictates the order in which work items in progress should move through the workflow so that their stories don’t age indefinitely. The focus switched to analyzing the age of each item in progress and progressing with those with the highest age first.

The Aging Chart came in handy for that purpose.

The dots on the top move forward first. By following up with the items with the highest WIP age first, the Wizards can ensure that there is no abandoned or delayed work left in the process. Sometimes, this would mean that the items that were started later had to wait until the older items were completed first, but this is perfectly fine from a predictability perspective.

The team used this pull strategy to give priority to the items that spent the most time in their workflow in order to improve their predictability.

The results? After two months, their Cycle Time Scatterplot looked like this:

The team was able to get 95% of their stories completed in 13 days or less. Their delivery times at the 95th percentile were reduced by over 80%. This is what their cycle times looked like:

Can you see that the gap between the 85th percentile and the 95th percentile is only 2 days? This means that now the Wizards can deliver any item in 13 days or less and there is a 95% chance that they will meet that commitment. The predictability of their system, first and foremost, was dependent on how effectively they were managing the flow of work. 

If you’re interested in learning about how to build a stable predictable delivery system and meet your commitments by delivering on time, I’d be thrilled to welcome you to our Sustainable Predictability program.

DOWNLOAD THE WIZARDS USE CASE IN PDF FORMAT

Use this PDF as a reference when assessing your explicit policies and evaluating the predictability of your delivery system.

LEARN MORE

Keep in mind that the Wizards didn’t change how much time they spent working, how many people were working in the team, or the nature of the work itself. Nothing else changed. Applying this simple pull strategy of handling the item with the highest age first resulted in a tremendous improvement in the predictability of their system.

The Wizards have exceeded their stakeholders’ expectations ever since, delivering off-the-charts solutions to their customers in a stable, predictable manner.

Alright, my friend. Thanks for tuning in. I’ll see you again next week, same time and place for more managerial insights. Have a wonderful day!

The post How the Wizards Scrum Team Immensely Improved Their Predictability in Just 2 Months (all by Applying a Simple Pull Strategy) 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.

Managing blockers effectively is the first step towards revealing the obstacles that cause delays and hinder your delivery speed. One of the practices that drive continuous improvement is blocker clustering. The blocker clustering technique enables you to track the impact that blockers have on your performance and prioritize those that affect your delivery times the most.

The blocker clustering analysis consists of the following steps – identify your blockers, capture your total blockers’ time, and determine the root causes of the most impactful blockers. Let’s go through each of the steps in more detail.

Identify Your Blockers

The first step towards evaluating the obstacles that block your work from moving further in your workflow is to identify your blockers.

At the moment a work item is getting blocked, think about the reason behind it and identify what is causing the work to get stuck.

Collect all the blockers and organize them into groups. The groups might be External Dependency, Internal Dependency or Expedite Request, just to name a few.

Create a custom field on your board i.e. Blocked Reason and add the groups you have identified as options to your new custom field. Now, when a new item gets blocked, you can associate it with any of your blockers. You can also modify the custom field to include new blocker groups to keep it up to date.

Once the card is unblocked, remove the custom field option from it. The goal behind adding and removing a blocked reason to the card is to track the time that each card spends assigned with a certain blocker to be able to evaluate the impact blocked time has on your overall delivery time.

Capture Your Total Blocked Time

The next step of the blocker clustering analysis is to prioritize the most impactful blocker that causes delays in your delivery. The trick here is to count the total days your work spent blocked and split that data into each of the blocked reasons you have identified.

Our Cycle Time Breakdown Chart collects that information automatically, in order to help you identify the blocker that is increasing your delivery times the most.

The above Cycle Time Breakdown shows that 38% of the blocked time is being caused by Unclear Requirements and a further 32% by Expedite Requests. These two groups are the most impactful groups of blockers that cause delivery delays.

Determine the Root Causes of the Most Impactful Blockers

What possible solutions can we suggest to resolve these impediments? A very effective technique that you can use to figure out the root cause of the problems is the 5 Why’s approach. You ask ‘why’ multiple times over, and each answer leads you to the next question in the chain.

Blocked reason: Unclear Requirements 

Why are the requirements supposedly unclear? Because a description of what is expected to be delivered has not been provided.

Why is that? Because there are no clear requirements on how a card should be structured before it is pulled into the system.

Why? Because we haven’t adopted concepts like Definition of Done, Definition of Ready or Acceptance Criteria.

What we have to focus on now is defining a clear DoD, DoR and AC, which would guarantee that the team knows exactly what they need to do to deliver results in a timely manner.

By eliminating this blocker, this team effectively reduced their delivery times by almost 40%. Drastically improving their overall performance all came down to a matter of introducing a new management practice.

Blocked reason: Expedite Requests

Why do expedite requests block work to such an extent? Because there are too many expedites in the system, which are constantly interrupting the work we have started.

Why is that? Because there is no clear definition of what an Expedite is, and most of the items just got assigned with this CoS based on intuition.

Why? Because we don’t prioritize our work based on the Cost of Delay and properly consider the risks that we have to manage.

Most likely, you need to look into the practices you have in place to better prioritize your work. Think about building a dynamic prioritization system based on the value your work brings to your customers, instead. In our Sustainable Predictability digital course, we explore the strategy of sequencing your work items, in accordance with the benefit they bring to your business, right from the moment you add them to your backlog. We’ve cut out the need to spend time reordering to-do lists.

By looking into the approach of prioritizing work based on the cost of delay and the market opportunities it realizes, this team has the potential to reduce their delivery times by a further 30%.

Manage Defects the Same Way You Manage Blockers

Although teams often track defects differently from blockers, defects can be clustered in exactly the same way as blockers, so you can investigate their root causes and work on their prompt resolution by going through these same steps.

Software defects are often the main obstacle to revealing the full potential of our solution to the market. Defects are expensive, especially when they make their way to production. The challenges behind developing quality software solutions, like constant market demand and lack of time, will remain. The cost of defects is likely to rise if we don’t commit to continuously improving our development practices.

To perform defect clustering, you can use the exact same approach that we described in the blocker clustering analysis, and use the Cycle Time Breakdown Chart to perform an analysis of the most impactful defect causes.

If you’re interested in building a delivery system that enables you to deliver on your commitments consistently, I’d be thrilled to welcome you to our Sustainable Predictability program.

Improvement is not a one-off task – it happens over time, with each new improvement building on the one before. Very often, small tweaks in your management practices will lead to a significant improvement in your performance.

Prioritizing blockers and continuously working upon the root causes that prevent your work from moving smoothly through your process is a highly effective approach to take towards reducing delivery times and fostering an environment of continuous improvement.

Thanks for checking in and I look forward to seeing you again next week, same time and place for more managerial goodness! Bye for now.

The post How to Reduce the Impact of Blockers on Your Delivery Times by Using Blocker Clustering 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.