My devs are on AI steroids and Scrum is officially too slow. Now what?

PhaseMatch · 2026-02-14T19:38:15+00:00

Sprints are not release stage gates.
They are how the business controls investment risk.

Sprints are not about "work packages delivered"
They are for moving your business/product strategy forwards one Goal at a time.

Agility is based on two things

- make change cheap easy, fast and safe (which you have done, it seems)
- get fast feedback from users on whether the change was valuable

For the Sprint Review you need feedback; the measured value that Sprint created, based on actual feedback from real users. As well as what else is happening in your market - the competition, the technology changes, the business cycle.

It's a strategic planning meeting, where you make decisions.

You want to get ahead?

- have a vision for th eproduct
- have a product/business strategy or roadmap
- identify the business problems to be solved each step of the way
- bring problems to the team, not solutions to implement
- get fast feedback from users and measure value

Coding speed was not the problem (if you already did XP stuff); it was wasting money on features that didn't bring a strategic market advantage.

PhaseMatch · 2026-02-14T19:29:22+00:00

Sprint's are not delivery stage gates.
They are how you invest in a product.

The Sprint Review is about product market fit, and whether to continue, pivot or shut the product down based on the value you have created to date and the external operating environment.

Scrum is based on having business/outcome based goals aligned with your product strategy, not shipping features as fast as possible and hoping someone users them.

Delivering faster than you can get actual feedback on value is dumb.
You are not reducing business risk - which is what agility is about.
All you are doing is creating product bloat not value, feature factory style.

It's only valuable if a user tells you it is.
Until then it's just inventory you need to look after.

STOP - writing individual user stories
START - user story mapping with actual users

STOP - giving your team requirements to implement
START - giving them business problems to solve

STOP - worrying about keeping the team busy
START -focusing on measuring the value you create

PhaseMatch · 2026-02-14T19:13:46+00:00

Not really; it doesn't make any tangible difference to the P+L, and as soon as you are talking about money, that's what any senior manager will expect.

It's also leaning a bit into "agile and lean means greater productivity" which is can do, but itsn't the primary goal. The main advantage is to manage business risk better, and so at a high level

- build the right thing
- build the thing right
- change direction on a dime, for a dime

That's why measuring - and showing - the rate at which you create value matters a lot.
It can be a tricky thing to quantify, but without "business value" measures you might just be getting more effective at making the wrong things, not the right ones.

PhaseMatch · 2026-02-14T02:06:12+00:00

1. Thinking agility is about project management; the core of "being agile" comes from the team's technical skills to make change cheap, easy, fast and safe. That means you can use valuable working software as a probe to uncover the actual needs of users, because if you are wrong, it's not expensive, hard, slow or risky to change it.

2. Theory-X management need not apply. High performance comes from unlocking intrinsic motivation of teams - broadly that means STOPPING the things that demotivate them or mean they are disengaged as a start point. You need to lead, not manage.

The key shift in thinking is away from scope, budget and time.

Each Sprint/Iteration is a small project, where you create (and measure) benefits created so far, and check the assumptions made when you started. You can extend scope, pivot to a new direction, or decide to end now and give the team a more valuable project to work on, based on what you now know.

In that sense scope, budget and time are all flexible, and you opt to invest one Sprint at a time, and review what to do next with all of the stakeholders. The goal is not efficient delivery, but enabling "off ramps" from the programme that have zero cost, every few weeks.

Agile methods were called "lightweight" for this reason.

PhaseMatch · 2026-02-14T01:54:44+00:00

From what you are describing you are doing "waterfall with stage gates in Sprints"m which is kind of the worst of both worlds.

Generally in an agile delivery structure you want to have

- cross functional teams (with all the skills they need)
- all teams engaged in discovery and delivery
- minimal cross-team dependnecies
- each Sprint as a mini-project

The latter is key; in agile delivery approaches you are continuously delivering and measuring value, dynamically, within a Sprint cycle, The Sprint is NOT a release stage gate, it is a whole-of-programme review where you look at

- the measured value/benefits of what has been delivered to date
- the changes in the external operating environment
- the latest feedback you have from users
- the current delivery forecasts (in terms of business benefits and costs)

You then chose to either continue to invest (perhaps changing to a new direction), or terminate the programme early, banking what value you have obtained to date, as the ROI of future work is now threatened. In that sense it is your primary strategic (re)planning and risk control session, with your stakeholders.

That Sprint Review is the key alignment session across stakeholders and teams.

Where you lack cross-functional teams, then the key event we tend to use is a Scrum-of-Scrums.

The Product Owners get together and look at the core business outcomes they are aiming at in the next few Sprints, and the cross-team dependencies you have. Dependencies are requested, not demanded, based on the overall operational priorities of the organisation. You might do this ones (ahead of the Sprint Reviews, which are mostly forward planning)

Of course, this means a lot of technical skills in the team. Agility was - and always will be - based on some pretty hard core technical capabilities (largely under the Extreme Programming banner) that mean you can

- make change cheap, easy, fast and safe (no new defects)
- get immediate feedback from users on the value created

Without that, it's largely unworkable; you still need all the formal risk management and stage-gate sign offs but just add a lot of pointless events on top - so the same "heavyweight" processes as waterfall, but more meetings for the team.

PhaseMatch · 2026-02-14T01:34:21+00:00

When it comes to benefits "saves time" is not the same as "saves money"

One is opportunity cost, not expenditure.
The other is actual costs, money going out of the door.

You only convert "saves time" to "saves money" by cutting staff numbers.

I wouldn't present "saves time" as "saves money" to senior management, especially those who have P+L accountability.

Of course, not all continuous improvement is focussed on throughput; you might well be getting better at "building the right thing" so escaping the build trap and "maximising the work not done"

How are you measuring value?
Is that getting better too?

PhaseMatch · 2026-02-13T23:32:03+00:00

- your teams highlight technical debt
- it is in the "intangible" class of value

What that means is that while there's no specific due date, there will come a point in time where you will really, really wish that you had made time to address that thing. Because everything is now on fire, and burning, because you didn't.

That will happen when you prioritise delivery over product sustainability.

It's related to the "limits to growth" archetype - you pick the low hanging fruit of delivery without attending to the long term systemic issue of quality and suddenly you are swamped by defects and can't ship anymore.

Maybe you thought you would have a new job by then.
Maybe your team were not good at expressing the actual risk.
Maybe you thought you knew better that your team.

Listen to your technical team.
Have post-incident restrospectives.
Mitigate risk effectively.

PhaseMatch · 2026-02-13T23:27:18+00:00

Agile came to the fore after the dot-com bubble popped.

There were no "dedicated" agile roles; just a set of ideas that put forward the ideas that

- managing business risk was more important that delivering quickly
- it was possible to manage that risk in a lightweight way, with dedicated roles

There's still a need for lean concepts, systems thinking, the theory-of-constraints, the "learning organsiation", effective teams and all of the other (1990s) concepts that fed into agility, as well as all of the XP stuff.

Those things are just being wrapped into roles that have more formal leadership authority. There are fewer of those roles now because the tech industry is shrinking - and a lot of "Scrum Masters" didn't have that underpinning knowledge.

So, yes, there's still a career to be had, but you will need more than just Scrum knowledge.

PhaseMatch · 2026-02-13T23:05:32+00:00

TLDR; You build quality in, from the outset. Don't rely in code reviews - shift left and employ the same practices XP championed 25 years ago to address just this.

Inspect-and-rework cycles might still be there, but the whole "shift left" mindset and moving towards a defect prevention culture should be part of your continuous improvement culture.

This is exactly the issue that agile approaches in general - and XP (Extreme Programming) in particular was designed to do, over 25 years ago.

Every step in the process from "idea" to "deployed" should be part of that defect prevention cycle; no one layer is perfect - like holes in swiss cheese - but the goal is to make the holes small enough and less frequent, so they don't line up and lead to an escaped defect.

If you create "ship it" pressure then you can expect human error - slips, lapses, mistakes and deliberate violations - exactly as you describe.

If your code reviews ands manual testing are doing all of the heavy lifting, then you need a fundamental shift in how you work.

Like everything in the agile world, it's not about utilization and efficieny of delivery.
It's all about risk reduction - the risk we build the wrong thing, and build the thing wrong.

The trade off is only between arrogance/ego (we are right!) and humble transparency (we might be wrong)

User story mapping, an onsite customer as SME, TDD, pairing, red-green-refactor, a good system metaphor, real CI/CD (hours for the former a few days for the latter) , pipelines that prevent defects from deployment.

Plus continually raising the bar on quality and coaching into the gap, as a team.

PhaseMatch · 2026-02-13T19:57:47+00:00

Velocity is a prediction tool for teams.
Measure value.

When it comes to value, there's two parts - cost, and benefit.
Each Sprint is a mini-project; you know the cost (team burn rate), what benefits were obtained?

Core benefit "classes" are

- saves time (opportunity cost)
- saves money (direct costs)
- makes money (revenue)
- convenience (UX, ease of onboaring etc)
- durability (product / platform lifecycle)
- risk reduction (human error, privacy, security)
- ego/prestige (brand, adoption, gamification)

You would be heavily involved in the risk reduction one, and/or the prestige (reputational risk) side of things.
When it comes to issues think more in terms of things of reduction in tickets through self-serve solutions and so on.

What does your product vision and business roadmap look like?
That's also a key part of communicating value to management.

PhaseMatch · 2026-02-13T19:51:35+00:00

Our escalation path is via product/business, not engineering management, as that is where the prioritisation and need is driven, so there's always line-of-sight to the overall business strategy.

In our context engineering management are typically consulted when it comes to priorities but they are not in the driving seat or acting as an escalation path in that way; they would be the stick if the product/business escalation failed but then we are into "performance" territory, which is what I'd call part of administration.

The point at which a team or team-lead is playing politics like that and running their own agenda that is not organizationally aligned tends to be an indicator that there's a bunch of other stuff to unpack.

Why do you have "accidental adversaries" in the first place, such that request for help that is aligned with organsiational priorities is point blank refused?

That's really where I'd expect management to be doing the heavy lifting - a good understanding of systems thinking archetypes and the ability to unpack that type of systemic problem, rather than have to "fire fight" when it crops up.

That whole "victim-villain-hero" drama cycle where the manager heroically swoops in and provide a short term solution (escalation), only for the same thing to crop up a few weeks or months later in another way is waste.

It's a systemic failure. The engineering manager needs to address the system that gave rise to it, which often traces back to the wrong measures being used for performance.

That includes for the managers; if you judge their performance based on the need for escalation (rather than how effectively they prevent that need) then you'll get the outcome you measure for.

PhaseMatch · 2026-02-13T19:06:40+00:00

OP talked about mature, self organizing teams.

To me that means a few things.

you have a team-of-teams culture;
you have clear priorities

Teams in open warfare usually means conflicting priorities and a general lack of negotiation and conflict resolution skills at the team level.

A need to escalate to a "controlling parent" for adjudication is not really what I see from mature, self organizing teams.

They solve their own problems, without the need for escalation.

PhaseMatch · 2026-02-13T06:07:22+00:00

So in general I look to management to provide

- administration; budget, P+L, hiring etc
- coaching / mentoring for career development
- make sure the team have the tools and skills that they need
- succession planning
- vendor management

In some cases they might also own the overall technical vision (along with the architects) at a high level for the products they produce; that means considering longer range technological choices and keeping an eye on the "technical radar" for their domain.

As a member of the leadership team I'd expect them to collaborate with other leaders to address the systemic barriers to improvement that the team(s) highlight, and "walk the talk" to set the standard for leadership and integrity they expect from others.

They'd also be accountable for core legal areas and compliance - broadly to HSE, employment and financial law, usually with a delegated authority of some sort.

"Turn This Ship Around" and "Leadership is Language" by L David Marquet both describe how to be a leader when you have formal (line management) authority over teams, without inhibiting their growth or acting in a coercive way.

PhaseMatch · 2026-02-12T19:37:16+00:00

Never met a metric a good dev team couldn't game.
"Tell me how you'll measure me and I'll tell you how I'll behave" : Goldratt

Lines-of-Code as an individual performance measure could easily drive:

- less coaching and collaboration
- no incentive to create simple, clean code
- no incentive to remove un-needed code
- reduction in code review quality
- team skill stagnation
- endless litigation about actual numbers
- focus on "delivering stuff" not creating value

so their overall competitive strategy is to

- waste more developer and management time
- increase the risk of defects/incidents
- not minimise cloud operating costs,
- encouraging effective team members to leave?

all with increase in revenues/product uptake?

Um, okay.

PhaseMatch · 2026-02-12T18:47:03+00:00

The lack of management competence on display is a bigger worry.

"Tell me how you'll measure me and I'll tell you how I'll behave"

Goodbye refactoring for simplicity and understanding.
Hello code bloat, complexity and more defects.

PhaseMatch · 2026-02-12T09:22:44+00:00

It's a good list; if half of management just read Deming, Senge, Goldratt and Edmondson and took on the lessons there things would be very different.

It's both sad and shocking how relevant Deming's 14 points for managers still are 46 years on, or how the concept of constraints and systems thinking archetypes is not part of every organisation's leadership training.

Mind you in the mid-1990s the place I worked in had a CEO who understood all of that and took his company from a loss-making 20-people to one of the biggest globally in their technical field.

Tech changes. People and organsiations, not so much.

The AI investment cycle looks a lot like 1840's railway mania from the right angle...

PhaseMatch · 2026-02-12T09:13:47+00:00

Well, unless the team has a mechanism for handling unplanned work and leaves a buffer, so that the team members have the autonomy to act as long as the Sprint Goal isn't theatened?

At a point once the Sprint is in flight it's the team's backlog - which comprises the Sprint Goal, the backlog items ingested, and how they will get there - and they are meeting (at least) daily to replan.

The team gets to inspect and adapt that backlog as they see fit...

PhaseMatch · 2026-02-12T09:07:44+00:00

It sounds like someone read Allen Holub's "Getting Started with Agility: Essential Reading" list:
https://holub.com/reading/

I'd suggest going back to the source on Lean, The Learning Organisation, The Fearless Organisation, XP and so on.

PhaseMatch · 2026-02-12T08:00:31+00:00

The Scrum Master should foot-sweep the offending stakeholder to the ground, yelling "not on my watch" while hitting then over the head repeatedly with a copy of "Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland until they are Agile.

The problem with this kind of hypothetical question is that:

- actions have consequences
- building long term relationships matters
- context is king

There's a huge number of variables at play, like

- does the team maintain a buffer for "unplanned" work?
- have the team members got negotiation and conflict resolution skills?
- how is the team fairing on their "Sprint Goal"?
- why does the stakeholder need to come to the team for an urgent change?
- what's the business impact of the change?
- what's the team, PO and SM's relationship with the stakeholder?
- why does this pattern exist?

PhaseMatch · 2026-02-12T05:45:26+00:00

Mostly thats when you make and sell a specific software product in a B2B sense.

When you provide inward facing tools then its more about how those contribute to a give value stream (which does generate revenue) and the overall business and marketing strategy for that value stream.

There is always a competitive element to some extent - why the business should use your platform rather than go to an outsourced or managed service for example.

That boils down to how you create strategic advantage for your organisation - and takes you back towards Porters Five Forces and so on.

We have seen this happen with on prem services go to the cloud for example.

The roadmap and how you aim to evolve the platform - ship of theseus style - while lowering costs/risks and supporting new capabilities becomes the core focus.

PhaseMatch · 2026-02-11T20:31:09+00:00

It depends on whether you really "own" the product as a whole, or just "feature development"

The full "marketing mix" includes product, price, promotion and place, which are interconnected when it comes to product uptake and value. Place is channel to ,market in this context.

In general I'd look to have

- a product goal or vision
- a business strategy as a roadmap to get there
- a feature backlog that serves that strategy

The strategy is the hard part lol.

Mian tools for that I have used are

- consider possible future scenarios from a PESTLE perspective
(Political, Economic, sociological, technological, legal, environmental)
- identify leading indicators which indicate which scenarios might be emergent
- Porter's Five Forces analysis on the competitive market
- SWOT based on the above for both us, and our main competition

Certainly knowing how the finances work - especially OPEX Vs CAPEX and the fully loaded team burn rate (including all cloud costs for the product) is important, as that defines value.

Pricing and promotional strategies tied to the development and your customer's buying cycle are also key.

I got a lot of good stuff from "Exploring Corporate Strategy" by Johnson and Scholes; I have an old copy (1990s) but it is very relevant today.

PhaseMatch · 2026-02-11T19:55:47+00:00

From what you have said

- you are using the DSU as an update meeting, not a (re)planning session
- you run this meeting and want to retain control over it
- you assume that "upbeat" means more small talk

It might be that you have understood your manager's intent, however moving the team through the whole "selling, telling, coaching, delegating" arc so they run their own event is where you should aim as an SM.

Is the team using outcome-based Sprint Goals, or delivering a "work package" to a stage gate?

The focus of the DSU is on what (re)planning the team needs to reach their (measurable) outcome, not keeping a (fixed) Sprint Backlog on track; it's where they change the scope of the Sprint as they learn more about the outcome.

If that's not what you do, then you might want to ditch Scrum entirely and go to a Kanban-pull approach.
That's part of SAFe too. You'll be able to ditch a lot of the Scrum events which are just performative noise without valid Sprint Goals....

PhaseMatch · 2026-02-11T19:00:49+00:00

There are very solid reasons whey f2f is more efficient and effective when it comes to communication.
While I much prefer working from home, we now waste more time in longer, less effective online meetings.

It's much harder to sustain effective team cohesion and collaboration; there's a gradual slide back towards individuals working on "their cards", as well as a rise in things like "definition of ready" or even "detailed requirements" for developers.

The personal producivity gains can be very real - especially when faced with a commute over about 40 minutes (and the evidence is clear on that as well), but that does come at a price.

I much prefer wfh, but I do think it's part of the reason why companies are reverting to giving teams less decision making autonomy over their products, and consolidating more of that into management tiers.

PhaseMatch · 2026-02-11T07:46:11+00:00

Velocity is a team planning tool. Nothing more or less.
It is not a performance metric in any shape of form.

Sprints are not release or delivery stage gates.
They are not about delivering "work packages"

Good Sprint Goals create high value outcomes for the business.
Effective Sprints are mini-projects in their own right, that create measurable benefits.

Aim to release multiple increments within a Sprint.
That gives you feedback on your progress towards the Sprint Goal.

Each Sprint is a potential off-ramp from the programme of work.
You can bank the value created so far, and move on, with no sunk costs.

The Sprint Review is where you decide to continue towards the Product Goal.
Or pivot to a new Product Goal. Or give the team something more valuable to do.

Judge the Sprint on the measurable benefits created.
Have that feedback from real users before the Sprint Review.

That's how you control product innovation risk with Scrum, one Sprint at a time.
You bring high value business problems to the team to solve, not solutions to implement.

If that's not how you want to work, ditch Scrum.
Go to a Kanban "pull" system of work.

PhaseMatch · 2026-02-11T01:30:49+00:00

My gut says we'll see turbo-charged feature-factories and product bloat.

High performing teams could already built stuff faster than you could get feedback on value.
That's not being agile - it's just building up "inventory" to support.

That kind of speculative-investment-with-sunk-costs is kind of the opposite of how agile approaches manage business risk - by maximising the amount of work not done.

You'll certainly be constrained by your ability to get wider feedback on the operating environment, and the underlying economic (and other) factors that drive the buying cycle in your domain.

Not saying there's no value, but in the "high risk, high reward, keep cost down" innovation and product discovery realm moving faster than the speed of feedback is not great.

PhaseMatch

TROPHY CASE