CHAPTER NINE

Ownership

Top-notch execution lies in getting the details right, and no one understands the details better than the people who actually do the work. [Poppendieck2003]

Lean Software Development: An Agile Toolkit

Agile teams own their work. They decide for themselves what to work on, how to break it into tasks, and who on the team will do it. This is because of a fundamental Agile principle: the people who are doing the work are the ones who best understand what needs to be done. They’re the ones most qualified to decide the details.

Ownership isn’t just about control, though. It’s also about responsibility. When teams take ownership of their work, they also take responsibility for getting it done.

This chapter has the practices you need to take ownership of your work and successfully get it done:

“Task Planning” helps your team break stories into tasks and decide how they’ll get done.
“Capacity” ensures your team signs up only for what it can complete.
“Slack” improves capacity and allows your team to make reliable short-term commitments.
“Stand-Up Meetings” helps team members coordinate their work.
“Informative Workspace” surrounds your team with useful information.
“Customer Examples” helps your team collaborate with experts.
“Done, Done” focuses your team on creating software that’s ready to release.

OWNERSHIP SOURCES

Self-organization and collective ownership have always been at the heart of Agile.

The ways in which teams plan their tasks has varied. Extreme Programming and Scrum both used short cycles called “iterations” or “sprints.” Other methods, such as Ward Cunningham’s EPISODES pattern language, used a continuous flow of work. [Cunningham1995] XP and Scrum came to dominate the mainstream, and continuous flow fell out of common Agile practice until being reintroduced in David Anderson’s “Kanban” method in 2005.

Task Planning includes both iterations and continuous flow. Its approach to iterations is based on XP, and its approach to continuous flow is based on Arlo Belshee’s “Naked Planning” variant of Kanban.

Capacity has its origins in XP, where it originally involved a calculation called “load factor.” Martin Fowler and Kent Beck distilled the idea down to a simpler “velocity” concept in their book Planning Extreme Programming. [Beck2000b] I’ve renamed it “capacity” to avoid some common misconceptions.

Slack was introduced in the second edition of XP. [Beck2004] I suspect it was influenced by [DeMarco2002]. I was influenced by both those sources, as well as [Goldratt1992], although my resulting take is fairly unique.

My approach to Stand-Up Meetings has been filtered through a variety of sources. Scrum’s “Daily Scrum” formed the base. XP added standing up to make the “Daily Stand-Up,” which is how I first learned it. And the modern “walk the board” approach appears to have originated in a 2007 conference talk by Brian Marick. [Marick2007b]

Informative Workspace is a combination of first edition XP’s “Big Visible Charts,” second edition XP’s “Informative Workspace,” and Alistair Cockburn’s “Convection Currents of Information.” [Cockburn2006]

Customer Examples is heavily inspired by working with Ward Cunningham on his Framework for Integrated Test (Fit), a tool for allowing customers to communicate via tests. In the first edition of this book, the practice was called “Customer Tests.” It evolved into “Customer Examples” as a result of my experiences using and teaching Fit.

“Done Done” is a common idea with no particular source. The related term “Definition of Done” is commonly attributed to Bill Wake, although he says it didn’t originate with him.¹ It’s since been made a central part of Scrum.

¹ Via personal communication.