What is Accountability?
From the Cambridge Dictionary we have this description:
‘the fact of being responsible for what you do and able to give a satisfactory reason for it, or the degree to which this happens’
This definition is particularly relevant too Agile in that defines responsibility but combines providing evidence (satisfactory reason) so that we can more easily define both the who and what with respect to accountability.
When talking about accountability in the context of Agile we also need to address responsibility. In Agile your software development teams need to be accountable for work that they do, with respect to planning, execution and quality. But they also have a shared responsibility to be accountable. This is where the concept of self-organizing comes into play with Agile.
Frameworks and Accountability
One of the outcomes of the Agile Manifesto was a movement towards creating frameworks or methodologies that would help people be able to implement an Agile.
Search through the web and you will see people consistently telling you that ‘x’ framework does not make you agile and to a large degree that is true. Doing Scrum in fact does not make you Agile. Changing your organization to support how Agile planning and Scrum operate will.
Agile requires that you have a much more engaged approach to planning and execution.
In Waterfall you ask your business unit leaders to create a bunch of projects that will be funded for the next fiscal year. Leadership engagement is actually light in this model, they expect that their leaders to be building the right things to deliver value and as the year unfolds their PMO provides regular status updates on the progress of these efforts.
Even worse in this scenario is that you have a fixed set of people who are spread across multiple projects and your project managers main job is to fight to ensure that their ‘resources’ are working on their project.
So it should not come as a surprise that your projects are often deliver less than originally planned or have cost overruns.
Accountability is hard to pin down and the project manager, the one person who does zero work to deliver software is typically looked as the person who is accountable for the success of their projects.
With Agile we build in accountability by fundamentally changing both the structure and funding of our project teams. Gone are the days of yearly funding, instead having a funded long standing team.
We build accountability via the familiarity that these teams build within themselves. Running a waterfall organization is equivalent to asking a baseball manager to create a new team every day with different people but get to the World Series every year.
In almost every sports setting you can find situations where the most ‘talented’ team doesn’t win, instead the team that worked together, through their weaknesses and supported each other win the title. High performing teams are a by-product of people working together to raise each other up.
If you have selected Scrum as a primary framework (and most organizations have) for your Transformation, then you have gone through the process creating static teams. You have also identified a Product Owner and either added a full-time Scrum Master or have someone one the team play the role of Scrum Master.
Before we get deeper in the Accountability Pillar let’s review some of the most popular Agile frameworks:
Probably the most popular framework that is used today, Scrum is both successful and mis-understood. At its heart is a way for a single small team to plan and execute work in short increments, providing an ability for the organization to respond to what they are building and in theory make changes in scope and direction of a project as it unfolds. In reality many organizations implement Scrum within the context of a fixed scope project environment.
Scrum has a set of prescribed roles that are involved in the planning and execution of work that comes out of the Product backlog.
Often the methodology that Agilists will suggest you start your Agile journey with. The key benefit is that it allows you to take your existing processes and model them into a continuous flow of work that is visualized via a Kanban board that provides high visibility regarding the quality of that workflow. Kanban will provide you evidence of where your inefficiencies are providing you the opportunity to improve them.
A derivative of Scrum and Kanban is what is called ScrumBan. This framework brings together lightweight planning from Scrum, without the dedicated roles prescribed by Scrum, with the continuous flow that Kanban provides.
4. Scaled Agile Framework
SAFe, as with LeSS, attempts to address how organizations can implement Agile frameworks at larger levels of scale. Unlike LeSS which essentially has a single way of delivering product software, SAFe has several different levels that can be applied based upon the size and need of the organization. One of the challenges I’ve seen with organizations is that they:
Are too small to apply SAFe – Organizations with less than 10 teams probably don’t require the heavy weight that SAFe can imply.
2. Don’t apply SAFe across the organization – At many organizations I’ve coached at (>400 individual teams) where there are many different business units, the implementation of SAFe is localized to each of those units, meaning your SAFe implementation is uneven at best and does not take advantage of the potential benefits you can obtain with some of the discipline.
Scrum and Accountability
Scrum, with its smaller product backlog and short delivery increments (Sprints) provides for accountability within the context of their ceremonies:
· Planning – As with all of Agile we are in a constant state of planning. In fact you will be doing significantly more planning with Agile than you ever did in Waterfall. Scrum features two primary planning activities, Backlog grooming and Sprint Planning. These two planning sessions focus on the planning and delivery of small features that could be potentially delivered to Production at the end of that individual Sprint. Teams are accountable for the successful planning of what work can be completed in their Sprint.
· Stand Up – This part of the Scrum ceremony is a daily check with the team, not a status update, for them to confirm that the work that they planned to do is still on track to be completed. This ceremony forms the foundation for their accountability, they are in essence making a commitment to their Product Owner (who is the business representative) that they will get this work completed.
· Sprint Demo – This ceremony provides the team an ability to show the work that they did in that sprint to their Product Owner as evidence of their effort, this is the second part of accountability with Scrum.
· Retrospective – This final piece of Scrum ties in the Inspect and Adapt processes of Deming and provides the team an ability to reflect on their most recent sprint and address issues that kept them from meeting their plan. This is the final pillar of accountability with Scrum.
Kanban/Scrumban and Accountability
Kanban with its focus on flow doesn’t have the same type of Accountability from a planning perspective that Scrum does but what it does provide is a clear view to how work flows through your teams.
Kanban provides accountability by making work Transparent and then providing evidence that there is a consistent flow of work through the organization.
Most Kanban teams don’t require a role such as the Product Owner to prioritize work because the expectation is that the priorities are self-evident and the people on the team have all have most of the skill sets to do the work.
Accountability then is wrapped in the clarity of the amount of completed work. Kanban can visualize the state of the teams work. For example if you see that most of the work is marked as In-Progress, you know that they aren’t actually working on everything at once so it’s virtually impossible to know when anything will be Done.
We address this by putting in place Work In Progress (or WIP) limits for each individual on the team. Accountability is then derived by viewing how much work is in progress, and how much work is cumulative flowing through the team. It’s very easy to see both who is doing what work and what they are being blocked by.
As a manager your focus will be on removing organizational impediments that are blocking the team. An easy example is a team that perform client on-boarding work where they require information from the client. With a blocked state called ‘Waiting on Client’ you can visualize how much of your teams work is impacted by delays in customer communication.