Accountability, responsibility, and trust

One of the fascinating things about agile team structure is the delineation between responsibility and accountability. While I may be in charge of making sure something gets done, I may not actually be the one to perform the work. I am accountable to a task without being responsible for actually doing it.

As a scrum master, I may be accountable for explaining and improving the team’s velocity, but I do not directly impact the velocity – I am not responsible for the work done that creates or alters the velocity. Only the development team can be responsible for the estimation and volume of work that is completed.

It’s an interesting paradigm, to separate who is held to the fire for something from who will actually do that something. That takes a huge amount of trust within the team – to trust the responsible party will do what they say they will do.

And if there is no trust? That’s a huge problem if a team member doesn’t fulfill their responsibilities. Which gets exacerbated if there are no reciprocal dependencies between us – if mutually assured destruction is not an option, albeit a last resort, clearly.

If I am accountable for things that you are responsible for, and you never fulfill your responsibilities, then there is a problem. A foundational breakdown of trust and responsibility, fracturing a team from the inside.

Be on the lookout, team leader, for small breaches that may lead to larger collapses. Defend your team vigilantly against actions that erode trust.