One of our clients recently reached out to us asking for advice about how to manage their organization’s scaled scrum adoption. They wanted to know if they could use scrum to manage the adoption of scrum in the organization. The short answer is yes.
Guiding an organization’s adoption of scrum is a big project. It’s a project that will require a cross-functional team. It’s a project where the full scope of work can’t be known when the work starts. It’s complex, exactly the kind of endeavor that you want to use scrum to implement. When I’m working with organizations that are adopting scrum at scale, I always start by recommending that they create a scrum adoption team, and that this team use scrum to do the work of rolling scrum out to the organization.
One of the many benefits of leaders using scrum to guide their organization’s adoption of scrum is that they are leading by doing, instead of telling. “Do as I do” is much more compelling than “Do as I say.” The leaders will also develop a much deeper understanding of what they are asking their people to do, and will be better able to understand the changes needed in order to be successful.
This team needs a product owner, someone who can answer the question “Why is this organization adopting scrum?” The organization’s management is seeking some kind of value, and they believe that investing in this scrum adoption will get them that value. Is the value faster time to market? Higher product quality? Happier customers? Happier employees? Something else? These are all laudable goals, but it’s important that the product owner for the scrum adoption team understand which of these is most important to the business. Based on this knowledge, the product owner can create and share a vision for how this scrum adoption will create value for the organization. This vision will guide the team’s work.
The scrum adoption team will need a product backlog filled with the deliverables of the scrum adoption itself. One product backlog item might be identifying a pilot project to try using scrum. Another product backlog item might be to pick the team members for that first scrum team. Yet another item might be to get scrum training from Agile Learning Labs for that first team (okay, that was shameless). As the organization starts to adopt scrum, the scrum adoption team will discover impediments that are preventing scrum from working well, such as middle managers that aren’t willing to let go of control. These impediments will lead to new items in the scrum adoption team’s backlog. Perhaps they’ll decide to bring in Agile Learning Labs to do some training and coaching with those middle managers (okay, I’ll stop now).
The team will need a scrum master. As with any team, the scrum master will focus on helping this team become high performing. The scrum master will coach the team and help them use scrum effectively to self-organize and continuously improve.
Most importantly, the team needs team members. These should be people from various parts of the organization who will do the work of guiding the organization’s adoption of scrum. I recommend that the team have some permanent members, perhaps high-level managers from engineering, test, product, and human resources. The team should also have a rotating group of people from the field. These are people who will be using scrum and/or be impacted by the organization’s adoption of scrum. Examples include: scrum masters, product owners, engineers, testers, managers, and anyone who will interact with a scrum team. These rotating members should serve on the team for pre-defined terms, perhaps three to six months. These members of the scrum adoption team will provide the muscle to get the scrum adoption team’s work done. They will also act as eyes and ears, keeping the adoption team in touch with what’s really going on.
Here are a couple of things to be careful of. First is the role of the scrum adoption team itself. Scrum is about ‘doing it better and better’ not about ‘doing it right’ and so the scrum adoption team should not be the scrum police, telling the teams how they are doing it wrong. Their mission should be to help the organization learn, improve, and drive toward the specific value that the organization is seeking from their scrum adoption. Focusing more on education and less on enforcement usually leads to better results.
Secondly, the scrum adoption team needs to guide the organization in the selection of appropriate metrics for the scrum adoption. Measure the wrong things, and that’s what you will get! For example, velocity (often measured in story points) is a terrible metric. No organization ever adopts scrum to get “more velocity.” What they probably want is to deliver more value or to reduce time to market. So create metrics that focus on these things, not velocity.
Obviously, I’ve just scratched the surface here. Hopefully it helps you get started creating your scrum adoption team.
Have you been a part of a scrum adoption team? Or perhaps you’ve worked at an organization that needed one, but didn’t have one? Leave a comment and let’s talk about it.