This is the next in a series of posts about resource efficiency vs. flow efficiency:
- Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System
- Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People
- Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance
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.
| Reference: | Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability from our JCG partner Johanna Rothman at the Managing Product Development blog. |
