How much can your Team Deliver? Why?
The True Value and Limit of Your Team
I coach software teams. That’s no surprise by now. I have fascinating conversations with them. They’re unique and challenging in their own way.
Yet, some things don’t differ much. I’ve seen over a hundred teams. There are patterns.
And some of the really bad ones you should be aware of.
Today, we explore two of them.
They are contradictory.
And both are true.
I selected the most common phrases to describe them.
“It is near impossible to tell when something will be done or when my team will deliver. And it’s getting worse!“
and
“[We] are frequently late, running at a constant slow pace. And it’s getting worse!“
Curious, isn’t it?
To not be able to tell your speed enough to guess time of arrival - yet… it seems slow and always the same. Maybe you’re headed the wrong direction. But no, there are simply too many priorities.
Hm. Sound familiar?
How do teams end up here?
Keep reading to find out 👇
You Build it, You own it, You Maintain It
It all starts with a foolish assumption.
You build a feature. When it’s done it requires no more work so you go on building the next unrelated feature.
But lo’ and behold the old features needs extra work.
I can hear your product manager sighing already. “But wasn’t it done? When will it be done-done?”
That’s a great question! If only we knew what it and done mean, we would have a perfect answer.
Even though that’s a great questions — it’s the wrong question.
To present the next point, you’ll need to know a little bit about Wardley Mapping. Here’s the website, you can go into detail later.
Wardley Mapping highlights a context map that is very similar to Bounded Contexts and Event Storming. It has 4 distinct regions with examples:
Genesis of novel ideas - the iPhone
Custom Built features - you build your own OS and hardware
A Product - An App on said phone
Commodity - Login and Email servers
The Bottle Neck is Cognitive Load
Your team has neither the time nor the capacity to understand everything. I’m very happy with the newest research on Flow and Team Topologies. The Fast Flow conference was an eye-opener for many post-agile practises!
They are fastest when the software they are working on fits in their head. That’s speed.
They will be successful when they follow the valuable needs of the customers. That’s direction.
They will be on time when they are building only what serves user demand in a way the business can capture as revenue. That is the roadmap.
And they can stop working on it when it has been industrialised (with great effort and investment!) to the point where it becomes a commodity. That is done.
The Way out of the Foolish Rabbit Chase
“Each feature you introduce into your product has to be maintained, changed, updated and tested until you have commoditised it.”
Non-engineering stakeholders often miss this last point. There is no done per se with custom software. It’s custom! You can’t just take it into the shop and give it an oil change. You have to build the shop!
There are three popular solutions to this problem that we will go into in more detail next week:
Removing Features that are not serving user needs that are important to the business
Investing into automation and scope-freezes to commoditise the important features
Specialising teams around cognitive load and domain contexts so that specialised teams can be created to relieve the Team Cognitive Load stress for the ones delivering custom features and discovery (the so-called Stream-aligned teams)
Below is a video that highlights the last point by the Team Topologies authors. See you next week!
Every new feature is like adopting a new puppy that needs care and feeding. Eventually you have a herd to tend to.