Overview

The purpose of adopting Scrum is not to adopt Scrum in and of itself. It is to make a team and its organization more effective. The best way to do this is to learn how to do Agile & then use the Scrum framework to support these practices. This is the opposite of learning the Scrum framework first and leaving teams to figure out how to do Agile.

Scrum is usually taught as a forcing framework. That is, use Scrum’s immutable roles, events, artifacts and rules to both uncover impediments to a team’s ability to deliver value as well as force the team to adopt solid Agile methods that will overcome these challenges (e.g., small stories are needed so they can be completed in a sprint).

Another way to adopt Scrum, however, is to directly learn what doing Scrum would have you do while learning enough of Scrum to support these efforts.

We must remember the distinction between Scrum as a framework for developing software in an Agile manner and what Agile software development actually is.  They are not the same.  The first approach leaves the teams to figure out what actual Agile practices they must do. For teams new to Agile this can be difficult. The second approach requires a skilled practitioner to identify how a team should adopt Scrum and teach that to them. Learning the details of Scrum later is not that difficult.

Scrum as a Forcing Framework

This is a kind of two-step process. By attempting to achieve value in two weeks (or whatever sprint length you are using) you will discover your impediments to delivering value quickly. Scrum’s roles, events, artifacts, and rules are immutable to force you to follow them. Actions you take to follow them will improve your delivery of value. For example, completing stories by the end of the sprint will require having small stories that are accurate descriptions of what is needed. It will also require close collaboration between the product owner and the development team as well as tight collaboration in the development team of coding and testing. This approach is using Scrum as a forcing framework – in order to do the immutable aspects of Scrum you are forced to make changes to your work. While it tells you the objective, it doesn’t tell you how. This is not unlike the ubiquitous financial advice of “buy-low sell high.” Sounds good, but how?

Scrum as a Supporting Framework

This has teams first is to be taught that which Scrum will eventually force you to do. This is not hard to ascertain since the goals of Scrum are fairly straightforward. To paraphrase Ron Jeffries description of Scrum you’ll need:

• a strong connection to the business deciding what needs to be done and what needs to be deffered
• have all the skills you need to build the product right on the team
• have a tested tangible product every couple of weeks and show it to stakeholders
• regularly  review how things went and strive to improve them

This requires an experienced trainer who has development experience  and can ascertain the right practices for the team being adopted in order to accomplish this. This trainer does not need to be a developer now, but must have been one in their career in order to be able to relate to the development team.

The Challenges of Learning Scrum and then Agile

Even if a company has the budget to do a Scrum-centric training followed by what they need to know, the time commitment of their teams is excessive. What typically happens is that teams become well-trained in Scrum and learn a little about Agile analysis, design, code and test, but do not learn it on their own work – so the concepts don’t travel well. Another challenge is that the team now has new things to do for which they don’t always see the value. This often causes resistance. The result is that most developers won’t figure out how to actually adopt the practices they need to in order to make Scrum work. Teams often abandon the rigor of Scrum and practice “Scrum-but” (we do Scrum but we don’t do …) or the Scrum Master becomes dogmatic about following the Scrum mandates.

Adopting Scrum as a supporting framework

A more effective way to adopt Scrum is to focus on what the team actually needs to do to get its work done. This has initial training being light on Scrum and more focused on writing good stories (from the teams own product backlog), how to collaborate and how to complete demonstrable work. This requires some form of Acceptance Test-Driven Development which alleviates most of the challenges teams new to Scrum have – achieving high collaboration and writing small stories. By spending the first workshop days focusing on how to be effective, Scrum’s roles, events, artifacts, and rules can be seen as supporting what needs to happen.  Training a team on what they need to be doing provides an opportunity for them to do hands on work together . A pre-canned Scrum Master class cannot do this since it is about Scrum and not the work Scrum suggests you do.

Conclusion

Given the realities of budgets and time available for training, either approach will have challenges.  The real question is which is more effective for those learning Scrum:

• Learn Scrum and have to figure out how to do that Agile analysis, design, code and test required to be effective?
• Lean how to write clear, effective stories and have a general understanding of Scrum and have to learn how to fill in the blanks of the Scrum training?

The harder part of Agile is actually doing it. The framework provides no detail on how to do this. Scrum is designed for a reason. It will support teams doing Agile development. Therefore, Scrum should be taught as a supporting framework, with the focus on development. People will understand how and why Scrum will support them and figure out those details later. This comparison is assuming equal investments in time and dollars for the training.