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.

I’m delighted to welcome Yuri Kudyn, Yuri Lapin, and Filip Tomaszewski to today’s conversation. These are the brilliant minds behind Release Management‘s Advanced Kanban Boards (AKB), a tool that fundamentally changes how teams work with Jira.

What makes their work particularly valuable is how it solves a problem nearly every Kanban practitioner faces: Jira is non-negotiable, but it lacks the features true Kanban implementation requires. The combination of AKB and Nave’s Kanban Analytics Suite creates what I consider the complete Kanban solution for Jira, enabling the policies and practices teams need without forcing them to abandon their existing toolchain.

I’m excited to explore how AKB helps teams visualize end-to-end flow, apply work-in-progress limits effectively, and maintain the human-centered focus that makes Kanban powerful.

Seeing the Complete Picture

“In Kanban, it’s very important to see everything from idea to completion,” Yuri Kudyn explained. “Only then can we see how value is created, identify bottlenecks, and build a truly efficient flow.”

The problem? Most teams cut their flow into pieces. Product management gets one board. Engineering gets another. Marketing gets a third. Each board looks manageable, but the full picture disappears.

Yuri Lapin shared a telling example: “We had a client with separate boards for each function. Everything looked fine inside each board, but backlogs kept growing and time in the backlog kept increasing. They never saw it because they didn’t have one single view of value creation.”

Creating one massive Jira board sounds like the solution, but anyone who has tried knows it becomes unusable. Columns stretch endlessly across the screen.

AKB solves this problem. Teams can zoom in and out, collapse or expand any column, and save custom views for different roles. DevOps engineers see only deployment columns. Testers see testing stages. Product managers see requirements preparation. Everyone works on the same board but focuses on what matters to them.

“We can pre-define views and save a lot of time,” Yuri explained. “No more clicking around constantly.”

Column groups take this further. Teams can group columns by function (like all engineering steps) and apply policies to the entire group, not just individual columns. The board stays readable while showing the complete flow from idea to production.

WIP Limits That Support Your Maturity Level

Here is where AKB truly delivers on the Kanban promise. In my opinion, a Kanban board cannot be called a Kanban board if there are no WIP limits on it.

AKB provides WIP limits at multiple levels, which perfectly supports teams at different stages of their journey.

For teams just starting with flow management, personal WIP limits help individuals avoid overload. “We can assign a work in progress limit to each team member,” Yuri noted, “so we can spot who is overloaded and who is not.”

As teams mature, column-level limits keep work moving. But the real power comes with column groups, especially when combined with doing and done separation.

“We can apply work in progress limits not only to certain work like architecture review or code review, but to the whole engineering function,” Yuri explained. “And we can see how our people are busy.”

This matters because done columns are parking lots. Work sits there waiting. Without limits on these queues, they become black holes. AKB lets teams mark columns as active or waiting, then automatically calculates efficiency scores based on where work actually spends its time.

Swimlanes add another dimension. Teams can allocate capacity by work type, dedicating 70% to strategic initiatives and 30% to maintenance, for example. Each swimlane gets its own WIP limit, ensuring the team stays aligned with business strategy while managing day-to-day work.

Keeping Work Moving and Visible

Blockers kill flow. AKB makes them impossible to ignore.

Beyond Jira’s basic flagging capability, AKB lets teams specify impediment reasons using custom fields. Hovering over the flag shows the reason immediately, no clicking required. Over time, teams can analyze which blockers happen most often and eliminate root causes.

Dependencies get the same treatment. Visual links on the board show connections between work items, with different colors for different link types. Critical blockers appear in red. A special window tracks dependencies outside the team, separating internal and external coordination needs.

But here is what really impressed me: health indicators.

Teams set thresholds for acceptable time in each column. Instead of mentally tracking dozens of variables, a simple color-coded indicator shows green (all good), yellow (warning), or red (problem).

“We see that the aging limit for the whole flow is exceeded,” Yuri demonstrated. “Also on column groups, we’re developing more than expected. We have more returns than expected. Efficiency is low. Such indicators show items where we need to pay attention.”

Returns between columns are particularly insidious. Work might not violate WIP limits or stay too long in any one column, but ping-ponging back and forth destroys efficiency. AKB tracks how many times each item returns and flags excessive movement.

Finally, AKB makes process policies accessible where teams actually work. Instead of burying definitions of done in Confluence pages no one reads, teams add them directly to columns, column groups, or the entire board. Hover over any column to see its exit criteria and agreements.

“Information should be easily accessible,” Yuri emphasized. “We believe in information radiators, not information refrigerators. You don’t need to open it and look inside.”

If you’d like to explore Advanced Kanban Boards, you can find it in the Atlassian Marketplace.

For deeper discussions or to book a demo, visit their website and use the “Book a Demo” option. Mention “NAVE” in the description to access the special offer and get tailored guidance on your specific use case. The team will discuss how to solve your problems based on their experience with other clients and their Agile and Kanban consulting background.

AKB makes Jira work the way teams need it to work. Combined with Nave’s analytics, teams finally get the complete picture: how work flows, where it gets stuck, and what to do about it.
I wish you a productive day, and I’ll see you next week, same time and place, for more managerial insights. Bye for now!

The post How to Build Real Kanban Boards in Jira 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.

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.

I had the pleasure of speaking with Allison Bacher, also known as the Agile Angel, one of the most thoughtful voices at the intersection of coaching, data and AI. Allison has spent years working with CTOs and product leaders, helping their teams perform at a high level while staying human-centred and commercially grounded.

She is also the co-creator of Performalise, an AI-powered coaching platform that shines a light on what she calls the “silent data” behind team performance.

I am excited to share her insights on blind spots in coaching, how AI can help at scale and what it really takes to prove the value of agility in the boardroom.

Seeing the Blind Spots Coaches Cannot Avoid

Most Agile coaches work across several teams. Different locations, different time zones, different levels of maturity. It sounds normal, but Allison is very clear about what this means in practice.

“Agile coaches do not scale,” she told me. “We are not in every meeting. We do not hear every comment. By the time something shows up in a retrospective, the moment for a real intervention has already passed.”

Those missing moments create blind spots. Teams may share curated metrics or filtered feedback, and important patterns stay hidden.

This is where Allison sees AI as a partner rather than a threat.

“We can use AI to look for patterns in flow, churn, rework, stakeholder satisfaction and even team confidence,” she explained. “It picks up the behavioural signals we would never see in real time on our own.”

Instead of relying only on what teams choose to report, coaches can work from a richer picture of how the system actually behaves.

At scale, the challenge becomes even sharper. A few coaches. Many teams. A lot of pressure to tell leadership what is really happening.

Allison is careful about the role of metrics here.

“A single metric is a very blunt instrument,” she said. “Velocity on its own does not tell you anything useful. What matters is clusters of metrics that show trends. We do not want to become the metrics police. We want to be the people who see the patterns.”

She emphasises that the intent is never to compare teams or name and shame. Instead, AI can highlight where refinement is weak, where work repeatedly rolls over, or where stakeholder engagement is low.

“If I have 5, 10, even twenty teams, I do not need to look at everyone every day,” she said. “With the right metrics and dashboard, I know exactly which five I need to see today and why.”

The result is more focused coaching and less noise for teams.

Proving That Agility Is Working

Sooner or later, every coach hears the question: “Is this Agile thing working?” Often very early, sometimes after the very first sprint.

Allison’s advice is to start in the executive’s world, not ours.

“We have to get in their shoes first,” she said. “What do they actually care about? Time to market. Risk. Customer outcomes. If we answer with story points and velocity, it does not land.”

Instead of promising that things will be faster, cheaper and better, she suggests using “rich data” that connects directly to outcomes.

“Show them that quality is improving. Show that cycle time is coming down. Show how better stakeholder engagement is reducing rework,” she explained. “When you have trends and leading indicators, they relax. They can see that we see the risks early and that we are on it.”

AI helps by turning thousands of small data points into readable patterns. Coaches no longer have to spend hours assembling spreadsheets. They can spend that time explaining what the data means and what needs to change.

Of course, AI brings its own fear. Some coaches ask her directly whether tools like Performalise are meant to replace Scrum Masters. Allison does not hesitate.

“No!” she said. “AI is there to do the work humans cannot do at scale. It handles repetitive analysis so we can focus on the human conversations. It moves us from reactive, after the car crash, to proactive, seeing that a crash is coming and going there now.”

“But AI is not taking away the judgement or the relationship. It is taking away the parts that machines are better at, so the humans can do the work that only humans can do.”

Silent Data and Performalise

Toward the end of our conversation, Allison introduced the idea of “silent data”.

“It is the data that tells the real story. The comments people make in daily scrums, the sentiment in reviews, the small signals that never make it into a slide deck.”

Performalize sits on top of tools like Jira or Azure DevOps and focuses on these human aspects of performance. It helps coaches see patterns across teams and gives leaders a more truthful picture of what is happening.

If you would like to explore Performalise, you can visit performalise.com or go to performalise.com/partner if you are a coach interested in working with the platform.

Allison’s insights are a powerful reminder that real agility is not just about boards, backlogs and ceremonies. It is about seeing what is really happening, telling the truth with data and keeping the human conversation at the centre of change.

I wish you a productive day, and I will see you next week, same time and place, for more managerial insights. Bye for now.

The post How AI Amplifies Agile Coaching: Allison Bacher’s Approach appeared first on Nave Blog: Expert tips and guidelines for agile teams.