Getting Started with Team-Agility or Scrum

Lean-Agile at the Team: A Lean approach to Scrum and Kanban (online book)

 
Provide Feedback

Contents

The advice in this article is intended for software teams (either product or IT) who are adopting Scrum.

Is Scrum applicable for your team?

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:

Before adopting Scrum, it is important to ask if Scrum is applicable for your team. As with any approach, Scrum should not be used as a one-sized fits all. Abraham Maslow observed – “If all you have is a hammer everything looks like a nail.” 

Scrum was designed for a team working on a project/product. Its inspiration lies in The New New Product Development Game which we highly recommend reading whether you are doing Scrum or not.

And here’s a summary from the chapter that describes the issues:

How well Scrum and Kanban fit certain situations.

Scrum is simple to understand; it shouldn’t be difficult to do

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:

  1. it must include the entire team – Product Owner, development team and Scrum Master
  2. it should be about the team and not the Scrum Master role
  3. it should include how to break down chunks of value into features and stories through the use of Acceptance Test-Driven Development

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:

  • Almost all teams learning Scrum make the same mistakes and how to avoid these mistakes is well known
  • Scrum Masters and teams are different roles and need different training
    • Scrum Masters need to know the Scrum core practices in greater depth than the team since they will be coaching the teams
    • The team needs to know more Agile practices that they will use than the Scrum Master who does not do development
  • Product Owners should train with the Scrum team to enhance understanding and collaboration

What should be in every Team-Agility / Scrum team training

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:

  • Estimation
  • Instilling a test-first mindset in team members and the product owner (by this we mean just consider how you’ll know you’ve achieved the goal before you write start coding)
  • Backlog refinement
  • Managing work in process with a focus on finishing (WIP limits not required or recommended)

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.

What should be in your Team-Agility / Scrum training

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.

How Team-Agility / Scrum Masters should be trained

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.

Start simple, but prepare the teams for upcoming challenges

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.

Why Scrum team training should include the Product Owners

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).

Common challenges to expect at the start

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.

Teaching for retention and understanding

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.

Providing a support system for continued learning

Learning a new way to do work requires an understanding of how people learn and the limitations this presents to us. in particular, people:

  1. Can only absorb so much at any one time
  2. Learn better by doing
  3. Need something very specific at the start
  4. Need to continue learning over time
  5. Learn new ideas best by example

Scrum’s roles, practices and artifacts are presented so that teams can get started. A support system of templates, FAQs and webinars should be provided when teams are ready to go deeper.