Are We Heading Towards the Scrum Team of One? And Is Your Organisation Ready?

The Scrum Team of One - Image created with DALL-E

I’ve spent the last 30 years helping organisations build digital products and software. Large programmes. Distributed Agile teams. Value streams. Digital transformations. Investment banks. Global consumer brands. Along the way, I also became a team coach because I realised that organising delivery was only half the challenge. Helping teams perform was the other.

More recently, I’ve worked extensively with Flow and Team Topologies concepts, helping organisations rethink how technology aligns with business value. From reshaping technology organisations in banking to redesigning digital value streams at a large restaurant franchise, the objective was always the same:

• Reduce the distance between business intent and working software.

• Bring technology closer to where value is created.

For the last decade, that has been the dominant direction of travel.

And I believe it still is.

Yet AI may be about to trigger the biggest shift in software delivery since Agile itself: The Scrum Team of One.

The Bigger Shift Behind Vibe Coding

Much of the current conversation focuses on AI coding assistants, copilots and vibe coding. Some of the excitement is justified. Some is plain hype.

But I suspect most people are focusing on the wrong thing.

The real AI shift is not better coding tools. It is the emergence of what I would call SDaSS: Software Development as Self-Service.

The ability for non-engineers to increasingly create and evolve software directly, consuming engineering capability in much the same way organisations consume infrastructure, platforms or cloud services today.

At first glance, this sounds far-fetched.

Yet the weak signals are already visible:

• Data has already started moving in this direction. Modern data platforms, data lakes and semantic layers increasingly allow users to create their own reports and insights without relying on specialist teams.

• Software is beginning to follow a similar path with tools such as Cursor and the rise of Vibe coding.

• Even in requirements and analysis work, I have seen teams use AI to consume research, generate requirements, and dramatically shorten the journey towards working software.

The technology is still immature. But the direction is becoming harder to ignore.

Sooner or later, a well-crafted user story may become all that is required to generate working software.

The Scrum Team of One

This raises an uncomfortable possibility.

What happens when software development itself becomes increasingly self-service?

For years, the typical Scrum team has consisted of Product Owners, Scrum Masters, Tech Lead, developers, testers, and a range of supporting specialists, including architects, UX practitioners and DevOps engineers.

The first signal has already appeared. As teams have become leaner, many organisations have reduced or removed Scrum Master roles altogether.

As AI capabilities continue to improve, it is not difficult to imagine development capacity reducing within stream-aligned teams. Five engineers instead of ten. Two instead of five.

Eventually, perhaps, a Product Owner sitting alone, generating software directly from business intent: The Scrum Team of One.

That sounds extreme. And perhaps it is. But the direction matters more than the final destination. Because even if organisations never fully arrive there, the journey itself changes everything.

More importantly, it should shape how leaders think about AI strategy today.

Engineers, No Need to Panic!

This is not a prediction that engineers will disappear. Oh, nooo.

In fact, organisations pursuing this future will need stronger engineering capabilities than they have today in order to enable SDaSS.

Someone still needs to:

• Build the platforms.

• Design the architecture.

• Define the domains.

• Secure the data.

• Automate testing.

• Manage cloud and token economics.

• Create the controls, guardrails and reusable services that make software safe to generate and deploy at scale.

Most enterprises are not particularly good at these things today.

• Many still struggle with colossal technical debt.

• Many still rely heavily on manual testing.

• Many still lack mature platform capabilities.

• Many have accumulated years of architectural and operational debt.

• Many have much duplication and no clear source of truth.

The AI-enabled future will remain a pipe dream unless organisations start getting a grip on these fundamentals.

The best engineers may become more valuable than ever.

But the capability will shift.

Team Topologies Was Pointing in This Direction All Along

One of the reasons Team Topologies and the Flow System resonated so strongly with technology leaders is that it recognised a simple truth:

Technology works best when it is aligned to the flow of value.

For years, organisations kept their business and technology departments separate and then built an army of project managers, programme managers, governance forums and steering committees to stitch them back together.

The result was predictable:

• Handoffs.

• Delays.

• Misunderstandings.

• Slow feedback loops.

The answer was to bring engineering closer to the business through stream-aligned teams and eliminate the layers in between. That was the right move. And it still is.

Some readers may conclude that if engineering capability eventually shifts towards platforms and enabling teams, then bringing engineers closer to the business was a mistake. I believe the opposite.

The journey towards SDaSS goes through value streams, not around them.

You cannot industrialise software creation until you understand how value flows through the business. Equally, you cannot create self-service software development while technology remains disconnected from business outcomes.

Team Topologies provides many of the organisational constructs needed for this transition:

• Stream-aligned teams help organisations understand value.

• Platform teams create reusable capabilities.

• Enabling teams accelerate adoption.

The principles remain highly relevant in the unfolding AI world.

What changes is where engineering capability sits over time.

Historically, engineers needed to be embedded directly within stream-aligned teams because software creation was largely a manual craft.

As SDaSS matures, some of that engineering capability will gradually shift towards platforms and enabling services. The business continues to own the value stream, but increasingly consumes software development as a capability.

The alignment remains.

The organisation layering changes.

The Reverse Conway Manoeuvre Becomes the Strategic Lever for Executives

This leaves executives with a challenge.

They cannot wait for the capability to arrive, yet the capability will only materialise gradually over time. By the time production-grade SDaSS becomes commonplace, it will be too late to begin adapting the organisation. The technology will move faster than the organisation can respond.

This is where the Reverse Conway Manoeuvre becomes critical.

Conway’s Law tells us that systems tend to reflect organisational communication structures. Team Topologies popularised the idea that the reverse is also true.

If organisational structures influence technical outcomes, leaders can deliberately evolve the organisation to enable future technical capabilities.

For CIOs, CTOs and COOs, this may be the most important lever available.

This is not about launching another large-scale reorganisation.

Quite the opposite.

The organisations most likely to succeed will evolve gradually:

• Strengthening value streams.

• Building platform capabilities.

• Reducing friction.

• Clarifying ownership.

• Increasing automation.

• Improving data quality.

• Developing new governance models.

The capability follows the organisational evolution.

From Delivery Governance to Strategy Governance

There is another consequence that receives far less attention.

Most organisations still govern technology through delivery outputs rather than outcomes:

• Projects.

• Programmes.

• Milestones.

• Status reports.

• Steering committees.

Delivery governance existed because delivery was difficult. But what happens when delivery becomes abundant and increasingly frictionless?

What happens when software development becomes self-service?

At that point, delivery is no longer the constraint.

Delivery becomes Flow.

The question is no longer: “Will we deliver it?”. It becomes: “Should we build it at all?”

Or perhaps: “Is it delivering the benefits we expected?”

Governance, therefore, moves upwards. From delivery governance to strategy governance. From project management to strategy deployment. From outputs to outcomes.

Some CFOs may quietly sing alleluia: At last, the conversation can move from whether projects have been delivered to whether they continuously create value.

The growing interest in OKRs is one of the weak signals that this transition has already started. Many organisations are attempting to govern through outcomes rather than activities.

Most are discovering how difficult that is.

I have helped several organisations begin implementing a Continuous Strategy Operating Model and, without exception, this has been the hardest change to make. There is so much to untangle and realign, not least people’s experience, habits and available time, all of which have historically been focused on delivery management rather than strategy.

Governing through strategy is significantly harder than governing through delivery.

Yet AI may bring this world faster than organisations can adapt to it.

Don’t Ask Me What Good Looks Like

Our corporate brains have been programmed to know the final picture and build a plan towards it. Draw the target operating model. Define the future state. Build the roadmap. Execute the programme.

It has never worked quite as neatly as we pretend, yet it remains a difficult habit to break.

The mistake would be to treat this article as a prediction of a future operating model.

I have no idea what the final organisational shape looks like. Neither does anyone else. Anyone claiming certainty is either guessing or selling snake oil.

• The technology is still emerging.

• The governance models are still emerging.

• The operating models are still emerging.

• The leadership practices are still emerging.

• The organisation capable of fully leveraging SDaSS has not yet been invented.

This is why asking what “good” looks like is often the wrong question. It reflects our desire for certainty in a context that isn’t, and cannot be, certain. If you wait for that certainty to appear before acting, the opportunity will have passed.

The destination will emerge as you ride that journey. The challenge is not defining the destination. The challenge is building the capability to navigate towards it.

That means:

• Continuing to strengthen value streams.

• Continuing to align technology to business value.

• Continuing to build platforms, automation and testing capabilities.

• Gradually shifting engineering capability from value streams towards business platforms as SDaSS takes shape.

• Continuing to evolve governance towards strategic outcomes.

• Continuing to develop leaders capable of operating in uncertainty.

The Scrum Team of One may never fully arrive. That isn’t really the point. The future organisation capable of fully leveraging SDaSS has not yet been invented. Nobody knows what it looks like. The destination will emerge.

The question is not where this journey ends. The question is where your organisation begins. And how you lead it through.

Because this future state is still so far removed from today’s organisational reality that using it as a blueprint is largely pointless. The organisations that navigate this shift successfully are unlikely to be those that define the perfect target state upfront.

They will be those who learn how to evolve towards it. How you embark on that journey, and how you continuously adapt as the destination emerges, will matter far more than the destination itself.

A Final Thought

If there is one question I hope this article leaves you with, it is how you get your organisation started on the journey.

If these themes resonate with the challenges you are facing, I’d be happy to explore them with you. From supporting individual executives and leadership teams to helping organisations evolve their operating models, governance and change capability, my work focuses on helping leaders, teams and organisations navigate complex transitions.

Feel free to get in touch.

Philippe Guenet - Henko (www.henko.co.uk)

Credits:

This article was inspired by a number of conversations.

• First, to my lovely wife, Christine Guénet, who, besides being an excellent technology leader, is often a much better natural coach than I am, and who prompted this very powerful question indeed.

• Thank you also to Fabrice Bernhard, Nigel Thurlow, Jatin Chandwani, Jonathan Webster, Benjamin Richards, Giles Lindsay (CITP FIAP FBCS FCMI), Hugh Ivory, Peter Coesmans, Karl Scotland and Jim Benson. Conversations with each of them, both this week and over the last few months, challenged and sharpened this thinking.

• And to Matthew Skelton and Manuel Pais, whose work on Team Topologies gave many of us a language for thinking about teams, flow and organisational design—ideas that remain highly relevant, even in an AI-enabled future.