Buy it now!

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Accountability

If Agile teams own their work and their plans, how do their organizations know they’re doing the right thing? How do they know that the team is doing its best possible work, given the resources, information, and people it has?

Organizations may be willing, even eager, for teams to follow an Agile approach, but this doesn’t mean Agile teams have carte blanche authority to do whatever they want. They’re still accountable to the organization. They need to demonstrate that they’re spending the organization’s time and money appropriately.

This chapter has the practices you need to be accountable:

• The “Stakeholder Trust” practice allows your team to work effectively with stakeholders.

• The “Stakeholder Demos” practice provides feedback about your team’s progress.

• The “Forecasting” practice predicts when software will be released.

• The “Roadmaps” practice shares your team’s progress and plans.

• The “Management” practice helps teams excel.

Accountability Sources

Accountability is more implicit than explicit in Agile literature. In the days of Extreme Programming, the community talked about a “customer bill of rights,” an early version of which could be found in the preface of the first XP book:

To customers and managers, XP promises that they will get the most possible value out of every programming week. Every few weeks they will be able to see concrete progress on goals they care about. They will be able to change the direction of the project in the middle of development without incurring exorbitant costs. [Beck2000a]

Extreme Programming Explained, 1st edition

This is a strong statement of accountability: “we will give you the most possible value.” But XP didn’t have much to say about how to demonstrate accountability. Instead, the team’s software was assumed to speak for itself. Stakeholder Demos is an example of this sort of accountability. It’s based on Scrum’s “Sprint Reviews.”

But managers and organizations want more than just software out of their teams; they want to know that the teams are working effectively, too. This has led me to explicitly define practices that Agile processes usually gloss over.

The first practice in this chapter is Stakeholder Trust. It’s a truly fundamental idea—so fundamental, that I can’t say where my specific techniques came from. They’re based on applying various ideas I’ve heard over the years and noticing which worked best. My discussion of Roadmaps is similar: I’ve tried a lot of ideas and shared what works.

Forecasting is another idea that’s been around since the early days of software, although it’s usually called “estimating.” I’ve absorbed ideas from too many sources to remember. My favorite source isn’t actually a forecasting approach at all. It’s [Little2006], an article by Todd Little that compares hundreds of forecasts to actual release dates. It draws strong conclusions about uncertainty and predictability. Little’s article has been a significant influence on my thinking about forecasting and is the basis of the discussion in this book.

My discussion of Management is strongly inspired by Robert Austin’s book, Measuring and Managing Performance in Organizations [Austin1996], as well as ideas absorbed from working with Diana Larsen over many years.