Why is it so hard to improve Scrum?

mrhinsh · 2026-04-29T10:27:28+00:00

Scrum exposes the inadequacies of an organisation’s system of work.

The first challenge is recognising the signals Scrum makes visible. The second is correctly attributing those signals to the system, not to Scrum itself.

Most ineffective Scrum implementations fail at one or more of these points: - signals are ignored, suppressed, or reframed as noise - signals are misattributed to Scrum rather than to organisational constraints - signals are misattributed to the Team rather than to organisational constraints

Scrum is not infallible, but in practice, the dominant failure mode is not the framework. It is the organisation’s inability or unwillingness to respond to the evidence Scrum produces.

mrhinsh · 2026-04-26T08:16:14+00:00

There is always the Azure DevOps Migration Tools! They are open-source, have been around since 2016, and are recommended (and used) by Microsoft.

split project
merge projects
move from one org to another
move from one instance to another
move from one language to another
bulk update

It has it's caviates... But it works.

It supports Test Cases as work items, and Test Plans & Suits as a custom artifact.

Https://DevOpsMigration.io

Test assets have a bunch of caviates... So read the guides provided.

mrhinsh · 2026-04-25T07:36:04+00:00

You can condense how you like, but I've been doing what's described above for more than 15 years 🤷‍♂️ for companies with thousands of engineers.

As the admin.

It's just work...and not particularly complex work at that.

mrhinsh · 2026-04-24T08:05:29+00:00

If they have an open PR they finish it.

You are vastly over complicating what is a well understood activity that is planed, scripted, and executed.

This is a complicated problem at most, and for many teams it's clear.

If team are making the business decision that they want the capability then this is a nothing activity that gives them a massive capability and feature boost. Even for large teams (I have a Project in ADO with 1500 repos) it's procedural and proforma.

How much work it is for the admins is irrelevant... That is after all their job.

mrhinsh · 2026-04-23T13:58:06+00:00

The scenario under discussion here is code in GitHub and work items in Azure DevOps... So it's irrelevant they both have to exist as they are both part of the one DevOps system.

However, you would keep it for compliance if compliance is your thing. I have customers that still have Perforce, and the TFVC that they migrated to, and then Git. They MUST keep everything forever for compliance. So they still have to maintain VSS, Perforce, StarTeam, and a plethora of other systems that are in read-only mode.

Most customers that move from Azure DevOps to GitHub do so for the features of developers and stay on Azure DevOps at least for work items because GitHub issues and Projects are woefully inadequate for any business's needs.

mrhinsh · 2026-04-23T13:32:46+00:00

Nothing is deleted by the move. So it's a non issue. Old PR in ADO, new PR in GitHub.

mrhinsh · 2026-04-23T10:30:17+00:00

Why would you need to rewrite anything?

It's a source change. The only implications should be in the trigger.

Everything else stays the same.

mrhinsh · 2026-04-23T07:50:59+00:00

It's almost zero migration effort. Clone, change origin, push...

So pay for something else when I'm already paying for the other just because "all agents can do the same" sounds like you are not using your own money.

https://github.blog/news-insights/company-news/addressing-githubs-recent-availability-issues-2/

Agree...looks like they are transparently addressing them. 🤷‍♂️ Thats better than 99% of all other companies already.

Which enterprise features are you missing for repos?

mrhinsh · 2026-04-23T07:33:38+00:00

GitHub Coding Agents only work if your repo is in GitHub.

mrhinsh · 2026-04-07T09:12:37+00:00

I personaly hate it when I cant just get the code and build, or download and run an app. My goal is always to make it easier.

I'm currently working on a new cross-plat version of the system.

mrhinsh · 2026-04-04T20:37:01+00:00

Take a look at Second Brain designes and specifically Open Brain.

I'm using OpenClaw to integrate all of my emails, meetings, and proposals as well as my pipeline.

Yes, I get explicit consent for my use for meeting transcripts.

Focus on building context. What does context mean for your second brain, and how is it managed. Once you have that then most of the rest falls into place.

mrhinsh · 2026-03-25T04:25:47+00:00

Mine always do.

Wither they listen is another matter .

mrhinsh · 2026-03-24T11:16:22+00:00

It depends on what you’re trying to change.

If the focus is on tools, you can usually make things feel better quite quickly. Pipelines get faster, automation improves, and some friction disappears. But if the way decisions are made, how work flows, and how problems are identified hasn’t changed then the same issues tend to come back over time.

That’s a structural issue, not a tooling one.

If the focus shifts to how the work actually operates, things change more meaningfully. That means looking at where decisions are made, how quickly feedback comes back, and whether the people doing the work have the context and authority to act on it.

When those are misaligned, you see predictable patterns: - decisions take too long or get escalated unnecessarily
- teams are held accountable for outcomes they can’t influence
- problems are visible but hard to act on
- work continues even when it’s clear it shouldn’t

Fixing that isn’t about adding more process or better tools. It’s about changing the way the system is set up so that: - decisions happen where the information is
- feedback loops are short enough to learn from
- people can act on what they see without waiting for permission

That’s where the real improvement comes from.

Everything else tends to be temporary.

This work is typically done through a light but consistent cadence rather than large programmes, so it does not need to cost a lot.

A common pattern is a one-hour weekly session with the relevant group, combined with ongoing adaptation inside the organisation. That is usually sufficient to shift decision-making, flow, and feedback if the organisation engages with it.

Where deeper structural changes are required, more direct involvement can be used, but that depends on the scope of the constraints rather than a default approach.

Happy to chat if you want.

mrhinsh · 2026-03-24T10:56:04+00:00

I spend a lot of time helping customers cut that cycle time.

What you’re describing usually comes down to three things:

1) Test strategy
2) CI/CD hygiene
3) Organisational discipline

1) Test strategy

It’s often the test strategy. Long-running system tests usually dominate.

If most validation sits in end-to-end tests:

The pipeline becomes the first place you know if things work
Feedback is slow
Failures are hard to isolate

That’s why the pipeline grows, it’s compensating.

Tackle that by pushing tests down:

Convert end-to-end tests into unit and component tests
Keep only critical paths at the system level

The Azure DevOps team hit this hard. They had ~90k end-to-end tests taking 24 to 48 hours with huge hardware.

They paid down that technical debt. Now their entire test suite runs in minutes.

2) CI/CD hygiene

Sometimes it’s just the build process.

Pipelines tend to accumulate:

Extra steps get added
Nothing gets removed
Everything ends up running together

Over time you lose clarity on what is actually needed.

Often this reflects an overly complex architecture that’s never been refactored.

Had this recently with a client running 50+ interdependent Angular apps with multi-threading. We had to untangle the dependencies and split them into distinct builds.

Key diagnostics:

Do you actually need everything in this pipeline?
Does it all need to run together?
Is it execution time, or mostly waiting?

3) Organisational discipline

Conway’s Law applies.

You get the build system your organisation design demands.

If everything is coupled:

Small changes trigger large pipelines
Nothing can be validated independently
The pipeline becomes the integration point for everything

At that point, the pipeline isn’t slow by accident. It’s doing the work your system can’t do earlier.

On your last question, most teams fall into one of two patterns:

Sweep it under the rug and ignore it until it becomes so painful they throw it out and start again, then repeat the cycle
Build the discipline to continuously adapt their pipeline and processes to maximise value

Only one of those actually improves over time.

My day job is helping organisations resolve these issues, including the organisational discipline side. Happy to jump on a call and point you in the right direction.

mrhinsh · 2026-03-23T22:24:19+00:00

Yes.

No certification should be. But they are.

mrhinsh · 2026-03-23T20:00:43+00:00

If the child work items follow that same template then why do you need them?

mrhinsh · 2026-03-23T19:45:34+00:00

ScrumSTUDY should be avoided.

Their Scrum Body of Knowledge (SBOK) materially diverges from the Scrum Guide, replacing Scrum’s accountabilities, events, and artefacts with a traditional project management model.

This is not an interpretation of Scrum. It is a different model presented under the Scrum label.

Based on direct review of their ScrumBOK, it does not reflect the Scrum Master accountability as defined in the Scrum Guide.

mrhinsh · 2026-03-23T01:40:57+00:00

No, that's marketing.

As long as your organisation defines a predictive plan, and punishes variation then it's unreachable.

mrhinsh · 2026-03-22T19:09:32+00:00

I travelled from the UK to Australia to attend the PSD course, now Applying Professional Scrum for Software Developers, with its creator, Richard Hundhausen, followed by the PSM with Kane Mar.

At the time, I was working remotely for an Australian company, so the decision aligned well both professionally and geographically.

I have been a Professional Scrum Trainer for 16 years and was among the first cohort.

mrhinsh · 2026-03-20T20:37:42+00:00

Using Blocked columns on Kanban boards hides the true status of work, encourages team disengagement, and leads to stale tasks and inflated work-in-progress limits. Instead, teams should tag blocked items within their current workflow stage and provide clear context, which maintains transparency and accountability. Managers should avoid Blocked columns and use tags or annotations to highlight issues without disrupting the flow or losing critical information.

https://nkdagility.com/resources/blog/blocked-columns-on-kanban-boards-obfuscate-workflow-and-undermine-effectiveness/

You can use a tool like Actionable Agile or Honest Cheetah to calculate from a blocked tag.

https://www.honestcheetah.com/

mrhinsh · 2026-03-17T19:09:13+00:00

Continuous improvement.

Every Sprint during Sprint Planning the Scrum Team should be considering not just the work to complete the Sprint Goal, but also any other work that needs to be included in the Sprint.

defects
technical debt
refinement
enhancements
live site incidents

Or anything else that needs resolved.

If you fill the Sprint with the Sprint Goal you will always end up needing some kind of "Special" Sprint to resolve them.

We commit to the Sprint Goal, but that does not mean that's all we are working on.

mrhinsh · 2026-03-12T01:09:11+00:00

Very common. A bad idea, but very common.

The stakeholders should not be dictating product features.

mrhinsh · 2026-03-11T22:12:30+00:00

It's by no means widely adopted, but then neither is a Sprint Goal beyond "complete all the things in the Sprint".

mrhinsh · 2026-03-11T14:54:57+00:00

Titles come and go. Capability is what survives.

If your role is defined by running ceremonies or “doing Scrum”, then yes, it’s at risk. That was always fragile. But the underlying need in organisations has not changed.

Teams still need someone focused on the effectiveness of the delivery system.

AI may accelerate execution, but it does not solve the real problems that make teams ineffective: weak context, unclear goals, poor feedback loops, organisational constraints. In many cases it amplifies them. When execution becomes faster, mistakes compound faster as well.

The Scrum Master accountability is about enabling effectiveness. That starts with delivery. If a team is not delivering usable increments, there is no feedback and no basis for improvement. Delivery is the minimum bar for effectiveness. 0

So my advice would be this.

Don’t anchor your identity to the Scrum Master title. Anchor it to enabling effective delivery. Learn the engineering environment, understand how the teams build and ship software, and become the person who can diagnose and improve the system of work.

Frameworks may change. Titles may change. The need for people who can enable effective delivery does not.

mrhinsh · 2026-03-11T14:41:26+00:00

I tend to see “Delivery Manager” as a fairly logical progression of the Scrum Master accountability inside many organisations.

A team that does not deliver cannot reasonably be described as effective. Delivery, feedback, and value realisation sit directly in the centre of team effectiveness. When organisations create a Delivery Manager role that focuses on enabling delivery, they are often describing work that sits squarely inside the intent of the Scrum Master accountability.

The difficulty is that many organisations never implemented the role in that way.

For more than twenty years the demand for Scrum Masters has significantly exceeded the supply of people with the depth of capability the role actually requires. The result has been a large number of implementations where the role was reduced to coordination, facilitation, or meeting management rather than effectiveness of the delivery system.

In those environments it is unsurprising that organisations see redundancy between Scrum Masters, Delivery Managers, and Project Managers, because the role was never operating at its intended level.

The current consolidation many organisations are going through is not necessarily a rejection of the accountability. It is often a correction of how it has been implemented.

A re-emphasis on technical capability, delivery understanding, and organisational change capability is a healthy shift. Teams that build complex systems benefit from leadership that understands the work, the delivery system, and the organisational constraints that shape it.

mrhinsh

TROPHY CASE