Courage and Accountability (go hand in hand)

Accountability, commitment and transparency are terms that frequently pop up in the context of agile and Scrum. Unfortunately, but not uncommon in our industry, the use of these terms seems to happen a lot without much reserve or consideration, out of context, from a superficial or no understanding, as self-elevation attempts by self-acclaimed charlatan-experts; and in a way that even contradicts the principles and values of agile and Scrum. Yet, despite the misuse, they can be essential and powerful drivers of behavior in agile and Scrum.

Good enough reasons for further inquiry, thoughts and consideration, starting with the observation that accountability, commitment and transparency are inter-connected and have the requirement of an important quality in common: COURAGE, also one of the 5 Scrum Values.

Accountability complements Collaboration

‘Accountability’ is the state of a person, a group of people, an organization being accountable. This in turn refers to the expectation, the ability and the willingness to share how a certain result came about in a specific domain or area of accountability; what actions or decisions were or were not taken, explain why these were or where not taken, what the considerations were, etc. Accountability has less to do with the actual result than it has to do with sharing, explaining and justifying the path leading to the actual result.

Accountability thus requires the courage to be honest, to work hard, to do the best you can, to act responsibly, to share information, to reveal reality; not the destructive ‘courage’ commonly demonstrated in achieving a desired result, at any price, cost or damage.

All too often accountability is (mis)understood as the assurance of a desired, future result, the promise of a future outcome, with the built-in threat of laying total blame with the one(s) bearing the accountability when the predicted result is not exactly or completely achieved. It is a hideous expression of a desire for command and control. It builds on a blame culture, not on a goal-oriented culture of learning and improving.

Shall we rename the false understanding of ‘accountability’ to ‘commandability‘?

The undertone of commandability is: „YOU are accountable. It is therefore YOUR job to make it happen, whatever it takes.“ It is in itself obviously disrespectful. Beyond that, in the complex, unpredictable and uncertain environment of software development no approach with the characteristics of commandability is viable anyhow. Because software development by nature thrives on emerging knowledge and facts, and ongoing discovery. It requires the ultimate superhero to live up to the (false assumption of) accountability.

Being accountable for work, a task, a goal is not a promise of a result. Neither is it 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. And in a complex environment, like software development, it reduces the chances of success to extremely low and even zero, at the cost of an extreme feeling of loneliness and being burned. It doesn’t work like that in difficult, creative, unpredictable work. It doesn’t work when being part of a team.

The person taking such individual expectation of a promised result seriously is likely to wander off into a personal death march when lacking this courage to admit it can’t be done alone, that it takes collaboration and help from others to live up to the assigned accountability. It takes courage to ask for help and engage with fellow travelers. It is a type of vulnerability that enables better living up to accountability.

Commandability, the falsified and perverse form of accountability, even brings about the danger of creating silos, silo-thinking and silo-behaviour; at the level of an individual, a team, a product, a department, a company.

Using inverted accountability in a context of Scrum leads to exactly the opposite of the Scrum tenets; cross-functional collaboration, utilizing collective intelligence, bottom-up knowledge creation, shared goals. Yet, accountability remains essential. The false application of it doesn’t drive out 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 clear accountabilities:

• 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 facilitating the understanding and application of Scrum.

These accountabilities are separated, yet all 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. The built-in tension, resulting from the separate accountabilities, invokes productive dissent, helping teams to rise above artificial harmony, recognizable as accommodation, silence and apathy. The tension is a foundation for emerging ideas and the creativity to create the best possible solution. The level of tension however is to be observed and protected from accumulating into unhealthy levels and types of dissent and (personal) conflict.

In the end, true accountability complements collaboration, not supersedes it.

Commitment mirrors Accountability

Accountability is the mirror to commitment. A committed person or team fears not taking up accountability, often it happens even spontaneously and voluntarily. Accountability works better if it induces commitment, if it appeals to intrinsic motivation.

Commitment suffers from a misunderstanding very similar to the misunderstanding that exists over accountability, i.e. being interpreted as a hard-coded contract with a promise of a certain future result. In a context of Scrum this misuse was somewhat reinforced by the past requirement for teams to ‘commit’ to a Sprint. It caused creation of the expectation that all scope would be delivered, no matter.

‚Commitment’ however was always intended as a promise to do the maximum possible in the Sprint and to be transparent about the achieved result at the end of the Sprint. In the complex, creative and highly unpredictable world of software development a commitment on scope is impossible anyhow.

So, commitment is about dedication and applies to the actions, the effort, not the final result. As such it is still a core value of Scrum. Committed people show the courage to do the best they can, to promise they will do the best they can, given the conditions they work in and the means they are given.

Committed people accept accountability. They show no fear of being transparent over the work done, the work not done, changes to a plan, opportunities discovered, problems encountered. Transparency even helps them demonstrating that the best possible result was accomplished, even when it is not the supposed or hoped for reality, whether it is less or more than what was expected. Such transparency comes not without courage.

Transparency Serves a Purpose

Accountability requires transparency. Commitment offers transparency. But transparency serves a purpose, the purpose of learning. Accountability and commitment without the goal of validated learning are meaningless. Transparency for the sake of transparency is meaningless. Accountability, commitment and transparency are the ingredients of progress, not a hammer for blame over the past. Accountability, commitment and transparency without trust, self-organization and regular validations are pointless.

Validated learning is also why work is organized in time-boxes in Scrum, as a way to limit any type of risk and to frequently learn, thereby superseding the traditional notion of failure. Scrum makes validated learning explicit via its implementation of empiricism in software development. Transparency in Scrum serves the frequent cycles of inspection and adaptation. Transparency is needed for all inspectors to know about reality, to assess and evaluate the actual, real status, and adapt to it in order to move on.

Transparency is not necessarily applicable to any sort of information, independent of situation and context. Transparency applies on all information that the people accountable for inspection and adaptation require.

Some illustrations

• In Scrum, the Product Owner typically maximizes the value of the work by ordering the Product Backlog. The Product Owner is accountable for the Product Backlog, accountable for identifying, ordering and expressing product ideas and options. A Product Owner will have an extremely difficult time trying to do this all alone. Consulting with users, stakeholders, and the Development Team, appealing to the collective intelligence of the ecosystem augments a Product Owner’s accountability (and credibility). 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 an Increment of releasable product by the end of the Sprint. Inspection of the Increment 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).
• In Scrum, the Development Team plans and organizes its work for a Sprint. On a daily base the work is optimized and re-planned against the Sprint Goal. What is a demand to make Sprint Backlog transparent outside of the Scrum Team based on? What inspection and adaptation would such ‘transparency’ serve?