Scrum is Difficult to Master — Here’s how you can make it Easier
According to the Scrum Guide, Scrum is simple to understand but difficult to master. The Scrum Guide doesn’t go into detail about why Scrum is difficult to master or how one can make it easier to master.
At the heart of “difficult to master” is the expected change in human behavior. For a team to be successful with Scrum, developers would have to make significant behavioral changes. A Scrum team is expected to be self-organizing and cross-functional. Being cross-functional may be the easy part. Let’s focus on being self-organizing.
Let’s say, a development team has been asked to adopt Scrum. They have been “trained” on Scrum, and have a Scrum master to coach them. They have been asked to “self-organize”. What does it mean to the team?
Before Scrum Adoption
Before Scrum adoption, the development manager created the work plan based on the release requirements, assigned tasks to individual developers, and managed the development project. Developers accepted their task and went about writing their piece of code. If the team faced hurdles, they raised it with the manager who in turn got them addressed. The developers’ primary responsibility was to develop and test “their” piece of the code, well maybe do the integration if asked. Everything else — what, why, how, when was the responsibility of the development manager. Once the code was ready, it was handed over to QA to test. Testers then completed manual and automation testing and reported bugs. Once the bugs were resolved, the feature was handed over to the documentation team. The developers, testers, and doc writers were happy, doing what they did best — code, test, and document respectively. Before Scrum, managers were the decision-makers.
After Scrum Adoption
The adoption of Scrum turned the developers’ lives upside down. Now, not only do they have to code, they have to collectively figure out the complete solutions, and take added responsibilities of team organization that once belonged to the manager. As a “self-organizing” team, the team has to make their own decisions right from estimating how much they can collectively complete in a sprint, resolving impediments, to delivering the committed work. If one developer falls behind or hits a technical challenge, someone else on the team must step up. The show must go on. The focus has now suddenly shifted to the collective team, and if the individuals are not prepared for it, they are in for a huge surprise. Often, in my experience, this becomes the first resistance to adopting Scrum, which experienced Scrum Master and Product owner can anticipate.
Cultural Impact
Add to that, developers may not be comfortable to open up and express their thoughts and opinions to authority figures, and discussing successes and failures in team meetings as it may not be consistent with cultural norms in their part of the world.
Self-Organizing Team
A self-organizing team controls all aspects of its day-to-day work. For example, they run the Daily Scrum meetings, decide who works on what and the order in which the work will be done. The team decides how to take advantage of the team members’ special skills and areas of expertise. For a team to do this effectively and successfully, the team has to adopt the five values of Scrum — Commitment, Courage, Focus, Openness, and Respect.
“Successful use of Scrum depends on people becoming more proficient in living these five values” — Scrum Guide
This is what makes Scrum so hard to master. Some teams find it difficult, almost impossible to become courageous and be open to discussing difficult topics, and that too in a team setting. Scrum demands a significant mindset change. It is easy to say that developers should have the courage to speak up. But, it is incredibly difficult to actually translate into actual behavior. The team may find it even more difficult of management expects this change right away since the team is now “trained” in Scrum. Companies generally underestimate the psychological impact of “self-organizing”. At this point, in the absence of “living the five values”, Scrum becomes nothing more than lip service.
Let’s think about it from a developer’s perspective. Before Scrum, his success criteria was simple. He controlled his own career destiny because all he had to do was to take care of his own tasks successfully. Now, in addition to coding and testing, he has to keep an eye on the bigger picture, the Sprint Goal. He has to find ways to come up with the best solution, he has to decide what and how much to plan in a sprint, and finally, make sure the team collectively delivers. Now, he has to act like an entrepreneur, and like an entrepreneur, he is now responsible for the success of the team. In some cultures, a typical developer may not be comfortable with this. He wants someone to tell him what to code, and he goes off into his own little world and does his magic. If he enjoyed making all these planning and execution decisions, he may have chosen a different career. I have seen developers who put off the Scrum training for as long as they can, just to avoid Scrum. Now add to this the fact that with Scrum adoption, the responsibility of the developer has increased many folds, but the salary of the developer has remained the same. The developers see this as a no-win situation, that is until they experience the benefits of Scrum.
How to make it Easier
Management, with the help of the Scrum Master & the Product owner, can make it a bit easier for the developers by taking a measured and gradual approach. Instead of asking the team to take the plunge into Scrum, coach them on the basic principle of trust. Create a work culture where developers are comfortable talking about difficult situations that currently exist, but no one talks about it. The trust goes well beyond the team. Developers have to trust the team and so does the management. Only when the team has the courage to “safely” discuss tough issues, without being penalized, they will open up. As the team works together and self-organize, they will develop respect for each other and gain the confidence of management. Imbibing the five values of Scrum early on, even before the formal adoption of Scrum can be the difference between success and failure.
Management should initiate a change in a work culture where the team feels safe to make mistakes. This will give the team the courage to experiment. At the same time, the responsibilities of the development or project manager should start to gradually shift to the team. The success of this shift will be noticeable in the energy of the team and the increase in collaboration. Management should give the space required for the team to realize that Scrum gives them a lot more control over their work. The team is now free to make their own decisions based on reality instead of decisions being forced on them — be it the technical architecture or design or the time it takes to complete a specific task. Once the team learns to work together, it really becomes “self-organizing”. And once the team becomes self-organizing, it is well on its way to a successful Scrum journey.
Conclusion
Management has a huge role to play in creating a culture that promotes the five values of Scrum. Once the team experiences the positives of self-organization, they are more likely to adopt it. The more the team becomes self-organizing, the more they experience the control they have over their work. This in turn leads to the real benefits from Scrum. Management has to be cognizant of prevailing social etiquette and culture and how it impacts employee behavior. This will help management identify the right approach to coaching and training the team on Scrum adoption.
This is a one-time opportunity at the beginning of Scrum adoption. If done successfully, the company will reap the real benefits from Scrum for a long time to come.
