Make Your Scrum Agile

By Asheesh Mehdiratta,

There is no question Scrum is evolving, improving.  Like all Agile methods/frameworks/… it improves by seeing how well it works and adapting.  There are many practices that weren’t in the original Scrum definition that are now considered good starting practices. These include:

• Agreeing on what a sprint ready story is
• Agreeing on a definition of done
• 1-2 week sprints (instead of the 30 days originally defined)

This blog will give you insights into how to accelerate the effectiveness of your Scrum adoption.

Scrum is a framework that many people feel should always start reasonably empty.  However, with 14 years of experience doing Scrum we have found several practices that virtually all teams end up doing.  While you may not want to start with all of these, we believe you should know what these practices are starting out so you don’t have to reinvent the wheel when it is time to do them. Also, some of these practices will make the transition to Scrum easier, not harder, if done right up front. .

Lean and Kanban start with an understanding of why it is important not to disrupt the workflow of a team.  It has several practices for doing this, the most prevalent is managing the number of items being worked on at any one time (known as WIP for Work in Progress).  Some have mistakenly misinterpreted this as Lean/Kanban being tool or practice centric.  It is just the opposite - both are motivated by helping people.  Because we respect people we want to make sure they don’t waste their time.

Most teams starting with Agile/Scrum are somewhat overloaded when they begin.  This leads some to think they need to start with as simple a Scrum model (framework) as possible.  I believe the question isn’t “how little should they start with” but “what practices can they immediately adopt that makes the transition easier."  Some practices are almost immediately understood by teams because they match the team members' experience - or implicit knowledge.  By implicit knowledge I mean those things that are known intuitively, but perhaps not explicitly discussed.  For example, all developers understand that if you interrupt their work when they get back to it it’ll take longer than it would have taken if it hadn’t been interrupted. 

Most of those new to Agile development are not new to software development.  Respecting them means we want to take advantage of what they know.  Most importantly, if we are giving them something new to do, we must respect that they are already somewhat overwhelmed.  I am reminded of the saying “when you are up to your ass in alligators it’s hard to remember that you are there to drain the swamp.”

We have found six practices that can be added to the Scrum framework that can vastly increase its effectiveness.  Many of these can be adopted right at the beginning:

1. Drive from business value
2. Use Acceptance Test-Driven Development (ATDD)
3. Limit Work in Progress
4. Have an explicit workflow
5. Use relative estimation
6. Break stories down into smaller pieces

These are all what we call trimtabs – that is, activities that change the environment within which we work to produce significant results – typically with relatively little effort. Let's go through each of these in a little more detail.

Drive from business value. This is more of a mindset shift than anything else.  The product owner is not the only person responsible for the value of the software being developed.  Coming from business value provides insights early that many Scrum teams only learn after a few failed releases. See  Minimal-Marketable Features: The Why of Enterprise Agility lightning webinar.

Use Acceptance Test-Driven Development.  ATDD improves communication and understanding and takes less time to do than not. The challenge is the rearrangement of the workflow.

Limit Work-in-Progress. Virtually all Scrum teams eventually learn to limit how many stories they have open.  While they will eventually learn this on their own, it is often more effective to relate a new practice to old experience than it is to make people learn from new experience. See  Real Tenets of Lean: Avoid Creating Waste By Eliminating Delays for more.

Use relative estimation methods. There are many methods of doing estimation.  We’ve found Mike Cohn’s Planning Poker to be cool, but not very efficient.  Other methods that are based on comparisons (e.g., Steve Bochman’s Team Estimation and James Grenning’s Planning Poker) are typically just as effective and take a fraction of the time to do.

Break stories down into smaller pieces.  Working on smaller stories (1-3 days in length) has many advantages.  This is the one practice of those listed, however, that can often take considerably new skills to do.

In conclusion

While you don’t to overload teams when they start out, you should look for what practices can be provided to the team right at the beginning to give them a jump start on things.  Taking advantage of what they know may enable some seemingly advanced practices to actually make the transition to Scrum take less effort.

Source: PMI - Agile Community of Practice