7 practical steps to increase accountability in agile teams
At the points in my career that I have seen senior management push back on the adoption of agile methodologies, the main areas of contention has been around the feeling of losing “control” over the delivery roadmap.
Agile methodologies accept and embrace the fact that the “control” of the future is illusionary, based on the fact that we are poor predictors of future events and that communication is never perfect.
Along the same lines, it’s very easy to understand how to apply accountability in a waterfall model – “You are accountable for delivering all the written requirements by the agreed time.”… Easy.
This, of course, ignores whether the written requirements are actually valuable if delivered at the agreed time. It ignores that the requirements are likely to be imperfect, incomplete or that any (inevitable) change will happen. It ignores that the work involved in delivering the features must be an estimate, an educated guess, an unreliable prediction, and the cost incurred by pretending that it’s not.
… But it’s so easy… And I, as a busy senior manager, can stop spending time thinking about the project after it’s kicked off all the way up until it’s delivered, I don’t have to learn or understand the implications of change, I can look even further forward now that I know what’s coming – I feel that we have established control over the future and that makes it easier to sleep at night.
It’s no big stretch to see why these beliefs are so seductive.
So how do I sleep at night and free up more time as a senior manager in an Agile environment? How do I ensure that my teams are accountable for delivering the maximum value for the business if we don’t have a big requirements sign off and plan of record?
The good news is that accountability is not only achievable, but likely to deliver far better results than plan-of-record style accountability, if you put the right framework in place. Here are techniques and approaches that I have found to be successful at various levels of the business.
Utilise OKRs
Make the goal measurable. OKRs provide a framework for empowering teams, unleashing creativity and ensuring accountability. OKRs are outcome focused, not output focussed like a requirements document and a plan of record. The Key Results are your metrics for monitoring the progress of your teams on achieving the outcomes. With the right OKRs there’s no room for dropping quality to achieve output deadlines, or political manoeuvring to make something sound more successful than it really was. Keep your teams accountable while adding measurable business value.
Ensure Continuous Delivery
If you hear a contention like
“I worked with a team that ran agile and another that ran waterfall. The agile team were engaged and creative but never delivered anything. The waterfall team delivered.”
Then the agile teams in that scenario were not running continuous delivery. It is certainly true that if a team doesn’t deliver anything then it is producing no value. In fairness, I have seen this happen and it can lead to teams that live in the ‘comfort zone’, there’s an overly relaxed attitude and lack of accountability hiding behind a façade of agile reasoning.
As a delivery manager, make sure your top priority is getting automated deliverable product happening as regularly as possible. Even if it doesn’t end up in customers hands every time use it to prove to yourself, and any internal stakeholders, that value is being added. In addition you provide opportunities to gather feedback and change direction, all based on working software, not reports.
Facilitate Close Customer Contact
Nothing keeps a team feeling more accountable than regular, direct customer contact. Caution is needed if this is introduced to a team unfamiliar with talking directly to customers, choose your participants wisely and offer coaching and support.
Once a team is successfully engaged in direct communication with customers, the waste generated by layers of indirection and the risk of personal agendas being injected along the way is dramatically reduced. Everyone’s happier that they’re not spending time on unwanted or unexplained work and a focus on direct value delivery drives accountability.
Enable Component Ownership
This aspect of ensuring accountability requires that the product architecture, supporting frameworks and team composition are coordinated to allow it, but the benefits are manifold.
Accountability sits proudly among the benefits, as a team that owns a component from cradle to grave naturally are accountable for the performance of that component.
Promote Pairing
Looking closer at the hands-on work – pairing can be an extremely effective accountability measure, both in terms of ensuring good practice and consistent focus. Be sure to keep the pairings fresh to ensure learning is maximised and pairs aren’t stagnating.
Full-time pairing can be mentally exhausting when first introduced, it’s worth considering how this approach could be trialled initially with a roll out over time.
Some members, or entire teams, may push back on this approach, in which case, consider it an opportunity for a discussion on what team members do to hold each other to account and ideas build on that.
Hire for accountability
Skills can be taught, personality traits like accountability are what set candidates apart. Accountability is born from a feeling of extreme ownership. Asking simple questions like “Do you take accountability for your work?” is obviously only going to get one answer in an interview, we need to look at more subtle ways of identifying clues.
The first thing I’d tend to look for is someone’s accountability for their own personal development. At the screening stage, look for extra curricular activity that’s in the public domain. For software engineers personal github projects and Linkedin certifications are a good place to start. Ask the candidate if they have any pet projects they want to demonstrate.
Once you at interview stage, probe on what the candidate has found to be particularly challenging in their career so far. Look for whether they accept personal responsibility for any mistakes and how comfortable they are in doing that.
To be accountable, you must be happy to take personal responsibility and have the drive to learn and improve.
Get Expectations Set Using RACI
Sometimes it’s just worth spelling it out. Using RACI can be helpful in this case.
My advice is not to try and boil the ocean with your RACI chart. Start with the big items that you think need clarifying first and keep evolving it as missing aspects are uncovered.
Like every good agile product, iterate!