Kick Start Scrum with Explicit Rules

Scrum provides a simple set of rules that have proven to work in thousands of projects.  I am an advocate for the benefits of the prescriptive framework of rules that Scrum provides because it is easily understood and repeatable in many different situations.  However, I don’t think this set of rules is sufficient and I don’t agree with the premise that additional rules should be discovered by the team solely through Scrum’s inspect and adapt mechanisms.  I have observed too many obvious cases where teams first have to experience the same problems and then either adapt to add practices which are well known to the agile community or just get stuck.  Initially their biggest challenge is often learning to work as a team so this blog will suggest adding some explicit rules from the beginning that reinforce and enable teamwork.

New Scrum teams frequently experience the following pattern in their first Sprint:

• A five to seven person team has committed to about five stories
• On day two of the Sprint work has started working on all stories
• On the last day of the Sprint the team has completed maybe one story and are scrambling to complete the rest

There are numerous opportunities for discovery during the retrospective from a sprint like this and I have heard Agile coaches claim this to be a constructive opportunity for the team to learn how they can work together as a cross functional team.  That may be true if an experienced Agile coach is in place to guide the team to recognize and address the root causes, then get them to take actions that limit work in process and engage more of the team in each story.  Consider how this makes a new team member feel about their first sprint experience.  They are likely starting with a disappointing feeling that perhaps Scrum doesn’t work that well after all, or may ask, ‘why didn’t someone just warn me about this before we made these mistakes?’

Let’s explore this initial example a bit further and see what additional rules we could start with to help avoid this situation. What is wrong with starting work on all of the stories early in the sprint?  In other words, what are the consequences and root causes? 

Consequences

• There is a high risk that most stories will not be completed and fully tested to meet the definition of done
• The top one or two most important stories may not get done
• Testers complain they were overwhelmed with testing at the end of the sprint but didn’t have anything to do at the beginning
• Coders were busy at the beginning but didn’t have much to do at the end of the sprint
• Increased pressure to tradeoff quality and accept stories that aren’t really “done”

Root causes

• Once committed in a sprint, the top ranked story is no longer a priority to work on first
• Individuals are working separately on each story
• There is no concurrent team work on a story
• Naïve tasking where each story has two tasks: “code it”, “test it”
• Definition of Done way too comprehensive and complicated to start with

In this example people are still working as individuals and haven’t learned how to coordinate working together as a team to accomplish a shared deliverable. Developers may claim, “it’s ineffective to have more than one coder work on a story at the same time because we would be stepping on each other’s toes”.  A scrumudgeonly coach may ask, “What does that say about the design of the code?”

Possible Practices and Rules that might help avoid this situation:

Practices

• Swarming is an agile practice where the entire team tackles one story at a time.  While this may not be the ideal approach for every sprint, it does help a team learn how to work together effectively.
• Task stories to include test planning and setup concurrent with design and coding; testers can then be prepared to more quickly perform tests and provide quicker feedback when coding is ready.  If testers and coders share a tasking plan, some testing may commence before all coding is complete.
• Include time to design code for each story and reflect it in tasking

Rules

• Work-In-Process Limit Rule: No more than half the stories in a sprint may be open at one time. 

This strikes a balance between the two extremes of swarming on one story at a time or having everyone working on separate stories.  This rule could also express that only a given number of stories may be open; no more than 3 for example.

• Maximum Task Size Rule: If estimate for an Individual Task is more than 4 hours then the task needs to be broken down further
• Test Planning Rule: Any story to add new feature functionality must have a separate task for acceptance test planning and preparation in addition to post code testing
• Coding Design Rule: Any story with more than 8 hours of coding work needs to have a separate design task
• Initial DoD Rule: A team’s initial Defintion of Done should be short, simple, and unambiguous. It should have no more than 6 or 7 criteria including these three:

1.       Accepted by the Product Owner

2.       No known defects in a story

3.       Each story has a persistent repeatable acceptance test

Definition of Done

Scrum includes the Definition of Done .  This should make it clear that quality is not negotiable when counting completed work at the end of a sprint.  A common problem is that many organizations make their Definition of Done way too comprehensive and complicated to start with. Combine an exhaustive Definition of Done with the situation in our initial example and people will be tempted to relax acceptance against the Definition of Done or slide defects in new code until later so that they can count their coded but not quite “done” stories as complete in the sprint.  People will be tempted to do this anyway.  I think this breaks the fundamental Scrum framework when it happens. See Chris Sterling’s post on Building a Definition of Done for advice on creating a DoD for your team.

Conclusions

A popular misconception is that Agile discourages process rules. This may be because the Agile Manifesto states, “Individuals and interactions over processes and tools.” I think there is value in stating more explicit rules both as a starting point and as a continuous improvement tool.  These rules should be adaptable. They are first intended to improve teamwork and the flow of work through each sprint.  Then making rules more explicit helps the team become more aware of the agile mechanisms at work in their Scrum system so that they can experiment and change them.  I want to recognize that Kanban has built in the concept of explicit policies for this purpose and I appreciate how it embraces them for continuous improvement.

If you want to get faster results from Scrum and help your teams to become highly productive sooner you may consider hiring an experienced Agile coach as a new team’s initial ScrumMaster.  An experienced agile coach brings a deep set of heuristics about what they and others in the Agile community have seen work in past situations along with the insistent mentoring to challenge teams to make adaptive changes more rapidly.  A lot of their value added comes from priming the initial conditions with suggestions like these rules to help new teams avoid common pitfalls. Jeff Sutherlands post about RapidScrum’s  Scrum"Shock Therapy" How To Change Teams FAST gives a good example

My goal for this blog posting is to elicit more rules for Scrum teams to consider adding to their working agreement without necessarily having to go through the pain of repeating common mistakes.  I think this can be especially valuable for larger organizations that are repeatedly launching new Scrum teams. Having more consistent rules across different Scrum teams can significantly accelerate their ramp up with faster wins for new teams.  I will add future posts with more rule ideas that can help people work as a team to deliver high quality, working products faster.