Our TeamContactGlossary

Agile Accountability: It's Not What You Think

By Miranda Dulin
Published in Agile Mindset
May 14, 2022
8 min read
Agile Accountability: It's Not What You Think

Do others demand your team be more accountable? Are the phrases “held accountable” and “future prevention” used as hammers? Escape the cycle of blame.

Definition of Accountability

Before discussing accountability, we need to agree on a definition, which isn’t as easy as it sounds.

Merriam-Webster defines accountability as “the quality or state of being accountable” and adds, especially “an obligation or willingness to accept responsibility or to account for one’s actions.”

Well, now I have more questions than I did before. What is accountable, and what is responsibility? I’ve used these words my whole life, and you probably have as well, but that doesn’t mean that we understand them.

As it turns out, accountable has two definitions:

1. : subject to giving an account: ANSWERABLE

2. : capable of being explained: EXPLAINABLE

Well, that isn’t how I’ve used it all my life. When I say (typically in anger), “She needs to be held accountable,” I don’t mean that she only needs to explain what happened. I want her to hang. This desire, however, isn’t accountability; it’s punishment.

The actual definition of accountable aligns with what I know about accounting as a profession, and it makes sense that these two words would share similar connotations.

“Accounting is the process of recording financial transactions pertaining to a business. The accounting process includes summarizing, analyzing, and reporting these transactions to oversight agencies, regulators, and tax collection entities. The financial statements used in accounting are a concise summary of financial transactions over an accounting period, summarizing a company’s operations, financial position, and cash flows.”


If proper accountability is about explaining how we got where we are, what is responsibility?

Responsible vs. Accountable

There are several definitions of responsible that are applicable:

  1. liable to be called on to answer

  2. liable to be called to account as the primary cause, motive, or agent

  3. able to answer for one’s conduct and obligations: TRUSTWORTHY

  4. able to choose for oneself between right and wrong

So, responsibility is the ability to choose the appropriate next action and the obligation to give an account. I am free to determine how to accomplish a task, but I need to be prepared to explain my decisions.

Do What You Say You’ll Do

Even within the agile community, we commonly misunderstand the idea of accountability as “doing what you say you’ll do.” In one podcast, Alicia McLain defines accountability as a do/say ratio. I’ve worked with other leaders who characterize accountability in this same way.

It’s funny how close this interpretation is to the actual definition of predictability:

  1. capable of being predicted: able to be known, seen, or declared in advance

  2. behaving in a way that is expected

Predictability is also an accepted agile metric that is measured like the false definition of accountability suggests.

Two predictability charts showing planned vs done and ratio in a target range

Some leaders are uncomfortable referring to “doing what you said you’d do” as predictability because it seems absurd to reprimand someone for not accurately predicting the future. On the other hand, accountability sounds like a quality that all professionals should possess.

If I were the type of person who was big on command and control leadership, my desire for command might lead me to use “accountability” as a hammer to beat people into shape. Are things not going the way I want? Am I put into awkward situations with stakeholders about our inability to deliver? I don’t have time to determine the root cause, but it must be a lack of accountability. The development team just isn’t trying hard enough.

I don’t mean to imply that we shouldn’t strive to do what we said we’d do; we absolutely should (assuming our plan is still valid).

I can only imagine what would happen if my husband handed me our rent money and asked me to pay the rent, and instead, I returned with a new pair of shoes. He would hold me to account for my actions. I would have to explain how I left intending to pay rent and returned sans receipt.

If he weren’t satisfied with my account, there would be consequences. Most likely, I’d be forfeiting my margarita money to cover the rent. I might hang from my new shoelaces if he sought punishment instead of accountability.

Agile teams are motivated in the same way to do what they say they’ll do. Peer pressure kicks in, and no one wants to feel like they’ve failed in front of their peers. However, as rational beings, we must admit it is not always possible to execute according to plan.

Knowledge based work involves uncertainty. If I don’t do what I said I’d do, that shouldn’t instantly brand me as a failure. Given the imprecise nature of estimates, we must allow for unpredictability.

Who’s to Blame?

Take a moment to consider past discussions regarding accountability. What percentage of those times focused more on blame or punishment instead of accountability? Is it 50%? 60%? 80%?

I propose that this approach is entirely the wrong mindset. Instead of assuming we have a people problem, let’s shift our thinking toward our process. How can we tweak our process so that the unintended situation is less likely to happen in the future?

Assigning blame creates an adversarial environment, even when you attempt to shroud your intentions in the cloak of process improvement.

Suppose my husband gets stranded at Walmart with a car that won’t start. I agree to come to pick him up, and he asks how long it will take me to get there. We live close by, so I say five minutes. I leave the house and immediately get stuck behind a 6-car pile-up that will take three hours for emergency crews to clear.

When I finally show up at Walmart, my husband waits there with his lawyer and divorce papers.

Legal document on a desk next to wedding rings and pen
Divorce seems like an overreaction to a three-hour and five-minute wait, but my husband thought it was important that I do what I said I would do.

If my husband were more reasonable, he might call me to account for my actions, and I’d explain how I became stuck in traffic. He’d ask why I didn’t call to let him know. Perhaps my phone was dead or forgotten at home. Or maybe I was so dreading his wrath that I was focusing on any other way I could possibly make it to Walmart in five minutes, and I didn’t think to call.

Accountability conversations help to build a shared understanding between my husband and me. Being transparent with my decisions helps him learn how I think and helps me understand his expectations.

We may agree that anytime one of us will be more than five minutes late, we call to let the other know. That’s a simple process change that isn’t hard to implement and would have avoided all the drama.

If I repeatedly make decisions that don’t align with his expectations and fail to sway his point of view, perhaps my heart-mate will eventually divorce me. If we cannot reach a shared understanding, divorce isn’t a terrible course of action. Some personal relationships are incompatible, and the same can be valid for professional associations.

Infographic of six unfortunate events

Things are not always predictable, especially in a complex environment. Decisions do not always have easy or even good answers. Sometimes we’re choosing between the lesser of two evils. If the development team’s account is logical and within expectations - what blame is there to take?

Accountability in Agile

In an agile environment, what can we do to increase accountability? We need to be prepared to report on the decisions that have led us to our current situation.

Team Accountability

With agile approaches to software development, we move away from individual accountability. Instead, we depend on cross-functional collaboration to accomplish our goal.

As a team member, I need to communicate when I need help. If I fail to accomplish my task, the entire team fails. I should also be listening in the daily stand-up for people who need help, even if they fail to request it directly.

I prefer to focus on building empowered teams instead of rewarding individual heroism.

Increase Transparency

End users are removed from the effort that goes into building software. It’s uncommon for a customer to understand the complexities of the technical implementation. Therefore, when we track work at a portfolio or program level, we tend to summarize significant amounts of effort as a single-line summary on a spreadsheet.

Tracking progress in this way creates a the appearance that a straightforward task is taking a very long time to complete. When your professional life consists of scratching to-dos off a list between meetings, it can be difficult not to assume everyone else’s work is similar.

Imagine if you were to receive an invoice for some home repairs that listed a single generic line item with a cost of $15,000. Would you feel comfortable paying that bill? Contrast that with an invoice that details the exact materials used and hours worked each day during the project? I bet you’d feel more confident signing a check for the second invoice.

Woman's hand hovering over calculator next to stack of invoices
Would you trust an invoice that listed "Did Stuff" as a single item and demanded you pay $15,000?

I’m not suggesting that we track all work at an individual task level, but neither should we represent an eight-month initiative as a single line on a report. We need to balance our need for efficiency with transparency if we wish to have a realistic understanding of what’s happening on our teams.

Demonstrate Progress

Once we’ve broken our work down into manageable bites, we need a way to communicate our progress to stakeholders. A Scrum team will do this via the Sprint Review meeting, and a Kanban team might do this via the Kanban Board.

Two too happy kids in backseat of SUV look out the back hatch packed with suitcases
Constanly requesting status updates for work in progress reminds me of every family vacation where the kids are asking, "Are we there yet?".

Whatever the mechanism, we should keep stakeholders apprised of our progress. We should strive to provide tools or communication that make sense in our environment to prevent the need for them to ask, “Are we there yet?”  

Increase Predictability

Almost everytime I’ve heard anyone start bandying about the term “accountability,” they were actually talking about predictability. They weren’t after an accounting of events; they wanted us to hit a deadline.

Who doesn’t want to say this was the plan, and that’s precisely what we did? Everyone wants a successful delivery. However, we need to be open and respectful enough to recognize that this goal isn’t always attainable.

If I’m going to be accountable, it’s in my best interest to be more predictable. I’d be more comfortable explaining our decisions if those decisions led us to meet our goal 80% of the time. If we’re only hitting our goal 10% of the time, no one will be thrilled, and it will be hard not to feel like failures.

If predictability is a ratio between planned and completed work, there are only two ways to increase predictability, and we can either decrease planned work or increase the delivered work. 

Decreasing what we plan means saying no to lower priority work so that we can focus on finishing higher priority work.

Increasing delivered work means hiring more people or tweaking our processes to boost efficiency.

Relentless Improvement

Regardless of the agile approach used, some common red flags signify a lack of predictability that we should be sure to address.

In Scrum, the Sprint Retrospective should deal with any carry-over from Sprint to Sprint. In Kanban, we should take steps to rectify erratic variability in cycle time. Whatever your approach, identify the indicators to watch for and ensure your team discusses them regularly.

Allowing these smells to continue unexamined can create a negative feedback loop that keeps the team in a perpetual state of funky. Mark Manson discusses the feedback loop from hell in his book The Subtle Art of Not Giving a F*ck.

“You’re so worried about doing the right thing all the time that you become worried about how much you’re worrying. Or you feel so guilty for every mistake you make that you begin to feel guilty about how guilty you’re feeling. Or you get sad and alone so often that it makes you feel even more sad and alone just thinking about it. Welcome to the feedback loop from hell.”

-Mark Manson

Teams should focus on relentless improvement. Do we have an issue? Let’s solve it and move on.

Works Consulted


The cycle of blame can be escaped by coaching colleagues on the true meaning of accountability. Accountability is the willingness to be transparent about how we reach a point. It’s not about blame; it’s about knowledge. It’s not about guilt, punishment, or doing what we said we’d do. Improving predictability is a better expenditure of effort than identifying a throat to choke.


Previous Article
Agile Vertical Slicing: The Cake is a Lie
Miranda Dulin

Miranda Dulin

Scrum Master

Table Of Contents

Definition of Accountability
Responsible vs. Accountable
Do What You Say You'll Do
Who's to Blame?
Accountability in Agile
Works Consulted

Buy Me a Coffee

Are you gaining value and insights from Agile Ambition? If you love what you're learning and want to see more, here's a simple way to show your support. Click the "Buy Me a Coffee" button to make a small donation. Each coffee you buy fuels our journey to discover better ways of working by unpuzzling Agile, one piece at a time.

Buy Me a Coffee

Related Posts

What Emerges From Self-Organizing Teams
February 24, 2024
3 min
© 2024, All Rights Reserved.
As an Amazon Associate I earn from qualifying purchases.

Quick Links

Contact Us

Social Media