Your Scrum is not enough
Scrum isn't a team organization framework that guarantees effectiveness. That's why IT keeps missing delivery objectives. Change that with Team Topologies.
This is “Effective Delivery” — a bi-weekly newsletter from The Software House about improving software delivery through smarter IT team organization.
It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.
Is this newsletter for you? Learn here.
TL;DR
Technology managers believe their IT is effective, yet the team setup is often bad,
Standardized “feature teams” may act self-sufficient, but they’re not,
If your IT needs to fix delivery metrics, Team Topologies offer a way
Some companies already leverage Team Topologies… without knowing it
Contents
Hello! Adam here again.
Scrum is a hot mess. Everybody uses it, and most do it wrong.
It has its roles and regulations, but they conveniently disappear when executives push for a hard release date.
Scrum is flawed but remains the holy grail of effective delivery for most technology leaders.
Because what else is there?
It’s not like it’s easily replaceable. Surveys say it’s great.
In my 10+ years at The Software House, I’ve only seen 2 companies out of 160+ that tried a different framework on top of Scrum.
It was called Team Topologies.
A team organization framework you’ve probably only heard of.
Let’s discuss why Scrum is so sticky and what Team Topologies bring to the table.
Scrum’s limitations
Obviously, we use Scrum.
A startup with 1 or 2 pizza teams doesn’t need anything else.
But, like I said in the introduction, we made “Effective Delivery” for managers of IT departments with 20+ engineers.
Inside such groups, Scrum turbulence starts when it’s time to roll in new technology — like AI.
Consider this story.
Your organization wants to stick an AI feature onto the product to make it cooler.
You upsklill or hire 1 AI technologist and put them into that feature team.
As that new agent vacations after the implementation, 3 critical bugs crawl out.
But the feature team can’t fix them!
They’re grounded for weeks until that AI expert returns from the beach.
So who’s guilty here?
The leadership.
Under Scrum’s rules:
the feature team wasn’t asked to master AI use but to implement it,
that AI commando wasn’t asked to educate but to support implementation,
teams are meant to be multidisciplinary, but they can rarely do all that’s required.
While Scrum teams are supposed to be “self-organized” and self-sufficient”, rarely does anyone question their efficiency until IT hits the wall hard.
I don’t think the framework is to blame.
Most IT managers don’t know that Scrum can be practiced better under new rules.
And there’s a couple of misconceptions they hold dear that prevent them from seeing better delivery metrics.
Myths that keep IT teams inefficient
Please, enjoy this list of arguments.
We had to overcome these internally on our self-healing organizational journey and in selected commercial projects, in which we could set the workflow.
Conveniently, Team Topologies has an answer to all of these.
What a coincidence 🤓
“Our Scrum teams are designed to be effective.”
Scrum sets a rhythm for consistent delivery and encourages team autonomy.
That’s great. But there’s a lot that it doesn’t define:
how to reorganize a Scrum team to nail a specific project type,
how the team’s responsibilities should change with the product’s lifecycle,
how IT teams should interact with each other,
Since old champ Scrum is now 30 years old (!), it’s just logical that our management philosophy could use a GPU upgrade.
“We have DevOps to support our delivery.”
Improper DevOps implementation is one of my favorite sins to discuss.
Usually, a DevOps engineer's role is limited to infrastructure management or CI/CD setup (sic!).
And that’s like 20% of what they should do!
In my mind, their role is to streamline the delivery process through automation, CI/CD practices, and monitoring — and to teach developers to do it themselves.
And no, DevOps as it is IRL, is not Platform Engineering. We’ll get to that.
“Our engineers support each other.”
IT managers do their best to buddy up engineers to get them upskilled.
But does that knowledge sharing have real impact?
We used to do it wrong, running lectures, workshops, and hackathons, while still having to put out fires on the regular.
Once the fire broke out, you bet there was no time to teach anything.
We also expected that engineers would self-educate after hours.
But our delivery didn’t seem to improve.
Something was missing.
Through failure, we’ve learned the teacher needs to master the domain in a live project first.
Then, their teaching can be effective — if they’re glued to a team until it becomes self-sufficient.
How Team Topologies can help
The myths you’ve just read are just a small bunch.
I could dig up more, but you probably can’t spare 6 hours for my talk.
And, as a manager, you might have some tactics against them.
I’ll just say that Team Topologies is a pretty good toolbox for raising team effectiveness, project security, software quality, and technological innovation.
That’s why you could at least discover it with us.
The framework defines 4 types of IT teams, their entire lifecycle, and the 3 modes of productive interaction they can use.
And while Team Topologies is my recommendation, some A-players you can recognize have used it with measurable success.
The takeaway here is that the effectiveness of your delivery is always the result of how teams are organized.
So, the first step is to grasp what team formations you can use, and when.
There’s a lot to unpack.
Today, it’s enough if you take in this sneak peek.
The four Team Topologies you can use
Stream-aligned team
It’s your basic scrum team that delivers a complete product or service, improves flow and responsiveness, and is used for end-to-end ownership.
Platform team
They do what DevOps wants to do, and what management thinks DevOps is doing while nobody does it 😉 This team builds internal tools to reduce workload and improve delivery, and is used when shared services are needed.
Enabling team
The team you don’t employ now. It helps other teams adopt new skills or technologies, improves capability, and is used during learning or transition phases.
Complicated Subsystem team
What a Scrum team can morph into without knowing it. It manages specialized areas toimprove quality and safety, and is used when deep technical expertise is required.
Next time
Buckle up for a breakdown of the Platform team.
If one of your employers has ever outsourced software, you've already seen its miracle at work.
And it’s the A-Team that your IT might just benefit from the most.
Thanks for reading today ✌️
Was this enlightening?
Roast or kudo this issue in the comments! I might even respond 🙂
Published with a smirk by The Software House
Twarda 18, Warsaw, Poland
tsh.io →
 | A guest post by
|