Accountability Is Not the Problem You're Looking to Solve
Accountability Is Not the Problem You're Looking to Solve
We look at why a lack of accountability is a symptom of a larger problem among Agile development teams, and what to do about it.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
A frequent answer I receive when I ask about an outcome organizations are looking for out of their Agile transformation is greater accountability. Leadership will say things like "We need our people to be accountable for what they say they're going to do!"
That doesn't sound like accountability to me, that sounds like commitment and conviction. Simply put, what is accountability? It's who is responsible for something. Accountability does not directly correlate or cause commitment to get it done, just who is RESPONSIBLE if that does not happen. If we're wanting people to be more responsible for things and think that they are not, we have a different issue to solve and need to ask why. Let's investigate!
Lack of Accountability Often Means an Absence of Trust
Perceived lack of accountability is a symptom of a larger problem in the organization. If the organization believes their people are not accountable or responsible, that points directly to a deficit in trust. We see both in Patrick Lencioni's hierarchy of the 5 dysfunctions of a team, though avoidance of accountability is not the root problem, absence of trust is.
What I often see as I get to the heart of the accountability issue is that in a command and control culture, "lack of accountability" is a synonym for the blame game. "It's not MY fault!" "Who was supposed to do that?" "Who is supposed to be responsible for that?" "We have to spend time proving the problem was not caused by us." When sentiments like that frequently arise during my interactions at an organization, it's a huge indicator of a problem. I also see an indicator of this issue in role confusion and the frequent ask for a RACI (Responsible, Accountable, Consulted, Informed) diagram to further pinpoint where every function of a role fits.
Does it REALLY matter who needs to do every little thing? Or is it more important for those things just to get done? Sure, people need to have accountability for their responsibilities but when everything down to the smallest task needs to be assigned out, we are essentially micromanaging ourselves and that is defeating a main purpose and benefit of self-organizing teams (at all levels of management).
Yes, our people do need to be accountable, but they need to be accountable to each other before they can be accountable as a team. We must believe that the people we work with are driven by motivations for their work, want to succeed, and are working under the Prime Directive:
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." -Norm Kerth, Project Retrospectives: A Handbook for Team Review
Organizations Can Unknowingly Sabotage Trust
One way management often hinders teams in forming trust is by frequently changing their members around, thus causing them to have to re-form relationships. How can we expect people to be accountable to people they have never worked with before and immediately deliver on everything that is expected of them? Those are unfair expectations and teams are at a disadvantage from their inception (which repeats every time a member is relocated).
Another way trust is hindered is lack of involvement in the actual plan that the accountability is perceived to be lacking on. A key piece of information I've taken out of graduate change management classes is that we need to invite people to the change and invite them to be a part of the solution. Agile trainings have missed this point at times when discussing product ownership and product management. Those roles have the final priority win - every time - but if they are not collaborating and involving the people doing the work they are more likely to get it wrong. Priorities will lean toward subjective over objective and as a result the team will not be as invested, committed, accountable to the plan because they have less trust for it (and it's likely worse for the customer, too).
Organizations that do not include the necessary players' input in forming plans often face constant change and churn of that plan. Team players are not only development teams but the teams that help to prepare the work for them to develop. Often management teams spend much time delegating to the teams they lead, but it's the teams they are a part of who cause the majority of the politics and conflict in consistently and rapidly changing priorities for the teams they lead.
Changing a plan is not bad, but the excuses and frequency often are and the implications turn to distrust in the organization and management. The shifts organizations feel they need to make are driven more by internal politics than market need. We think our organizations need to be able to shift priorities any and all the time if necessary; we're "agile" after all, right? That is NOT what "being agile" means. This is not pivoting relentlessly, it's pivoting recklessly. If leadership/management teams cannot commit and be accountable to a plan for a short period of time (and a quarter is short in context), how can we expect the teams we lead to commit to the plans? The development teams pay the price for not delivering on something that is far from certainty because it's often viewed as lack of accountability to a plan they weren't trusted advisors in.
Accountability was never the problem; trust and inclusion are what translate to true commitment and conviction. Until we solve those problems at all levels of the organization, we will always wrongly see accountability as the issue and chase relentlessly after a symptom while ignoring the root of the problem.
Published at DZone with permission of Natalie Warnert , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.