The Real Issue
When you think about Agile, you probably think about backlogs and sprints and requirements and acceptance criteria and so on. Let’s start this discussion by outlining the fundamental item that is usually missing: Accountability. I will let you debate why this is missing , but you can read my thoughts about it in this article.
Accountability and Agile… Do They Play Well Together?
I have been a part of many talks about accountability with various customers and managers, and I have consistently heard the same concern from just about everyone. “This is Agile. It is based on self-organization and collaboration.” In other words, it is not their place to tell the team how to do their job. So management is often left with no “requirements” to use for holding the team accountable. So how does management deal with accountability in an Agile environment?
The truth is that Agile does NOT preclude accountability. In fact, it provides all the methodologies needed to deal with it. For instance, the purpose of a sprint retrospective is to self-evaluate what went wrong and fix it. Likewise, agile supports working agreements where the teams define how they will work. Here are a few articles talking about Agile and accountability. They are well worth reading.
- Is Agile Accountability an Oxymoron? (from agilealliance.org)
- Accountability is a Quality of Agile (from scrum.org)
- It’s Not Agile’s Fault (from nextgov.com)
- Definition of Sprint Retrospective
How do we measure accountability and how does the team improve?
The authors of the above articles do a better job of explaining why Accountability is not only OK with Agile, but also actually required. Below are a few examples of how to “measure” the team members’ requirements (in other words, what are they accountable for).
Single Source of Truth – When a team “agrees” to a way of doing something, they should put it in the WIKI. The accountability is defined right there.
- Processes and Working Agreements need to go in here. They do not need to be extensive, but they need to clearly define basic expectations etc.
- Architecture and shared resources need to be kept up to date here.
Post-Mortems – Here we can use the findings from any outage or other production issue to add to our team’s working agreements and processes.
Sprint Retrospectives – Have regular retrospectives, and use them to review the working agreements and where we fell short.
Use the tools – ADO offers several tools designed to help the team.
- story sizing and burn-down rates to see how effective developers are.
- Task hours to make capacity planning easier.
- Developer availability to account for non-workable hours (senior devs who must spend a lot of time approving PRs should lower their working hours to account for that time).
- Bug reviews that allow developers to learn from their mistakes.
- Static Code Analysis tools to create gated check-ins (You can’t check in your code if it doesn’t meet these requirements).