One of the hallmarks of Scrum is the creation of a sort of “bubble” outside your normal corporate hierarchy. This can cause difficulties, of course, when companies first try to implement Scrum. Some of these companies end up modifying Scrum to fit more easily within their existing reporting structures. This is a mistake.
In these situations, you’ll often find ScrumMasters or Product Owners who act more like old-school Project Managers. You’ll find Technical Leads who dictate and software engineers who put their heads down and just follow directions.
Organizations like these are doomed to failure. Because the real power of Scrum is not in its processes and routines, but in the way it empowers and leverages the skills of team members. In my opinion, that’s the real reason why Scrum works so well.
And that’s the reason why it’s so important to take your corporate hierarchy out of the Scrum team and let that team dynamic thrive.
Does it mean that leaders with important titles in your company can’t serve on a Scrum team? Definitely not. But they’ll need to be able to separate their departmental or personnel management role from their role as a Scrum team member. This could prove difficult because playing the role of an “equal team member” is probably not what many managers are used to.
On a Scrum Team, however, managers are no longer “managers” – they’re team members. They can still serve as leaders, as I pointed out in this article, but instead of managing and giving directions to subordinates, they’re coaching, training, and mentoring. Instead of providing their own answers and solutions, they’re coaxing the best solutions from the team.
Why?
Why is this divergence from the normal corporate hierarchy so important in Scrum? In the remainder of this article, I’ll share several reasons why this divergence is not just important, but an absolute pillar of your success in Scrum.
The “Front Line” Analogy
Traditional project management takes a “top-down” approach, where both what to do and how to do it are defined at the higher levels of an organization. More details are added as directions trickle down through the organization. But by the time actual software engineers get their hands on it, all the real decisions have been made. At this point, they’re just following orders.
But who’s more capable of determining the best way to solve a software problem? An IT or business manager focused on the “big picture” solution? Or the software engineers who will be performing the actual work?
And who do you think could provide better estimates as to how long that work will take?
Scrum lets your IT and business managers do their thing in determining what needs to be done. But it looks to those front-line workers – such as software engineers – to determine how they’ll do it… and how long it will take.
More Brains on Each Problem
When “the boss” decides how something should be done, there is exactly one brain working on the problem. And that one brain is not even on the “front lines” as I noted above.
Some of the best bosses overcome this by soliciting input from their top subordinates. This increases their likelihood of finding an optimal solution.
But in Scrum, the entire team of 7±2 members is entrusted with each decision. This puts more brains on every problem. It also involves input from more diverse skill sets, making it more likely to discover those innovative or “out of the box” solutions.
Losing Control
When companies try to bring their corporate hierarchy into their Scrum teams, it’s usually because they’re afraid of losing control.
But it’s important to note that while they’re delegating a certain amount of control into the hands of their front-line employees, at the same time they’re gaining control in what matters most to them – the direction of their business.
That’s because a Scrum team’s output is guided through the product backlog and the prioritization of those tasks. And the business maintains complete control over the product backlog through their Scrum team representative, the Product Owner. This, plus the unique short-term focus and flexibility of Scrum’s production sprints, gives the business all the control it needs over the results of the project.
More Accountability, Not Less
Many executives I talk to regarding Scrum are concerned that empowering Scrum teams to such a high degree will erode their accountability. They’re concerned with teams padding estimates or under-promising results in order to make their jobs easier – or make themselves look good.
I say they’re selling their people short if they truly believe that.
In my experience, this is not human nature – especially when dealing with the highly trained, educated, and professional folks you’ll find assigned to a Scrum team.
A Scrum team is more invested in achieving great results because they made the decisions. They’ll be more creative, productive, and efficient when they’re allowed to take that kind of ownership of their work.
A well-known psychology maxim states that you take better care of something you own than something you borrowed. Scrum leverages that by giving ownership of their results to the Scrum team. It should come as no surprise when they end up holding themselves more accountable than their managers ever would.
Teamwork is the Key
What Scrum does so well is it allows real teamwork and real collaboration. Not the kind where one person leads and makes decisions and everyone else tosses in an idea now and then. I mean the kind of team where everyone is viewed as equal, where every contribution is valued, and every person has a voice in making decisions.
Scrum teams work because they’re empowered. Take that empowerment away by placing a management structure inside it, and you’ve tossed aside the single most important part of Scrum.
If you’d like to learn more about how Scrum teams work, contact us today to find out more about Ascendle’s Agile coaching, training, and turnkey software development teams for your next project.
