If you've got a technical staff of fifteen people, a Scrum conversion isn't that hard. You get everyone in one room, lock the door, give them a problem and say "solve it."
Ok, ok, it's a little more work than that. Still, in that environment, switching to Scrum is mostly a matter of mindset and culture.
With fifty people, though, it's not so easy. Five hundred or more?
Forget about it.
Large organizations have policies, organizational structures, politics, and just plain inertia that will hold them back from an overnight overhaul. In other words: "big bang" Scrum projects are expensive, cause the team to slow to a crawl for weeks or months before improving performance, and are likely to fail.
Let's look at an alternative to "Everybody comes in on Monday and does Scrum."
A typical Scrum scenario
As an example, let's look at a large software development organization. Specifically let's look at a software company that has grown through acquisition, off-shored some of its development and test operations and also needs to integrate with some third-party applications. Changes in the software will now require "ripples" to other teams and the communication costs for a single change skyrocket.
Yet on every large team I have ever worked with there was a small team trying to get out. This small team did the core of the work -- the analysts, developers, and testers who were going to work on the core components. In many cases, everyone else's job was to translate the core work, push it to include their sub-products, or integrate with the new core engine. Ken Schwaber, co-founder of modern Scrum, claims that, over time, the core work tends to be considered 'legacy,' or at least less interesting. This means that the staff capable of doing the work tends to leave or move on to other roles within the organization. Over time, the core engine becomes the bottleneck.
Suddenly performance falters and a large-scale Scrum conversion looks appealing.
Start with a tiger team
Before we jump to a big conversion, let's consider a series of small refinement, starting with the core development team.
It's likely this 'team' is actually a half-dozen to a dozen people, scattered throughout the organization. Instead of re-organizing six departments, we temporarily borrow the people we need and create one tiger team. To fund the tiger team, all we need is a single war room, a little consulting time, and a little management attention. Perhaps we send the team to Scrum training; if we do, this costs us twenty person-days instead of two hundred. We allow the team to self-organize and self-direct while insulating the team from politics and providing it some sort of interface to work with other, more traditional organizations. Another way to do this is to respond to an emergency, crisis, or big piece of software that is needed in a hurry, taking volunteers.
In either case, we have now created a single multi-disciplinary product team. At the same time, we have found the bottleneck holding up development and massively decreased its communications delays. So this new big project, be it an upgrade, a migration, or some change to comply with some law, is going get done faster than usual.
By the end of the project we now have a high-functioning, multi-skilled team. Instead of breaking the team up, we formalize it, creating a sort of special-missions team that operates differently than the old functional teams.
If you can get this far, pat yourselves on the back. You've won. You can now sit back, resting on your laurels, certain that you have improved the organization in a real and specific way.
Sure, you could stop at one Scrum team. You might consider the Scrum team some sort of elite unit, and the other teams 'mere humans' or 'doing it the old way.'
If the new Scrum team appears happy, if they appear successful, if they get the promotions and recognition, well... it's likely the other teams will start to feel ignored, or maybe a bit jealous.
So take volunteers to form Scrum team number two. Once this second team completes its first project, we give it a formal manager and transfer the team members, thus creating another independent unit. Lather, rinse and repeat.
Now it's unlikely that every single team member will want to move over to a Scrum team, and that's okay. In addition to new development, the team will have maintenance requests, ongoing operations and support, or what some call MOOSE work. The people that stay back are likely the ones who take pride in straightforward, repeatable work, and there will likely be plenty of that kind of work to "keep the lights on." Meanwhile, over time, the Scrum teams eventually become the primary drivers of new feature development.
How do I staff and manage this transition?
The newly-formed Scrum teams will need Scrum-masters, coaches, some sort of product manager, and possibly a director or two to report to. So there will be plenty of opportunity for traditional managers to transition over time to the Scrum side of the house.
At the same time, the groups those people manage will be shrinking. That means that as leaders transfer over to the Agile "side of the house," few managers are needed to control the MOOSE work. As the MOOSE work becomes more administrative and easy to measure, it will make sense to merge teams and have fewer managers of those teams.
Eventually you'll end up with two organizations: The development staff and the systems support staff. Or perhaps not; you can always stop somewhere in the middle with a few active Scrum teams, and other organizations largely untouched. In a heavily outsourced or distributed organization, that might be the best win possible, at least for the time being.
This friction between those who want a new way to do things, and folks who prefer the old way, is the cause of a fair amount of conflict, strife, and failure in Scrum adoption.
Some people want to have explicit goals and defined process, and won't be excited about an edict to "Start Scrum on Monday; figure out what needs to be done and do it." On top of that, groups organized by function will have a number of functional managers whose role may be disrupted by a Scrum transition. My advice for Agile transition is not "big bang" but instead incremental, done in a way that respects people and gives them options.
This kind of focusing on people isn't limited to Scrum adoption. It turns out that every time you change the process, you get to decide if you want to focus on people sitting in the same room and talking or churning out documentation. You get to decide if you want to manage to plan or to outcome -- and if you'd like to plan every action of the team up front, or enable them to make good decisions in the moment.
Scaling from Agile development to Agile ALM