Craig RudmanBeyond Software with Scrum?

Everyone who takes part in a Scrum project eventually has the thought, “Hey, Scrum could be used for just about any kind of project – it’s not specific to software projects!” After all, there’s nothing in Scrum that refers specifically to software engineering. And Scrum has a very simple and elegant structure that’s easy to manage:

1. convene a project
2. declare a set of objectives
3. prioritize objectives into an ordered list
4. let the project team determine how to translate objectives into work items
5. use a ScrumMaster to facilitate communication between Product Owner and Team
6. let the project team take responsibility for the work in a way that makes sense to them
7. deliver the project in fixed-duration sprints so that the team can come to know their strengths
8. review and accept work in increments to retire the product backlog

And on reflection, it seems to me to map pretty well to Stephen Covey’s “7 Habits of Highly Effective People”:

1. Be Proactive – establish a project and fund it
2. Begin with the End In Mind – declare a Product Backlog
3. Put First Things First – prioritize the Product Backlog
4. Think Win/Win – let the Team select backlog items for a Sprint in a manner that lets them be successful
5. Seek First to Understand, Then to be Understood – a Sprint planning session is structured just so… first the Product Owner communicates needs, then the Team communicates a plan for meeting those needs
6. Synergize – this is the essence of a Daily Scrum meeting, the highly-visible Sprint backlog, not to mention the Scrum social structure which is intentionally collegial rather than hierarchical. This allows people to have more fun and bring unexpected skills or insights to the process.
7. Sharpen the saw – short iterations, collaboration, reviews, project delivery metrics… these are tools to help all participants become better at what they do.

So, if you accept these basic assertions, why don’t we see Scrum more broadly applied to other disciplines?

One explanation might be that few have tried. Scrum was conceived and communicated as an approach to software project management and it has remained closely associated to software projects. It is possible that it remains relatively unknown outside of software and system development circles.

On the other hand, maybe Scrum is widely accepted as a project management paradigm outside of software and system development, but I haven’t heard of it because I’m in a bubble. I tested this possibility by doing a Google search for “Scrum project” and the only context that came back is software. So I’m pretty confident that Scrum hasn’t bled very much over into other disciplines.

Another possibility is that software projects have particular qualities or pose certain challenges that make Scrum compelling, while other types of project do not. A few such attributes come to mind:

• Software teams are more interdependent – Software team members are working on parts that integrate and must work together so there is more need for short build-and-integrate cycles, frequent inspection, and daily communication. Other projects – a marketing campaign, for example – might require less integration of work products and thus, fewer dependencies and linkages. This is one quality being examined in The Marble Run Challenge.
• Software projects are conceived in one lexicon but delivered in another – It’s common to software projects that stakeholders understand the needs and objectives and possess business acumen, but may not be proficient in the technologies required to realize the vision. The project team may have that technical proficiency, but lack the business acumen. That’s why we have Product Owner and Team, and ScrumMaster to bridge the gap. Any kind of project that deals with a technical or scientific product is likely to share this quality.
• Software is easy to conceive and difficult to get right – All too often, a project falls off the rails because stakeholders haven’t been able to see actual work-in-progress. Perhaps they’ve seen a requirements specification, or a design document, but when the software is delivered, it doesn’t match what they thought they agreed to.

There are probably many other reasons… I’m curious to know what you think.