Scaling Scrum: 4 Tips to Help with Organizational Change
11 September 2013
When a company decides to embark upon the Scrum journey, it may start with renaming a few project managers as ScrumMasters. It may even send them to become certified and then have them come back and teach others. Things muddle along for a while, then at some point the organization begins to stall, and no one understands why.
At this stage, the more enlightened (or desperate) companies seek out a coach to help them with the transition, and this is the point at which I am most likely to encounter a company that is having issues with its transformation.
"I don't understand . . . we're doing everything right, it's just not sticking. . . ." This is the refrain I am most likely to hear, so I start asking questions. Most often, the "stalling out" is a direct result of how Scrum very quickly begins to move beyond the confines of the engineering team into the broader organization in a way that is unexpected.
Usually when a company decides to become more Agile, they see it as yet another SDLC method that they can use in their software department to get all the benefits they read about in the case study. What they don't understand, and what I tell them, is that "Scrum does not make you faster, it helps you understand why you are slow. What you do when you gain that understanding is up to you." In other words, once you see the organizational impediments in your way, what do you do about them?
In the case of a small-group adoption, both problems and solution are very localized in that they can usually be solved at the same level of the organization that noticed them -- provided the organization is flat, as most small orgs are. However, when we look at larger organizations, the problems and weaknesses that prevent complete transformation are usually symptoms of the layers and structures of the organization itself. Scrum makes these organizational problems and weaknesses more visible, and making these problems more visible can make people feel most uncomfortable.
Here are some tips for scaling Scrum on the organizational side:
1. Orient the efforts around products. Some of the most successful and highest-performing companies have a product (and thus a company) focus. Instead of having the Engineering Team, the QA team, and the Architecture team, turn it into "Product #1 Team," "Product #2 Team," etc. Take everything you need to take a product from idea to market and build your teams around that singular focus. This will naturally mean that non-software functions (such as marketing, legal, accounting) will all be on the same "team" as the team that is developing the product, and it's safe to say that, depending on their workload, they will be shared across multiple teams. This makes the notion of "cross-functional teams" mesh better with the organization.
2. Ensure that company leadership reinforces the Agile vision. When leadership holds a strong vision around where they want to go, it helps inspire the actions of the whole organization. Sometimes leadership attempts to quietly puppet-master senior and mid-level management from behind the scenes and avoid public discussion or evangelism of where they want to take things. What this does is create an opportunity to snipe and debate every single potential point of change. The vision needs to be clear and able to be articulated in five minutes or less.
3. Communicate. Communicate. Communicate. This works hand in hand with the vision. In large organizations, there is no such thing as undercommunication. The communication needs to come from executive leadership, senior management, middle management, and all levels in between. It needs to be painfully obvious what the vision of Agility is and why it's important to attain. Communicate with both words and actions, and make sure your actions uphold the vision.
4. Create opportunities for short-term wins. Large-scale Agile transformation is a long, slow, painstaking, sometimes arduous process that requires a steady hand and unwavering focus. But that doesn't mean you shouldn't seek out ways to create short-term wins. Getting a "win" helps maintain everyone's focus, refreshes the energy around the effort, and gives you a talking point when you're measuring the progress of the transformation.
Scaling Agile very quickly gets you outside the bounds of software and engineering and moves into issues of organizational change. You can use some of these tips to understand what is happening and give executives tools and tasks to become part of the success story.
Current rating: 4 (1 ratings)