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.

Part 5 is the summary post for this series.

2 Replies to “Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability”

  1. Hi Johanna, great article !

    Do you think that a development team can shift to this flow efficiency mindset if the company as a whole praises personal accomplishment rather than team work ? And what about individual performance reviews? Do you think they still make sense in an environment that is trying to shift to the flow efficiency mindset (therefore team work) ?

    1. Hi Thiago, thanks!

      The team can still use flow efficiency. I have seen problems arise when the managers (and HR) insist on resource efficiency instead of flow efficiency. I often ask managers questions such as these:
      – What is more important to you: Speed of delivery or knowing who did what?
      – What is more important to you: reinforcing expertise or helping other people learn the entire stack/problem/domain?
      – What is more important to you: Solving a problem or knowing how many minutes/hours/ one individual spent on a problem?

      Too many managers think software development is piece work, a factory. But software is the instantiation of learning and problem-solving. We rarely, if ever, solve problems alone.

      I also talk to managers about their work. That’s when they realize they are part of a team, too. That’s when I really start to make progress.

      I discussed these questions in this article: If Managers Don’t Give Performance Reviews, What Happens? . That points to other articles, etc.

Leave a Reply