A Leader’s Guide to Agile - What to pay attention to and what you don’t need to

A Common Problem

If you lead a business or a function that has a software development team, there’s a good chance someone has tried to explain Agile to you at some point. There’s also a good chance that explanation involved words like velocity, story points, sprints, retrospectives, and epics, and left you none the wiser about whether your team is actually going to deliver what you need, when you need it.

That’s not your fault. It’s not necessarily theirs either. It’s a communication problem and it causes a lot of unnecessary friction between technical teams and the leaders who depend on them.

I’m an Agile advocate

I’ve spent more than 30 years in technology, starting as a developer, moving through architecture and business partnering, and spending the last 15+ years in senior leadership and CTO roles. I’ve championed Agile throughout that journey. I’ve seen it done brilliantly and done badly.

What I’ve learned is that most leaders are asking the wrong questions about Agile, and as a result, they’re either over-invested in the wrong things, or not invested enough in the right ones.

So here’s a straightforward guide. What you should care about and what you don’t need to.

What you should care about

1. Can your team make a commitment, and do they have the means to track it?

This is the fundamental question. Not whether they’re “doing Agile.” Not what methodology they’re using. Not how many story points they completed last sprint.

Can they tell you what they’re going to deliver, and when? And can they tell you, at any given point, whether they’re on track to deliver it?

Done well, Agile is an exceptionally powerful forecasting tool. A well-run team with a prioritised backlog and a stable work rate can tell you, with genuine confidence, when a body of work will be complete, assuming the scope doesn’t change materially. They can also tell you early when something is at risk, which gives you time to respond, adjust scope, add resource, have a real conversation with the business.

Can they tell you whether they’re on track to deliver?

That early visibility is the thing. In traditional project management, you quite often find out too late that there’s a problem, and by then the only options are overtime, pressure, and cutting corners. Agile, done properly, gives you time to make better decisions.

So ask your team, “If nothing changes, when will this be done?

If they can answer that confidently, and update you regularly as things evolve, they’re giving you what you need. If they can’t, you’re operating in the dark and you need to tackle it.

2. Is the team communicating well and surfacing problems early?

The best Agile teams I’ve worked with don’t look like Agile teams from the outside. They look like highly effective teams who communicate clearly, raise issues early, and deliver what they say they will deliver, when they say they will deliver it.

What you’re looking for as a leader is a team where:

• The plan for the week, the month, the quarter is clear

• Problems and blockers are raised in a timely way, not buried

• You’re not getting surprises at the end of a delivery cycle

If those things are happening, the process is working, whatever it’s called. If they’re not happening, no amount of Agile methodology will fix it.

3. Is the team healthy and motivated?

This one gets underestimated. A happy, motivated team that gets a regular sense of achievement from regularly releasing value is a leading indicator of success. It’s not soft, it’s practical. Happy teams deliver. Unhappy teams don’t, or not for long. Simple as that.

Good Agile gives teams autonomy, a clear sense of purpose, and frequent moments of genuine accomplishment.

A happy, motivated team is a leading indicator of success.

If your team is miserable, or if good people keep leaving, something has gone wrong, and it’s worth understanding whether the way of working is contributing to that.

If your team is miserable, something has gone wrong

What you don’t need to worry about

1. Which methodology they’re using

Scrum. Kanban. XP. Scrumban. SAFe. These are implementation choices. As a leader, you don’t need to know the difference, and it doesn’t really matter which one your team uses. What matters is whether it’s working for the, and you can assess that through the lens of the questions above, without needing knowledge of the methodology itself.

If your team can tell you what they’re delivering and when, and they’re consistently doing it, the methodology is working. If they can’t, the methodology isn’t the problem, and changing it probably won’t fix it either.

2. Story points, velocity, and other internal metrics

Velocity, a measure of how much work a team completes in a given period, is a team-internal forecasting tool. It’s useful for the team’s own planning. It is not a measure of performance. It is not comparable between teams. And it should almost never appear in a conversation between a development team and an executive stakeholder.

A leader looking slightly bewildered by his agile team bombarding him with jargon

If someone tells you Team A has a velocity of 30 and Team B has a velocity of 50, the appropriate response is to ask what that means in terms of delivery dates and outcomes. Definitely don’t conclude that Team B is better, or that Team A needs to go faster. Velocity is a relative, internal metric. Comparing it across teams is like comparing the lap times from two different racetracks and concluding one driver is faster.

Velocity should almost never appear in a conversation with an executive stakeholder.

The risk is that when leaders start making comparisons based on velocity, teams game the numbers. They adjust their scoring scale, their estimates suddenly double, and the metric becomes completely meaningless. The trust between the team and leadership quietly erodes, and nobody wins.

What you can legitimately ask about is throughput. How many pieces of work is the team completing, and is that rate stable or improving? That’s a real signal. But the story point detail underneath it? Leave that to the team.

3. The ceremonies and rituals

Stand-ups. Sprint reviews. Retrospectives. Refinement sessions. These are the team’s tools for maintaining discipline, communication, and continuous improvement. They’re valuable, but they’re not for you.

You don’t need to attend a sprint review unless you’re genuinely interested in the detail of what’s being built and can offer useful feedback. You don’t need to know whether the daily stand-up is ten minutes or twenty. You don’t need to know if they’re literally standing up.

What matters is the output of those practices, not the practices themselves. If the team is communicating well, adapting to change, and delivering reliably, those ceremonies are doing their job. You don’t need to inspect them.

4. Whether they call it Agile at all

This might be the most important thing on this list. If your team is delivering value regularly, asking for and incorporating feedback, and willing to change course when the situation demands it, they’re entitled to call themselves Agile, regardless of what they call their process or which method they’re aligned to.

Conversely, if they’re following every ceremony and principle of a recognised Agile methodology but not shipping value regularly, not adapting, and not communicating, they’re not Agile, regardless of what they call themselves.

The label doesn’t matter. The outcomes do.

If the team delivers value regularly, seeks feedback often, and acts on that feedback when it needs to, they can call themselves agile.

The thing leaders get wrong most often

The most common mistake I see from leaders around Agile isn’t being too hands-off. It’s actually the opposite. Getting drawn into the wrong level of detail, usually because of a communication failure somewhere.

When a team uses language that a leader doesn’t understand, the leader has two choices. They can disengage, or they can try to engage at the wrong level. Neither works. And the root cause is almost always that the team hasn’t translated its work into terms the leader can actually use.

If your team is talking to you about velocity and story points, or issue count and throughput, and you’re finding it opaque, that’s a legitimate thing to call out. Ask them to translate.

Ask them, “Given where we are, what’s your best view of when this will be done, and how confident are you in that?”

That’s the question that cuts through the jargon and gets to what you actually need to know.

A good team should be able to answer that clearly. If they can’t, it’s worth exploring whether the process is generating the visibility it should be.

When someone says “we need to be more Agile”

A word of caution about a phrase that gets misused a lot, including by leaders.

When executives say “we need to be more Agile,” what they often mean is, “we want uncontrolled and unfettered change, daily”.

But it’s not what Agile means, and acting on that interpretation will make things worse.

True agility isn’t about less discipline. It’s about more discipline, focused on the right things: delivering value regularly, seeking feedback, and being willing to change course when the evidence suggests you should.

True agility isn’t about less discipline, it’s about more

Importantly, a well-run Agile team is actually your best protection against the chaos that can come from constant change of direction. Because good Agile makes the cost of change visible. You can say, “yes, we can take on this new priority, but here’s what that means for the work currently in flight, and here’s the decision we need you to make”.

That’s not a barrier to change, it’s disciplined change management.

So if you find yourself wanting to say “we need to be more Agile”, pause and ask what you actually want. Faster delivery? Better forecasting? More responsiveness to the market? Those are legitimate goals. Good agile practice will help you achieve those, but poor practice will hold you back.

In summary

You don’t need to understand Agile in depth to lead an organisation that uses it well. What you need is clarity on a small number of things:

Pay attention to, whether your team can make and keep commitments. Whether they have genuine visibility of their progress. Whether problems are surfacing early. Whether the team is healthy and motivated.

Don’t worry about, which methodology they use. Their velocity or throughput. Their story points or issue count. The specific ceremonies they run. What they call any of it.

Ask often, “what are we committed to deliver, and are we on track?”. That question, asked regularly and answered honestly, will tell you almost everything you need to know.

The best-run teams I’ve ever worked with looked, from the outside, like they were barely trying. They just said what they were going to deliver, and then delivered it. The process was invisible, because it was working.

That’s the goal. Not Agile for its own sake. Delivery, trust, and the confidence to forecast.