The frustration in the room was palpable. Everyone agreed we weren't getting what we needed from the team: we had no clear picture of what they were doing, why they were doing it, and now we were being told with only a few weeks to go that the timeframes we were relying on were not likely to be achieved. The engineering managers, heads of design and product managers were all visibly exasperated.
"I need our teams to be accountable!", your manager insists: the frustrated strain in his words almost visibly hanging in the air. "We're finding out about problems too late and our teams have almost no visibility of how they're tracking". It was pretty clear to everyone that whatever we were doing now, it wasn't working. Our agile teams weren't accountable: they had taken the idea of being self-organising and become insular, protective and opaque. What was clearly needed here was a reminder about accountability! We workshopped a RACI matrix that had all the roles or functions within the wider agile landscape and put the 'A', 'R', 'C' or 'I' under each one. Now it would be clear for everyone.
I look back on this conversation and workshop and wonder why its taken so long to arrive at the conclusion that we failed our teams at the management level. There are multiple problems here to be sure, but the first one starts with accountability. It's an expectation managers and teams are presented with all the time, but what is "accountability" and what does it look like in practice?
Accountable is a terrible word
I have a love/hate relationship with the word 'accountability' these days. It's a necessary thing, and even a good thing at that. But it's also a very wide net of a word, capable of some very heavy lifting. That's where we went wrong as a leadership team: we all nodded and agreed our teams needed to be more accountable without examining what that accountability actually looked like or whether that's what we truly wanted at all. Saying "be more accountable" puts the onus on the other party to measure up without really having to explain the relationship in more detail.
I eventually went back to the large spreadsheet of a RACI matrix with the intention of taking a hammer to the whole thing. I wanted to rework it so that it related explicitly to the agile team we were trying to guide, and I decided that the outcomes we needed accountability around were the agile / devops process they owned. I refined the full page sheet of rows and columns down to 8 rows and around 6 - 7 columns, then added my best approximation of who was accountable in each area: planning, build, testing, deployment, monitoring... that sort of thing. Except now it was even harder! How the hell was it so difficult to decide which individual or role was supposed to be accountable for outcomes specifically related to agile teams?! It was that damn word again: "accountable". It implies a single person who answers for the decision or result, right? You can't have more than one person accountable, was what I was always taught. Yet agile teams are supposed to be collectively accountable for their results.
"Accountable" is a terrible word. It sounds like 'empowered' but implies 'blame'. "Answerable" is another synonym I see used in efforts to distinguish between responsbility, or simply "you are the one person who is required to be capable of giving an account of the decisions". Accountability is a reasonable expectation, it's just that in our case accountability wasn't the problem. Predictability, transparency and confidence were.
The problem our leadership group was having was not a lack of accountability from our teams (although it certainly looked like that to us). It was that we had set very loose parameters of what was needed, which was coupled with a lack of visibility of the work, which then led to a lack of predictability of the work, which in turn led to a lack of confidence of delivery from our teams within the constraints we had assumed.
Agile infers collective accountability
Agile teams need to be seen as a single entity, collectively owning the outcomes and decisions they make. As managers, assigning individual accountabilities to roles within the agile team effectively turns the relationship into one of command and control, where each role is being directed to be singularly answerable to the manager or other stakeholders. In trying to go down the route of picking roles to be accountable for each bit of the delivery process, things got very tricky very quickly. It's just not a practical exercise. Could it be done? Sure, probably. Is it a contrived problem with at least as many negative outcomes as productive ones? Definitely. Accountability is an abstraction of more concrete problems.
The three faces of accountability
Accountability is actually three gnomes in a trenchcoat. It's a proxy for visibility of progress towards commitments, predictability of an outcome, and confidence that the outcome will meet the requirements that were agreed at the start.
Visibility
Visibility starts with having a clear goal or outcome stated at the start: "We need to find a way to make this widget keep track of the items the customer has marked as a favourite so that they're able to refer back to the full list later". From there, we chunk up the work, size it all up in days, effort, story points, whatever. Then we have some way to show how each of those chunks are progressing so that people who rely on the result can see without having to ask for regular updates.
Predictability
Predictability flows from the previous tenet. If people can see a team's work in progress and it's clear at a glance how much of the larger goal is complete (and how much still remains to be done), then it's much easier to extrapolate how much time is likely to be needed. If there are blockages, risks or unplanned interruptions, the team communicates with its immediate stakeholders early to make them aware and reach a decision about how to handle the impediment; whether that's to persevere, work around it or stop work and pick up a higher priority instead.
Predictability isn't about crunch time and burnout in pursuit of an arbitrary deadline. It's about ensuring people who rely on a result being delivered know what the expected result is going to look like and how much more time is required before completion.
Confidence
Visibility of work and predictability of results yields confidence in the team's ability to achieve the agreed goal. Confidence in the team allows management to step back and let the team do what it does best: deliver great results. Confidence from management leads to mutual trust.
Accountable at last!
With the team making an effort to size up the tasks clearly and sustainably, while using the planning and collaboration tools in place within the organisation, managers could see that things were getting progressed more reliably and they understood what would be delivered in the agreed timeframe. "Finally! Some accountability"