5 Questions Leaders Need to Ask Before Adopting Scrum

Organizations don’t magically become agile overnight. It’s a significant transition process that requires every individual to reexamine and adapt their role. And it starts with leadership answering some fairly difficult questions.

Editor’s note: This is a guest post by Scrum Trainer and Coach Kane Mar, founder of Scrumology.com and creator of Scrum101.com.
The challenges modern organizations face make Agile compelling. Who wouldn’t want more frequent releases of product? Who doesn’t want to be more adaptable to an ever-changing business environment? But too many leaders are contemplating adopting Scrum without understanding the full impact that Scrum can have on their organization, career, and goals. 
Introducing Scrum into an organization is not something that should be implemented lightly, and leaders need to prepare themselves for some difficult questions. Scrum is not something that only the engineering teams do. It cannot be constrained to just one team. Scrum is systemic change within an organization, and it is frequently described as hard and disruptive. But what does that really mean? What are some of the likely impacts of doing Scrum?
Here are five questions that need to be addressed in order to prepare for a successful and productive adoption of Scrum.

How will I react to changes that impact my role?

This question needs to be answered by everyone within the organization, not just the teams that are implementing Scrum. The most immediate impact of Scrum is on the teams, but it doesn’t stop there. What is the role of a line manager? How are you likely to react when Scrum impacts your leadership role?
Quick example: Scrum and Middle Management
I was having breakfast with my friend John (not his real name). John was a Development manager at a large financial services company that had adopted Agile over the last several years.
He was concerned about how his role was viewed within the company. I asked him why he was concerned, and he said that, “Initially everything was good; the teams made quick progress and a team-based environment suits people more than a shared services approach. But now we have teams that largely resolve their own issues, and monitor their own performance.”
He wanted to know what his role was in this new, self-organizing/self-managing environment.
The function of middle managers in companies modeled around Scientific Management (also known as Taylorism) largely revolves around the performance and efficiency of staff. Taylorism has been credited to being a large part of the productivity gains for the 20th Century. It is, however, less suitable for the creation of modern knowledge-based products.
So, how does the role of middle management change when transitioning to Scrum?
After some discussion with John, he determined that he could add value by being a mentor and communicator, by showing his teams what was needed by the business, and by showing the business how his teams could meet their needs.

How do you deal with a star performer who doesn’t want to go on the journey?

Scrum is not for everyone. Many people enjoy Scrum because it allows them to create a product that they can have direct influence over, and that can be very rewarding. Not everyone will feel this way.
Quick Example: The Disgruntled Star
Jack was a star performer within his team, and he was quick to point this out to everyone. As the team approached a deadline it was common to see Jack working 80 hours a week to help the team meet their goals. He would often be seen in the office at 10pm and would send emails to senior management during the weekends. Management loved him!
But the quality of his work was questionable. He produced a lot of code that didn’t work or required substantial rework. After another overnight binge by Jack, the other team members would spend several days trying to debug and integrate the code.
They tried to show Jack how his behavior impacted the rest of the team, but he was unwilling to listen and dismissed the teams concerns by saying, “Take it up with management.”

This situation changed when Scrum was introduced to the team. Team progress and visibility was discussed every day during the Daily Scrum, so daily progress was constantly measured by the team. And by allowing the team to determine how much work they could complete within an iteration, the team was able to work at a more sustainable pace throughout the duration of the project.
During the retrospective, the team questioned the value of creating code that was not fully tested and took time away from other team members.
Jack didn’t take well to the introduction of Scrum. The visibility provided by the Daily Scrum clearly highlighted that Jack did not deliver code consistently but would delay work until the last day of the Sprint. When the team made suggestions to help the problem he complained of micro-management.
He was uncomfortable working at a sustainable pace, and rather than focusing on adding the most value to the customer he complained that the work was “boring” or “not challenging enough”.
When the team committed to improving the quality of their code by continuously testing during a retrospective, Jack threatened to quit the team and the organization. Five sprints after adopting Scrum, Jack left the company of this own free will. The performance of the team continued to improve, and three years on they are still producing a high quality product.
When adopting Agile, companies need to consider what happens when a star performer decides that they don’t want to work on a Scrum team. Are you prepared to let them go? Or should they stay with the company potentially disrupting other Scrum teams? If you’re willing to let them go, how do you justify that?

What mechanisms are you going to use to change the behavior of individuals?

Scrum requires changes in behavior including self organization, greater collaboration, and transparency. Changing behaviors is incredibly difficult, especially for long-term employees who have been trained to behave in a particular way. Now that there is a need to change, how are you going to make sure that actually happens?
Ongoing professional education plays a key role here. As management leaders, we can support existing staff with training, coaching, and conferences to help them understand and apply modern techniques of software development. And by demonstrating the company commitment to existing employees, we can improve morale and employee satisfaction with the the company at the same time.

A fundamental part of these behavioral changes is trust between the team members. If I collaborate with someone and they understand my job, am I putting my performance review at risk? Am I putting my job at risk? How is trust going to be established if the answer to either of these questions is, “Yes”?
One common approach is to change the responsibilities and metrics employees are evaluated on. To encourage collaborative behavior, more emphasis is placed on teamwork over individual contributions. One way to do this is with team-based or 360 performance reviews.
De-emphasizing individual contributions calls into question individual responsibilities. No one wants to be responsible for a given area if they’re going to be measured by the performance of the team. So, naturally Scrum team members need to be responsible for delivering across multiple areas. In short, they need to deliver an increment of potentially shippable product every sprint.
This may seem like a small point, but it has a huge implication on how the company operates. If the teams are responsible for working across multiple different subject areas, how does that impact your organizational structure?

How will support departments feel about the changes brought about by Scrum?

Scrum is frequently introduced to an organization through software development teams. Support and Architectural teams are very seldom thought about in advance. That’s because many organizations assume that Scrum is “something that developers do.”
But the fact is introducing Scrum is going to effect other teams. For example, how are support teams going to react when there is friction with the Scrum teams? How is this like to be resolved?
Quick Example: Mis-Alignment Between Departments
Sarah was a senior Java Messaging Service (JMS) architect and was responsible for her company’s vision of an Enterprise Service Bus (ESB). She was becoming frustrated by Scrum teams “who are not conforming to the corporate guideline by either creating products that by-passed the ESB, or added new features that are not aligned with the corporate strategy.”
When asked why she thought the Scrum teams were behaving in this manner, she suggested that they needed more discipline and education about the ESB strategy. And then she added, “Or, perhaps we’re not meeting their needs.”
After further discussion Sarah decided that the best option was to join a Scrum team to understand their challenges and to help them better understand the objectives of the company.

How much is the organization willing to spend on this transformation? And what value is being delivered for this expense?

Few companies set out with a clear understanding of the return they should get from adopting Agile. After all, there is little direct data available that provides a detailed idea of what return to expect. There is, however, anecdotal evidence which suggests adopting Scrum is beneficial in terms of more frequent releases, better quality of product, and greater engagement with customers.
One common solution is to allocate a fixed training budget every year for ongoing staff training and coaching, but this suffers when the pace of the agile adoption is greater than the budget allows for, and can be difficult to justify when returns are not explicitly called out.
A better solution would be to measure several key metrics such as:

• Revenue per Employee
• Customer Satisfaction
• Employee satisfaction

Watching those metrics over a period of time to see how (or even if) the Agile adoption improves those metrics can give leaders an idea of the effectiveness of the adoption, and whether changes need to be made over time.
There are a few interesting points with this solution that are worth pointing out: First, it is independent of the framework being used, and could be used to measure a company’s performance regardless of whether they choose to adopt Agile. Secondly, you may find that Scrum is not the best approach for the company, or that there are other frameworks that are more effective than Scrum. This is rarely the case, but it’s certainly a possibility.
This approach to measurement is exactly the approach taken by Ken Schwaber in his recently released Evidence Based Management approach. It is still to early to determine what impact this approach will have on the software development community, but it is a really interesting solution and has the potential to show companies direct tangible evidence of their improvement.

The Big Takeaway

Adopting Scrum is not something that can or should be done lightly. It involves risks to the organization as well as to individuals. By understanding the questions that people ask, you will better understand their motivations, fears, and uncertainties. This knowledge will help form a more comprehensive approach, sensitive to the needs of both the company and its employees.

“The capacity for logical thought is one of the things that makes us human. But in a world of ubiquitous information and advanced analytical tools, logic alone won’t do. What will distinguish those who thrive will be their ability to understand what makes their fellow woman or man tick, to forge relationships, and to care for others.”

― Daniel H. Pink, bestselling author of Drive
 

Learn More: Free Quick Guide for Executives

//

Image by Patrick Burgler