AoAD2 Chapter: Ownership (introduction)

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.

Lean Software Development

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 due to 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.

When teams take ownership of their work, they also take responsibility for getting it done.

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:

• The “Task Planning” practice: Break stories into tasks and decide how they’ll get done.

• The “Capacity” practice: Stabilize your short-term plans by signing up for what you can actually complete.

• The “Slack” practice: Improve capacity and make reliable short-term commitments.

• The “Stand-Up Meetings” practice: Coordinate every day about how your team will finish their work.

• The “Informative Workspace” practice: Surround your team with useful information.

• The “Customer Examples” practice: Collaborate with experts to understand tricky details.

• The “Done Done” practice: Create software that’s ready to be released.

Two key ideas are central to ownership. The first was included in the “Teamwork” chapter and the second is included in this chapter:

• “Key Idea: Self-Organizing Teams”: Agile teams decide for themselves what to work on, who will do it, and how the work will be done.

• “Key Idea: Collective Ownership”: Team members take joint responsibility for making the team’s work a success.

Ownership Sources

Self-organization and collective ownership has always been at the heart of Agile. In the early days, the assumption was that teams would work in relatively short cycles called “iterations” (also called “Sprints”). This idea was found in every Agile process. The specific approach I describe was inspired by Extreme Programming (XP).

Around 2005—I’m not sure of the exact date—David Anderson started pushing for a continuous flow of work rather than iterations. He called it “Kanban.” He encountered a lot of resistance in the Agile community, but he persisted, and that persistence paid off. Kanban is now widely recognized and used. The specific continuous flow approach in this book is based on Arlo Belshee’s “Naked Planning” variant.

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 the simpler “velocity” concept in their book Planning Extreme Programming. [Beck and Fowler 2000] I’ve renamed it to “capacity” to avoid some common misconceptions.

Slack, as a practice, was introduced in the second edition XP book [Beck 2004]. I suspect it was influenced by [DeMarco 2002]. I was influenced by both those sources, as well as [Goldratt 1992], although my resulting take is fairly unique.

Daily stand-ups come from Scrum, where they’re called the “Daily Scrum.” The modern “walk the board” variant that I recommend in this book was filtered through a variety of influences, but it appears to have originated with Kanban.

My take on “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” in [Cockburn 2001].

The “Customer Examples” practice is heavily inspired by working with Ward Cunningham on his Framework for Integrated Test (Fit), a tool for allowing customers to write tests. In the first edition of this book, the practice was called “Customer Tests.” It’s 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” comes from Scrum.

XXX Further reading to consider:

• Turn the Ship Around

Bill Wake reading recommandations:

• Facilitator's Guide to Participatory Decision-Making, by Sam Kaner - or another facilitation book

• Getting It Done: How to Lead When You're Not in Charge, by Roger Fisher and Alan Sharp

• Quality Software Management (series), Jerry Weinberg - Not something I used day-to-day but good background

• Maybe: The Effective Manager, by Mark Horstmann. - I haven't read his book, but I used to follow their podcasts, and attended their 2-day training years ago. It's not an agile perspective, but rather focused on managing for organizational results, with concrete advice on coaching, one-on-ones, feedback, & delegation. (You'd want to vet this - the perspective may not be a fit.)