Agile Economics: Scale 3D and the Knowledge Economy
Agile Economics: Scale 3D and the Knowledge Economy
Learn about the challenges of making decisions within agile teams and how agile principles increase efficiency, even for large organizations.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
When we started talking about scaling, we said that organizations are looking for a cure. The pain comes from slow delivery. The cure seems involves taking the success agility brought the team and scale it to a group, organization, even the entire company.
We know that small organizations, whether they are agile or not, generally have better delivery capabilities than those of the bigger organizations. 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 to solve this before agile. 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 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 delay of the product.
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. She’ll figure out the problem and solve it.
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 other elements that constitute 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?
Published at DZone with permission of Gil Zilberfeld , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.