Is Agile only for software development? Or perhaps only for product development? At Agile2009 in Chicago, Jeff Sutherland and his wife Arlene presented two papers on adopting Scrum, one at OpenView Partners Venture Capital and the other at a number of Unitarian Churches.

I attended Agile2009 in Chicago and there were two presentations about implementing Scrum in non-software development organizations.  “Scrum in Church: Saving the World One Team at a Time,” by the Rev. Arline Conan Sutherland, Jeff Sutherland, Ph.D., and Christine Hegarty as well as “Take No Prisoners: How a Venture Capital Group Does Scrum,” by Jeff Sutherland, Ph.D. and Igor Altman. I had first heard about these parallel Scrum adoptions from Jeff Sutherland himself in early 2008 and was eager to see the papers once they were formally presented. I was not disappointed.

The abstract from “Scrum in Church”:

From 2005 – 2009 the author led Scrum teams in churches in Massachusetts, Connecticut, Florida, and Delaware. Scrum was designed to increase productivity and improve quality through teamwork. This experience report shows how Scrum was implemented in non-profit organizations to break down silos of knowledge and activity, encourage communication and collaboration, improve the working environment and personal relationships, and drive higher velocity and quality throughout the organization. Non-profits have impediments that are difficult to overcome – part-time and volunteer workers, narrow specialization, little to no experience with project teams, and political problems whose roots can go back as far as 1692. Scrum as an institutional change agent is invaluable to a church.

The abstract from “Take No Prisoners”:

In 2007, OpenView Venture Partners decided to adopt Scrum as best practice in software development in its portfolio companies and Scrum as the standard practice in internal operations. It is one of the first high-performance non-software Scrums that delivers twice as much value in fewer working hours. The model at OpenView provides data and a working manual on how to do Scrum outside of software development. Their aggressive removal of impediments (take no prisoners!) distinguishes them from Scrum implementations that are unable to remove institutionalized waste.

My take-aways:

The Scrum methodology is to be adapted to the environment. One size does not fit all. Arlene wrote “each and every time Scrum is introduced into a system it has to be adapted.”

Biggest gains in productivity came from:

1. Creation and active management of a product backlog (20% or more new features, 80% maintenance, & aggressively remove low value stories & projects)
2. Clear definition of “done.”
3. Creation and aggressive management of an impediment backlog combined with root cause analysis.

People who are used to working as a team generally don’t resist the Scrum method as much as those who are very independent. In fact some people are too independent to be part of a team.

When stories are broken down into tasks, it is easier to see how team members can help each other out.

Interruptions and emergencies are a fact of working life and do in fact interrupt sprints [Church]. My response to this is that the key then is to carve out chunks of protected time (c.f. Covey’s 1st things 1st and Cirillo’s Pomodoro Technique.).

Vocabulary can be a stumbling block. I think this is because vocabulary is dependent on the culture. There have been a number of blogs on the topic Agile adoption being a culture shift with the inevitable culture shock. Those of us who look to implement Scrum and Agile in non-software organizations should watch our vocabulary. We should balance explaining concepts in a language the local culture understands with retaining those parts of the vocabulary that are different enough to be retained. For example, it’s safe to call a sprint an iteration or even a fixed schedule release. Back in the late ’90s we called this a release train.  Daily Scrum, stand-up, or daily status?  Whereas impediments are impediments because they are those things which impede us from achieving our goal.

What’s also interesting is that all the teams mentioned were most productive with one-week sprints. This contrasts sharply with the accepted wisdom that novice teams start off with one-month sprints and eventually settle on two-week sprints. I suspect that the difference is mostly due to the nature of the work. In both papers the teams are not creating products, software, or any system. In fact most of their stories are so small they resemble tasks. I’m reminded of Stephen Covey suggesting focusing one week at a time instead of one month at a time. The take-away here I believe is the sprint duration must be sized to the project at hand.

While not mentioned in the Church paper, the Take No Prisoners papers discusses at length the pitfalls of estimating in ideal hours instead of points. The biggest impact is that velocity remains flat as teams become more productive. Whereas using story points shows that the team can deliver more story points over time. By focusing on ideal hours, the team has to make some guesses on increased productivity (focus factor) in order to understand just how much their capacity really is. This strikes me as a compelling argument to avoid the temptation all of us faced when first confronted with estimating in ideal days versus points. This also speaks to predictability which is critical when trying to plan a release.

At the 10,000 foot level it comes down to Four Focus Areas:

• Direction (the backlog)
• Speed
• Quality
• Sustainability and Predictability

and avoiding the “5 Dysfunctions of a Team” by embracing:

• Trust
• Openness to conflict
• Commitment
• Accountability
• Attention to Results

Do you have any experience applying Scrum and/or Agile in a non-software development team or organization? Please let us know. We’d love to hear from you.