The dos and don’ts of stream-aligned teams (2/4)
Stream-aligned teams should deliver end-to-end. But too often, they’re missing autonomy, critical skills, and solid cross-team agreements. What’s the fix?
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%.
TL;DR
Micro-practices can increase your stream-aligned team’s autonomy,
Competency audits are the no. 1 practice that can predict future blockers,
The team must be able to deploy without support,
If backlog quality is low, delivery will always suffer,
Contents
Hello, you wonderful subscriber of ours.
Andrzej here.
I’m the Head of Development at The Software House.
It’s me who they send to deal with 15 of our Engineering Managers and our developers 🙂
Similar to him, I’ve survived years in IT.
15, to be exact.
And I’m here to tell you one of my favorite tales.
It’s called: “What Is Your Feature Team Still Missing?” (working title).
Like Adam:
I took part in most of the 160+ commercial projects we’ve delivered,
worked in the trenches with internal and external stream-aligned teams,
observed IT management styles across at least 8 industries.
From that experience, I invite you to read this rundown of the top sins and saves that impact your stream-aligned team’s delivery ability.
What defines a stream-aligned team
Stream-aligned teams should be formed with people who can solve a specific business problem unassisted by any other team.
The team needs to have a mix of skills to be truly autonomous:
Product know-how,
Technology skills,
Operational experience.
Do you feel this definition applies to your feature teams?
If so, consider that a lottery win!
My personal experience?
It’s a 50/50 chance that a feature team at any organization doesn’t have some dependency that postpones a release.
“(...) a majority 58 percent report multiple handoffs between teams are required for deployment of products and services.”
State of DevOps, 2021, Puppet
So, let’s tour the greatest delivery blockers I’ve witnessed:
No real autonomy
Missing competencies
Mishandled backlog
You’ll also discover our practices for breaking them down.
Blockers and fixes
No real autonomy
Stream-aligned teams need a scientifically defined scope, immediate access to data and infrastructure, application monitoring know-how, and decision power.
Remove just 1 piece of the puzzle, and you’ll hear excuses from the PO again.
What causes it
The team doesn’t have enough competencies to act alone,
Decisions keep needing to be confirmed with a PO,
Delayed access to environments and data outside of IT
Potential solutions
1. Audit for competency or skill gaps
You don’t want to hear that a second team has not whitelisted a feature weeks after the request was pushed.
An engineering manager (EM) or team lead can predict dozens of blockers.
On the inside, our EMs do that through competency audits:
They review:
The team’s skill matrix and competency framework,
The team’s composition,
Metrics such as cycle time, lead time, and backlog health,
Any documentation or DMs about recurring blockers,
Self-completed happiness surveys from teams,
Our long-lasting feature teams worked 2 years on a payment system.
The scope kept shifting: new providers, integrations, and edge-dases.
Someone had to manage the chaos.
Competency audits saved us from a dozen of blockers.
2. Reset the team’s formation and responsibilities
Why do we keep hearing ‘I’m waiting’ and ‘It’s an edge case’ from feature teams?
You’re missing some specialists or they’re not self-sufficient.
I suggest this approach:
The team must choose its technologies rather than accept such,
It has to manage production, deployment, and maintenance alone,
Leads must flag any gatekeeping around data access to avoid delays,
The team needs an actual work contract with the platform team,
Limit members to 5-9 people only, or comms will be a mess.
These 5 rules could take weeks to introduce, but they’re worth the sweat.
Any veteran IT leader can confirm this from experience.
Missing competencies
Stream-aligned teams often lack business competencies.
Not being clear on the company’s goal or most valuable feature to build gets it defocused.
Then, the team fails to prioritize the right tasks.
What causes it
A weak grasp of the organization’s business strategy,
Business and technical teams just pretend they’re collaborating,
Lack of training on product management and value prioritization.
Potential solutions
1. Pair an external guru or a stakeholder with the team
Workshops with product or business aren’t the winning answer.
People learn the most from mentors while they’re stuck in a project.
Choose a board member or an influencer you trust as the team’s new guide,
Connect the team to that person for at least 1 month,
The team will learn through Q&A interactions.
The availability of such a consultant should pay off.
You’ll see that in the lower number of support tickets.
2. Insist on introducing DevOps competencies
I can’t stand hearing that DevOps should deploy something.
Your stream-aligned team must have a minimum of DevOps competencies, including:
CI/CD basics
Understanding of the rollout process
Monitoring and alerting
If they still don’t, introduce it as a top-down requirement,
Developers will soon admit what skill they’re missing.
The audit I’ve mentioned earlier can also reveal gaps in DevOps skills and practices.
This happens more often than you'd think.
Low-quality backlogs
A PO and a business stakeholder prepare your team’s backlog.
What would you expect?
If only I’d get a dollar for each time a developer interprets what the scope means…
We had a fixed price project.
The scope said: “Digital media displayed in the panel”.
So, our stream-aligned team thought they’d just build a gallery.
The client wanted video streaming…
We integrated a third-party tool for that pretty quickly.
It had a fat monthly price tag… which wasn’t predicted in the scope.
What causes it
Non-technical stakeholders don’t provide decent task descriptions,
No one asks or invites the team lead to review the backlog,
A backlog is created before the team is formed.
1. The team lead must always review the backlog
The issue is so persistent that all team members should be alarmed if none of them gets to analyze what’s in the backlog.
EMs should insist on the lead’s involvement in the review,
Task description should follow a mandatory format (we have one),
The backlog needs a review after the team assembles.
It’s added work, but imagine how many screw-ups can be avoided with that rule.
2. Ask the team’s members to run scoping sessions
In our case, we run scoping sessions for a client.
This guarantees no team members, tools, or competencies will be missing, and that the timeline is set in stone.
Scoping sessions align everyone on project goals and priorities,
They identify risks and missing requirements early to avoid surprises,
Sessions improve communication and build trust among stakeholders,
A clear scope helps save time and reduce development costs.
When the stream-aligned team leads descoping, tasks can magically become as clear as day.
Next time
I hope this issue lit up some practices your feature team might miss.
If there are more hardcore blockers you know of, drop a bomb in the comments!
In 2 weeks, we’ll examine a team designed to combat backlog chaos, skill gaps, and unclear priorities.
The enabling team.
You’ll learn how they inspire autonomy when it’s lacking.
I appreciate your time today 👋🏼
Published with a smirk by The Software House
Twarda 18, Warsaw, Poland
tsh.io →
 | A guest post by
|