Introducing SCRUM into the Organization
In this chapter, we will discuss how a tech team can approach the process of becoming agile through adapting a SCRUM methodology for their project management approach.
Before introducing any change into a team or organization, it is important to take stock of the current context. If the tech team is high performing and management is particularly happy with their output, then you have to ask yourself, "Why attempt a major organizational change?"
The idea of introducing an Agile process usually arises because certain members of the team or management see an opportunity to improve upon existing quality, output, and processes. They could also be frustrated with their current situation because progress and output are below expectations.
It is important to take note of any pain points, goals, and desired outcomes that the team and management have before implementing a change process in the organization. This establishes the reasoning behind the desire to change. It will be of useful moving forward, particularly if adopting a new process brings challenges. You can remind everyone involved why it is worth this effort.
Top Down and Bottom Up Change Processes
It is worth noting that change can be promoted/suggested in two ways:
Top Down - where management teams believe in the value of change and push employees to adopt new processes that management think will be more effective.
Bottom Up - where the employees or team members doing the work want to improve their own processes and attempt to persuade management of the value in making a series of changes.
Deciding Where to Start
Several factors make successful SCRUM adoption more likely. You should look to see which teams and projects in the organization can match some of these criteria:
Employees who have already worked in SCRUM will be excellent members for the first teams. They can help team members who are new to the practice.
Tech leads often make good SCRUM Masters. They must be open-minded, eager to learn, and attend the relevant training.
Projects which are failing can be a good place to try something new that breaks progress into smaller, measurable units.
Projects where the team is already motivated to try SCRUM (bottom-up buy-in is already achieved) and where management is at least willing to entertain the idea of change (top-down buy-in seems possible) will make adoption more likely.
introduce SCRUM to one team first and then other teams can also adopt it when the first team enjoys some early success.
Achieving Buy-In with Common Language
When introducing SCRUM, it is likely that some team and management members will not be familiar with it. Therefore you need to explain what it is, and only then can people make up their mind. How you present "what SCRUM is" will be critically important to how open they are to adopting SCRUM (or at least learning more).
The Janrain team suggest using common language when explaining what SCRUM is and then relating that to SCRUM terminology. For example, you explain to a stakeholder that you would like to spend one hour every two weeks showing them a demo of all the work the team has done. Most likely, the stakeholder will think this is a good idea. You can later refer to this as a "sprint demo" or a "sprint review."
Here are some other common language descriptions for SCRUM terminology:
Backlog: A single list of all future requirements prioritized according to business value.
Daily Stand-up: A daily 15 minute status meeting where developers will share progress and call out if there are any blockers or impediments.
Sprint: A two-week cycle of development.
Sprint retrospective: A team meeting at the end of a two-week cycle to assess how well the team is doing and if any improvement is needed.
User stories: A one sentence summary of a requirement written in non-technical language so that everyone can understand it.
Product Owner: The person responsible for prioritizing the work we do each two weeks.
SCRUM Master: The person who ensures that the process is working well and that the team is meeting commitments. It's also the person you can ask if you have any questions about all of this.
Educate the Organization
The wider organization (people who don't work in or manage teach teams) will also be curious about using SCRUM.
Organize information sessions where employees can attend and get a very quick and easy-to-understand introduction to how SCRUM works. They can be informed of any upcoming events and ask questions about how the change will affect them. This is especially good for those who want to stay up-to-date with product improvements and make feature requests.
Kotter's Change Process
Harvard Business School professor, John Kotter, suggested an 8-step change process for effective organizational change management. These can be useful steps for you to consider when introducing Agile processes into the organization.
Establish a sense of urgency - identify why change is important, what frustrations the team wants to remove, and what opportunities lie ahead. Link the proposed change to these improvements.
Form a powerful coalition - It may be that the tech team will listen to a senior engineer in the team more than they will listen to you. Getting that person on your side first, then having them explain the benefits can be a very effective way of persuading a team. The same is true for upper management, where a key ally with a high reputation can generate support for change on a managerial level on your behalf.
Create a vision - A vision is a short, compelling, desirable and achievable statement of some future state that will inspire people.
Communicating the vision - Talk to people about this vision and spend time explaining why it is desirable and what meaning it has for them.
Empowering others to act on the vision - By changing corporate structures, removing obstacles, and creating a culture of risk-taking, others can be encouraged to act.
Planning for and creating short-term wins - Change can take time. Along the way, there are smaller and easier ways to achieve victories that will show everyone that the new way is working. Management is also less likely to cancel your efforts if they see success. Team morale will also improve.
Consolidating improvements and producing still more change - Use your increasing credibility (due to short-term wins) to change policies and systems within the organization to better fit the vision.
Institutionalizing new approaches - Embedding the change as part of the company's operational procedures.
Adopting SCRUM is a major change process. Understanding the current context (pain points, opportunities) of the organization is important so that the motivation for change can be made clear.
Use common language when introducing SCRUM to people who don't know it.
Aim for top-down and bottom-up buy-in.