Accountability and commitment. We hear these words a lot in the business and Agile world, but what do they mean, and how do we do them well?
Accountability
We’ve all seen instances of “accountability” in the form of blaming and shaming: (“Whose fault is it?” and “What were you thinking?) These are the forms that accountability takes in a fear-based organization. The blaming and shaming approach to accountability creates unhealthy stress, shuts down creativity, and limits the success that people and organizations can achieve to only what is achievable via “safe” choices.
However, some people and organizations that have rejected a fear-based culture, and the blaming and shaming that go with it, may swing the other way, and avoid holding people accountable at all. I don’t know how to hold you to account without blaming and shaming you, so I won’t say anything at all, even though your work or follow-through has not met my expectations or the organization’s standards. You might have experienced this dilemma. But surely this can’t be the only alternative?
The Learning Organization
The Learning Organization starts from the premise that every failure to meet expectations is an opportunity for learning – not just for the individuals involved, but potentially for the organization as a whole. When we approach accountability from that viewpoint, accountability becomes: when you are accountable, you can be asked to account for your actions and decisions so that we can both/all learn from that. To hold you accountable is not to blame you or shame you, but to inquire into how did we miss the mark? What can we learn from that so that we are better enabled for success in the future? And what amends or recovery actions are appropriate?
William Davidson makes the point that there are several conditions for accountability:
- The person or team must have a clear understanding of what they are responsible for.
- The person or team must understand how their success will be assessed, as well as the consequences for success or failure.
- The person or team must have sufficient autonomy to deliver what they are responsible for.
- There must be an agreement on how progress will be measured and tracked.
- There must be an agreement on how and when feedback will be provided, and by whom.
Commitment goes hand in hand with accountability and can have variations such as Commitment to a Role, and Commitment as a Team.
Commitment to a Role
In the dynamic landscape of projects, clients, products and contracts, we frequently experience role shifts: I am now Scrum Master for team XYZ, or I am now Product Owner for product ABC. This may come about by volunteering within a team – “Who wants to be the Scrum Master for this project?” “I will!” – or by invitation – “Andrew, will you take on the Product Owner role for this project?” What’s interesting is that taking on a role is a commitment for which I am accountable… sometimes a role shift is something we “slide” into without realizing that we are making a commitment. Taking on a role is a good time to examine whether the conditions for accountability are met and whether I can make a commitment to that role. Ask yourself these questions:
- Do I have a clear understanding of what I am responsible for?
- How will success be assessed? What are the consequences for success or failure?
- What autonomy do I have to be successful? What knowledge, skills and resources will I need to be successful? How do I get those if I don’t have them already?
- How will my progress be measured and tracked?
- How will I get feedback on how I am doing? Who will give it to me? When?
- Who am I accountable to?
- Can I make this commitment?
Commitment as a Team
Agile asks us to commit as a team: to take on shared responsibility for meeting the team’s goals. In Scrum, this occurs in every sprint planning. This collective responsibility means that each team member, individually, takes ownership of the team’s goals and output. It prompts questions such as:
- How can I best contribute to the team meeting its goals? What knowledge, skill or experience do I have that would help other team members and help the team move forward? How can I offer that?
- Am I happy with the quality of the team’s work? Would I be proud to show what we have done to the customer, another engineer, or the person paying the bills?
- Do I have the skills and knowledge to complete an item I took on? If I get stuck, what’s the right balance between struggling and asking for help? Can I ask for help when I need it? Can I admit areas that I feel less strong in and get mentoring or other feedback from stronger team members? Can I accept help when it is offered?
- Are we meeting the appropriate standard of care (definition of done)? Am I willing to speak up if I see the team or a team member compromising or creating technical debt?
- Are we improving? Do I see areas in which we could get better? How can I contribute to the team’s growth?
- How do I skillfully hold my teammates accountable for the team’s goals and our individual parts in it?
… which brings us back to accountability.
Team commitment asks for holding each other mutually accountable to the team’s goals. In a learning organization, that might look like, “Hey Andrew, I notice that you’ve been working on the XYZ story for 2 days – I could be a second set of eyes for you on this – shall we pair up to get it knocked out?” or, “Hey Andrew, it feels like that story is going slower than we expected – how could we progress on that?” In team accountability, we don’t blame others for their weakness or struggle, we bring them along with us, and provide the support and encouragement to grow in skill, knowledge, and capability.
Accountability and Commitment
At the end of the day, accountability and commitment are about trust. Can I trust you? Can I depend on you to do what you say you will, or get back to me early if you run into trouble? Commitment and accountability are a two-way street for building trust and ensuring overall progress. In a learning organization, commitment and accountability are tools for not only getting things done, but getting better at doing them.
Originally published June 21st, 2016 on the Innovative Software Engineering blog. Republished with permission.