When we started talking about scaling, we said that organizations are looking for a cure. The pain is slow delivery. That cure seems to be taking the success agility brought the team and scale it to a group, organization or the entire company.
We know that small organizations (agile or not) generally have better delivery capabilities than those of the bigger organizations (where the pain lies). When an organization grows, there are more communication pathways, more dependencies between teams, because of specialization. It’s hard to get answers quickly and things get stuck or fall and don’t get picked up.
The bigger they are
It’s not that they didn’t try before agile to solve this. But there are a couple of obstacles on the way to efficiency. Traditional hierarchy-based organizations use command and control in order to remove waste and make productivity efficient.
However, command and control methods have an implicit, yet wrong assumption: Your boss knows more than you. If you have a question, the boss will give it to you. If the boss identifies you’re working on something less important than you should, she will direct you to the more important thing. And if you need something from another group, the boss will fix it.
In high-silo organizations, when a team specializes in something (technology, domain, roles, etc.), they are constantly raising their dependency on other teams that are proficient in other topics. The only way to deliver something out, is to combine everything together, and with specialized teams, we require ambassadors and negotiators, and these are usually the bosses.
Finally, when teams specialize, their goals are about doing their job better, which may not (read: usually not) correlate with the organization’s end goal. Teams try to optimize the process for their gain, sometimes working against other teams.
Think about separate dev and test teams, where the developers are encouraged to push more code (that’s considered productive), more than the test team can swallow. That leads to return trips of bugs, animosity between the team, and the product just gets delayed.
That doesn’t work well
In the knowledge economy, the “workers” know more than the boss. They don’t “need” the boss for the traditional bossy things – after all if we can delegate something to the boss, it is because the team doesn’t know how to do it, and since the boss doesn’t know either, it’s like she’s just another member on the team. They’ll figure out the problem and solve it.
(Yes, I’m leaving out the discussion of what a boss means today, and what they actually do. Not today.)
Agile principles correlate with the ability to deliver. If the team has enough power and independence, they can solve their own problems.
And here in lies the real opportunity for scaling.
In order to deliver early and often, we need to push decision-making down to the team level. This way, we’re removing the bottleneck from the manager and let the team handle the problems managers used to solve.
Let’s assume we have a lowly product owner, who spends his time with two teams, and also “finds” time to meet with customers, conduct research and dabble with some UX. You know, a superwoman.
You’ll often find that the PO becomes the bottleneck for delivery. The product knowledge lies in him. Therefore she holds all the answers. And the teams are waiting for her to tell them what she wants so they can build it.
But our PO is too busy. She fails to “feed” the teams. The teams don’t know what to do.
Or don’t they?
If the team (usually developers and testers, but also operations, support, and whatever constitutes the team) know their business, know their software and are allowed to take chances (and sometimes fail), they can now decide what to push into the product. We’ve just “scaled” the product owner role.
Of course, that’s not that easy. The team will make bad decisions. They will think differently than the PO.
If the PO gives the team the ability to decide, she needs to accept this. If she doesn’t, the team will go back to “feed me” mode. After all, why should they waste their time doing something that’s going to be redefined by the PO?
But if the PO understands that her ideas also do not work all the time, and the team understands changing your mind, based on feedback, is part of the job – at that point you have removed the bottleneck.
Scaling is not about the process, a better process is not the cure. If we focus on agile principles and make sure they happen, we can scale the ability to deliver.
And isn’t that what we really want?
| Reference: | Agile Economics: Scale 3D from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
