Home » Agile » Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability

About Johanna Rothman

Johanna consults, speaks, and writes about managing product development. She helps managers and leaders do reasonable things that work. You can read more of her writings at jrothman.com.

Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability

This is the next in a series of posts about resource efficiency vs. flow efficiency:

Managers new to agile often ask, “How do I know people will be accountable?” Let’s tease apart the pieces of accountability:

  • Accountable to the project for finishing their own work
  • Accountable to their team for participating fully by doing their work
  • Accountable to help other people learn what they did by documenting their work
  • Accountable for meeting their estimates
  • Accountable for how the project spends money
  • … There might be more accountabilities

Let’s take the first two together:

Accountable for finishing their own work and by doing their work

I suspect that managers mean, “How do I know each person does their work? How do I know they aren’t asking other people to do their work? How do I know these people are learning to do their own work?”

Those are good questions. I have yet to see a single-person feature. At the least, a developer needs someone to test their work. Yes, it’s possible to test your own work. Some of you are quite good at that, I bet. Many people are not. If you want to prevent rework, build in checking in some form or another: pairing, design review, code review, unit tests, system tests, something.

So the part about “own work” seems a little micro-managing to me.

The part about doing their work is a little trickier. When people get stuck, what do they do? Often, they ask someone else for help. The help might be: talk to the duck, an explanation about what is going on in that area of the product, pairing on solving the problem, or even talking to more people.

There is no such thing as “cheating” at work. Managers are right to be concerned that people work to their capabilities. And, if those people are stuck, I don’t want them mired in the problem. We want people to learn, not be stuck.

Here’s the answer: You can’t know as a manager. You never did know as a manager.

The team knows who is hardworking and who slacks. The team knows how people are learning and if they are stuck. Even in waterfall days, the team knew. Managers may have had the illusion they knew, but they didn’t. Managers only knew what people told them.

Accountable for documentation

For me, the question is who will use the documentation? I am always amazed at how many managers want documentation other than end-user documentation and how few teams find this useful. In agile, you could make it part of the definition of done.

If people build documentation time into their estimates and the team finds the internal documentation useful, the team will pressure each person to deliver their documentation. The team knows whether the person documents their work.

Accountable for living up to estimates

When I ask managers if they want good estimates or completed features, they almost always say, “completed features.” Too often, the people multitask on fixing defects or production support work while they are supposed to work on a feature. I do understand the need for estimates, but holding people to their estimates? Sometimes, that’s about money.

Accountable for how the project spends money

Of all the accountabilities, this one makes the most sense to me. However, it doesn’t make sense in agile, where the customer/product owner is the one responsible. As long as the team completes features, the PO determines when either there is no more value in the backlog, or there is no more money for the project. With any luck, the team has met the release criteria by this time.

For me, the idea of accountability is a team-based idea, not a person-based idea. In flow efficiency, you can ask the team to be accountable for:

  • Finishing features
  • Knowing where they are with respect to the features in progress
  • Helping the PO understand the value of features and how long features will take
  • Providing an estimate, if necessary
  • If the team works in iterations, committing to work and not overcommitting to too much work

When you look at accountability like this, it looks pretty different than a single person’s accountability.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....


Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions


Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments