Principles and Practices All Agile (including Scrum) Teams Should Know and Follow

There has been a lot of debate about which is better, Scrum or Kanban. We believe an integration of methods is best. Having seen literally hundreds of teams learn Scrum, both those we’ve trained and those trained by others, we’ve seen patterns of success and challenge. We believe many of these challenges can be mitigated by properly arming the teams with concepts they would otherwise have to figure out on their own. Our belief is if it is likely a team is going to run into a problem it is better to arm them with the knowledge required to solve it. We do not ascribe to the minimalistic approach many in the agile community do (see The Case Against Minimalism ). This page describes many of these core principles and practices that we feel most any team, no matter how small, will find useful.

The most important of these is described on How to Vastly Improve Your Scrum Team in an Hour which includes information on acceptance testing, better estimation methods and why eliminating delays is so critical. You should definitely start there if you haven’t read it.

We’ve broken these concepts and practices by category. While you should read through all of these, you may want to skip ahead and see if any of the following represent particular challenges for you. Feel free to just jump to those as each section is written independently of the others.

Core Principles ("laws of software development") to be aware of

Delay cause waste. Watch this 12 minute video - How Delays Cause Waste: A Main Tenet of Lean. For example, delays from when information is gathered until it is used or from when an error occurs until it is detected literally creates extra work is readily confirmed from your own experience. Minimizing these delays is a key method to improved performance and quality. See Eliminate Delays to Avoid Creating Waste for a list of some of the typical delays that can be minimized.. It is important to get work completed as quickly as possible. Working on a small number of small stories at any one time is a good way to accomplish this.

Working on too many things increases delays that cause waste. This should be self-evident. This is why managing how many things in play at any one time is so critical. "Stop starting and start finishing" is a useful mantra.

When work in progress (WIP) exceeds team capacity, these delays go up significantly – thereby causing more of this unnecessary work. Managing WIP can therefore greatly help a team’s efficiency.

Optimize the whole. Improving one aspect of your development process can often hurt the overall performance of your organization. It is critical to consider the entire value stream - that is, the workflow from when work starts until it is consumed by the customer.

Understand the importance of the Minimum Marketable Features. See an 11 minute video that explains what Minimum Marketable Features are and why they are essential to Agile methods.

Focusing on productivity by keeping people busy actually lowers productivity because it tends to have people do too many things.

Practices to Implement the Core Principles

Managing Requirements

Have a vision statement for your project. Vision statements are very important to get everyone on the same page. See page 42 of our Lean-Agile Pocket Guide for Scrum Teams.

Break your requirements into small stories that represent end-to-end functionality. There are many reasons for this. By end-to-end functionality we mean vertical slices – that is each slice represents some path through the system that can be seen from the outside – that is the customer. Large systems are often built in layers. By creating end-to-end functionality, the people working on the different layers are required to work together and test their assumptions. The difference between horizontal and vertical slices is illustrated in the following figure.

Horizontal or Vertical Slices

 


Have all stories be no longer than 3 days (1 is better). Note, this does not imply using days for story length. We prefer story points. Creating small stories, it is possible to get feedback quickly. We’ve come across many teams who are certain they can’t break down stories any smaller than a month or a few weeks. However, this is because they are unaware of methods that enable even very complex requirements to be broken down into small stories. While the classic story format of “As a <role> I want <function> so that I can get <value>” definitely has limitations in complex situations. But other formats, such as “when the system is in <this state> and this <event> occurs, I get <this outcome>” are much more powerful in breaking stories into small pieces. Breaking stories down into small pieces is a critical practice and we believe it can always be done. If you don’t believe that, contact us, we’ll be happy to do a free consult to test our belief.

The product owner should act like a champion leading the team to discover what needs to be built, not a dictator of what to build (nor should he fear his neck might get wrung).

Use Minimum Marketable Features (or their equivalent), not epics, to guide stories being pulled off the backlog. See Minimum Marketable Features lightning webinar (<11min).

Use Acceptance Test-Driven Development . ATDD is a great method to:

  • Clarify what your requirements are
  • Assist everyone working together to speed completion of stories (particularly coders and testers)
  • Raise the quality of your software

Keep the number of MMF's (Minimum Marketable Features) open at any time to a minimum. You won’t get any value released until an MMF is done. Therefore, working on something besides the most important MMF usually delays its release – as well as creating additional work (remember, delays cause additional work to be done). One method of ensuring MMFs can get done quickly is to not start working on stories from one MMF until the MMF being worked on is completed.

Plan ahead enough to enable all stories in the iteration to have had acceptance tests written at the start of the iteration, but no more. Some consider it taboo to work on a story before it has been selected for completion in an iteration. This rule, however, is simplistic – not bad for beginners, but not truly the right rule either. Starting to implement a story in one iteration and then finishing it in another will most likely make the story take more time. However, getting acceptance tests specified in one story and beginning the work on it in another most likely won’t. While it is not good to look ahead very far, not understanding the acceptance tests for a story means you will be starting stories without truly understanding the amount of work in them. Be clear that we are not suggesting doing Scrum with an analysis sprint, a design sprint, a code sprint and a test sprint. That is not Scrum.

Managing Flow

Have team-mates work together on finishing stories. This shortens the time for stories to be completed.

Your sprint length should be no longer the 2 weeks in length. See The Rationale for a Maximum Sprint Length of 30 Days for more information on this.

Continuous Learning

Make all work visible. Explicit Policies Speed Learning. I talk a little bit about this at my Lean Kanban 2009 – Wow! Blog. Also, see Chris Shinkle’s Embracing Kanban that made me realize this.

Have the team discuss how they make decisions on a regular basis – having explicit policies is much more effective than people just using their judgment at the moment.

  • Really do retrospections - don't let them become stale
  • When deciding on how to do things, use economics and cycle time (time from start of feature to consumption) as the main drivers
  • Really do retrospections - don't let them become stale

Management

 

Upcoming Events