The advice in this article is intended for software teams (either product or IT) who are adopting Scrum.
Before undertaking an adoption of Scrum, it is important to ask if “Scrum is applicable for your team?”
It is highly recommended you read that article before continuing – but here’s how it starts:
And here’s a summary from the chapter that describes the issues:
Scrum is described in the Scrum Guide “as a lightweight framework that is simple to understand but difficult to master.” Our experience is that it doesn’t need to be ‘difficult to master.’ We believe that much of the reason it is difficult for many lies in the initial training that is provided. We admittedly break with tradition in three ways. We have found the following to be effective for training teams:
Much Scrum training for teams is provided by a Scrum Master training. These are different roles and need different training. In addition, Scrum training for teams who are going to do software development should include core practices that all software development teams need to know.
A lot of Scrum training is also based on the premise that since Scrum is a general, lightweight framework, it should be taught that way. However, we believe that if you are learning Scrum for software development, it is better to learn how to use Scrum for software development. Training in this context enables it to be much more pragmatic to the teams learning Scrum. In addition, with a little preparation, an experienced trainer can provide a few practices specifically for the team involved.
Not providing these core practices at the initial training only requires the teams re-invent them after struggling for a few sprints. Of course, not everything can be provided in the initial training, but a core set should be. In addition, trainers should understand the teams’ context that they are teaching. There are many useful practices that are needed by particular teams. We have found it is better for teams new to Scrum to start with the right way of doing things with a specialized training than it is to get generalized training where they start off in the wrong direction and have to learn to correct on their own. Of course, it is harder for the trainer to do this.
There are a few other few salient things to attend to when getting new teams up on Scrum:
Clearly the basics of Scrum should be taught. But this is not a very time-consuming task as the entire Scrum guide has only 17 pages of content. Some basic practices are also required although they are not part of the Scrum framework. These include:
Most of the work development teams do are understanding requirements, developing code, and validating that the code meets the requirements. Acceptance Test-Driven Development using Behavior-Driven Development (the defining of test specifications before developing software) has been integrated into teaching Scrum because although Scrum itself is simple, teams need to learn how to create stories. We integrate story writing with tests into our Scrum training to take advantage of this. This is done with the teams’ own stories, so they get a start on applying it to their own work. After the training teams can then take BDD as far as they want, but their mindset will have definitely shifted towards the better. See How to start with ATDD/BDD for more.
Although natural laws of software development apply everywhere, and the principles that emanate from them apply almost everywhere, each company does have its own set of specific challenges. Because of this, you should always have your trainer meet with your staff prior to your training. If nothing else, it will prepare her/him for what to expect and emphasize. But more likely, assuming the trainer is experienced enough, it will enable her/him to see if any particular practices should be emphasized or de-emphasized.
Scrum Masters should definitely attend the team training. While only about half of the training may be relevant to them, this provides an opportunity for greater collaboration between the Scrum Master and team. But, more importantly, it provides the opportunity for the Scrum Master to see what concepts the team is having troubles learning. It also lets the Scrum Master see how the team is taking to Scrum. These insights will be critical to the Scrum Master once the team actually starts doing Scrum.
This is just the beginning of Scrum Master training, however. It is presumed that a Scrum Master already has the attitude of being a good coach. This is not something one learns in days or even months. So pick your Scrum Masters carefully. Learning how to be a Scrum Master requires understanding what’s behind the challenges their team(s) is having with Scrum. This takes a considerable amount of experience.
The best way to teach this is with a several month long program that coaches the Scrum Master in their own work environment. They should be provided some deep Scrum learning each week along with some one-on-one coaching with an experienced Scrum Master. In this way they’ll learn by doing.
Teams need to be given a well-defined set of roles, artifacts, events and rules when starting something new. Scrum has a preset collection of roles, rules, artifacts and events, so if you want to do Scrum, you can stat with them. But consider this start as an example of what can be done. We call this Scrum as Example and it can to start with Scrum but have the attitude that it can be changed later as needed and as appropriate. If you start with Team-Agility you will also want to be able to improve your practices later. See How to improve or change your practices for how to do this.
We also believe Product Owners should be in team Scrum training as well. This helps teach these two roles how to work better together. Much of the work done in the Scrum involves developers and product owners working together. Product Owners define the “what” with the team deciding on the “how.” Since teams also validate what’s built the product owner and development team represent the customer, development and testing – the Triad of Acceptance Test-Driven Development (another name for Behavior Driven Development – BDD).
After deciding that Scrum is applicable, the team can now start implementing it as close to its definition as possible. This lets them get a better understanding of both what Scrum is as well as the challenges they have in their organization. It also provides for a clear, well-defined start, something teams need.
Even when cross-functional teams are readily achievable and planning is possible most Scrum teams have two common challenges:
Breaking down stories into small chunks. Scrum intentionally provides no guidance here – it is a framework. Unfortunately, standard decomposition methods don’t take advantage of what’s been learned in the last decade with Behavior Driven Development (BDD). BDD provides a structure for decomposition that enables virtually any problem domain (including very complex ones such as operating systems and compilers) to be decomposed into small stories.
Having Something Demonstrable At the End of the Sprint. This challenge is related to the first. When teams can’t figure out how to get small stories, they tend to flow over into the next sprint. The value of having sprints degrades and teams often fall into abandoning them entirely – describing what they are doing as Kanban. This is, of course, neither Kanban nor Scrum – just bad Agile.
Because of these challenges, the best way to start with Scrum is to integrate Behavior Driven Development into the Scrum training.
While there are times information must be presented, the best way to learn is by doing. Teaching through well designed set of exercises is essential. In addition, Scrum training needs to help people break down their own work into stories that are small enough. In addition to learning by doing, templates to help people both remember what they’ve learned and to use after the workshop should be provided.
Learning a new way to do work requires an understanding of how people learn and the limitations this presents to us. in particular, people: