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.
2 responses to “Accountability, responsibility, and trust”
If I were giving someone a suggestion on how to resolve such a conflict of internal trust, aside from pointing my finger at a developer and saying ‘Do what you say you’re going to do!’ (which is an important step), I would recommend that a company such as the one you’re talking about should make someone else the scrum-master rather than the product or product manager, or even a development manager.
You probably already know this, but other readers might not, but with an agile, scrum-based team, a scrum-master should be someone who has no management power over the team-members. This allows for the team to be fully honest about their work without fear that the scrum-master will be putting their lower velocities on the papers for their next promotion. They will truly feel that the SM is there to coach them to increase velocity and to be more transparent and honest with their work without fear or retribution or judgement.
Also, I recommend making a tiered ranking of scrum-masters. In the event that the primary master cannot attend a stand-up, the next-ranking master will lead the stand-up… and none of those should be people in a position of power.
Having a scrum-master who has power can also lead to mis-trust amongst the group as developers tend to want to please their managers, and if their master is the same as the the manager, it can lead to some interested “miscalculations” of tasks. To confuse a coach with a leader can cause an internal breakdown.
Here are some resources I’ve used for my own scrum-for-one resources and research:
http://www.codeenigma.com/en/blog/scrum-master-not-project-manager
http://pm.stackexchange.com/questions/4707/why-cant-the-scrum-master-and-the-project-manager-be-the-same-person
http://www.scrumalliance.org/community/articles/2012/august/a-scrum-master-is-not-a-project-manager-by-another
Thanks for that, Tabby! You’re right that in a pure scrum situation, the word ‘team leader’ was inappropriate – there is no team leader in scrum!
I would say that ultimately, the team is responsible for policing their own. The Scrum Master may take the lead on privately addressing individual’s behaviors that do not meet the team’s standard, but the team should decide what happens to individuals that don’t meet expectations. Which should be obvious and apparent at the daily stand up.