Software is created by people; for better or for worse. That is very different from looking at software development as a robotizeable activity. The agile worldview builds on software development being a creative activity (not: industrial) undertaken by and for people (not: replaceable pieces of machinery). It explains the high prevalence of terms like 'emergence', 'collaboration' and 'self-organization' in an agile context. Often overlooked, and even forgotten, however is the aspect of 'accountability', although it is an important amplifier that provides direction, purpose and a boundary to working with people. Accountability is a quality of agile.
'Accountability' refers to the state of 'being accountable', the state encompassing the expectation, the ability and the willingness to share not only a result, but even more how a result came into existence. It refers to sharing the actions and decisions that were or were not taken, explain why these actions were or were not taken, what the considerations were, etc. Actually, accountability has less to do with the actual result than it has to do with sharing, explaining and justifying the actions taken or not taken, the decisions made or not made and all associated considerations that have led to the actual result.
Accountability has a strong connection to agility via Scrum as it implies transparency, working hard, doing the best you can, acting responsibly, sharing information, revealing reality, striving for the art of possible. It is not about the false promise and faking to achieve a preset result, at any price, no matter the cost or damage. All too often accountability is (mis)understood as such assurance of a desired, future result, a promise of a future outcome. And such understanding has the built-in threat of laying total blame with the person(s) accountable when the predicted result is not exactly or not completely achieved. Assigning accountability in that way, from such understanding of it, is just a hideous expression of a desire for command and control.
The undertone is: "YOU are accountable. It is YOUR job to make it happen, whatever it takes." When this message is taken seriously in a complex environment like software development, most of the times it results in individualist hero behavior that reduces the chances of joy and success to below zero. Being accountable for work, a task, a goal is not an obligation to do everything alone. It looks like courage to try to do so, but it isn't. It is mistaking courage for individual heroism. It just doesn't work in difficult, creative, unpredictable work. It doesn't work when being part of a team. Not only are the chances of joy and success wiped out, the accountable individual is likely to wander off into a personal death march at the cost of inhumane loneliness and burn-out.
It takes collaboration and help from others to live up to an accountability. It takes courage to ask for help and engage with fellow travelers. It is the sort of vulnerability that enables better living up to accountability.
In a context of Scrum the described inverted form of accountability leads to exactly the opposite of the Scrum tenets; cross-functional collaboration, utilizing collective intelligence, bottom-up knowledge creation, shared goals. Yet, accountability is essential. The false application of it doesn’t reduce its importance. Removing and avoiding accountability has disastrous effects as well; no vision, no focus, no direction, no choices, endless discussions and meetings, indecisiveness; a Gordian knot.
Scrum foresees a clear accountability for each Scrum role:
These accountabilities are separated, yet all are needed. It is why these roles need to collaborate as a Scrum Team with a shared responsibility toward the organization, its customers and the wider ecosystem.
Some illustrations:
In the end, true accountability complements collaboration, not supersedes it.
'Accountability' refers to the state of 'being accountable', the state encompassing the expectation, the ability and the willingness to share not only a result, but even more how a result came into existence. It refers to sharing the actions and decisions that were or were not taken, explain why these actions were or were not taken, what the considerations were, etc. Actually, accountability has less to do with the actual result than it has to do with sharing, explaining and justifying the actions taken or not taken, the decisions made or not made and all associated considerations that have led to the actual result.
Accountability has a strong connection to agility via Scrum as it implies transparency, working hard, doing the best you can, acting responsibly, sharing information, revealing reality, striving for the art of possible. It is not about the false promise and faking to achieve a preset result, at any price, no matter the cost or damage. All too often accountability is (mis)understood as such assurance of a desired, future result, a promise of a future outcome. And such understanding has the built-in threat of laying total blame with the person(s) accountable when the predicted result is not exactly or not completely achieved. Assigning accountability in that way, from such understanding of it, is just a hideous expression of a desire for command and control.The undertone is: "YOU are accountable. It is YOUR job to make it happen, whatever it takes." When this message is taken seriously in a complex environment like software development, most of the times it results in individualist hero behavior that reduces the chances of joy and success to below zero. Being accountable for work, a task, a goal is not an obligation to do everything alone. It looks like courage to try to do so, but it isn't. It is mistaking courage for individual heroism. It just doesn't work in difficult, creative, unpredictable work. It doesn't work when being part of a team. Not only are the chances of joy and success wiped out, the accountable individual is likely to wander off into a personal death march at the cost of inhumane loneliness and burn-out.
It takes collaboration and help from others to live up to an accountability. It takes courage to ask for help and engage with fellow travelers. It is the sort of vulnerability that enables better living up to accountability.
In a context of Scrum the described inverted form of accountability leads to exactly the opposite of the Scrum tenets; cross-functional collaboration, utilizing collective intelligence, bottom-up knowledge creation, shared goals. Yet, accountability is essential. The false application of it doesn’t reduce its importance. Removing and avoiding accountability has disastrous effects as well; no vision, no focus, no direction, no choices, endless discussions and meetings, indecisiveness; a Gordian knot.
Scrum foresees a clear accountability for each Scrum role:
- The Development Team is accountable for creating releasable Increments.
- The Product Owner is accountable for maximizing the value of the work.
- The Scrum Master is accountable for the understanding and application of Scrum.
These accountabilities are separated, yet all are needed. It is why these roles need to collaborate as a Scrum Team with a shared responsibility toward the organization, its customers and the wider ecosystem.
Some illustrations:
- In Scrum, the Product Owner manages the Product Backlog to create a flow of value, with the accountability of identifying, selecting, ordering and expressing product ideas and options. A Product Owner trying to do this all alone will have an extremely difficult time. Consulting with users, stakeholders, and the Development Team, appealing to the collective intelligence of the ecosystem augments a Product Owner’s accountability (and credibility) drastically. And it doesn’t prevent the Product Owner from having the final call and prevent being stalled in endless debate.
- In Scrum, the Development Team is accountable for creating Increments of releasable product. Inspection of an Increment by the end of a Sprint requires transparency over the state of the Increment, over its quality. A much used practice to achieve such transparency is the ‘definition of Done’. A Development Team will have a difficult time providing full transparency through the definition of Done when only allowing in what they like or care to care about. Consulting with the Product Owner, taking into account the organization’s quality standards, regulatory requirements, etc. augments a Development Team’s accountability (and credibility) drastically.
In the end, true accountability complements collaboration, not supersedes it.