Posted on

Wasn’t this meant to be about accountability?

In my last post, I covered what I see as the real definition and value of accountability within an Agile organisation. Achieving a higher level of collaboration, teamwork and focus through the ability to discuss steps taken to reach some result, the need for clear goals and measures, for transparency and feedback mechanisms. That it’s less about the aforementioned result, and more about how you got there. Most importantly, I highlighted the requirement for teams or individuals to have autonomy to make accountability a relevant and useful concept to apply beneficially in an organisation.

When I first decided to write these few posts, I had a clear-ish idea of how they would flow. The first has been posted, and wouldn’t have changed anyway. The second would then cover some methods to achieve alignment between stakeholders and teams, the benefit of meetings (who would have thought?!?) built around those methods, and the resulting confidence that the team is doing the “right” thing, by all parties – the team, it’s members, and the company.

As is wont to be the case with things at the moment however – change is on the agenda. I’m going to break things down again into some key concepts which in and of themselves will constitute and lead to further posts. So instead of a bounded series on just accountability, there will be a coherent, but mixed bag of ideas that relate back to autonomy and accountability within the organisation. For example:

Setting team goals with stakeholder buy-in

Maintaining a goal based focus during feature inception

Clear definitions of constraints and assumptions, as early as possible

Feedback mechanisms

Being able to “fail safely”

Aligned with this, I also hope to share some thoughts around leadership within this space. A lot of the ideas (such as creating an environment where teams and individuals can fail safely) overlap – and rightly so. It’s up to individuals in leadership positions, from the team level up, to change the way they think about getting things done. To foster a culture of understanding and believing we can always do things better, that we don’t know what we don’t know, and always have something to learn. To encourage the next group of leaders – to make everyone a leader.

This all comes about because I am currently in a phase of rapid learning and change at work. My role has changed, how I work has changed, what I need to be thinking about has changed. My personal accountability has changed.

And now, what I will be posting has changed. Slightly. For the better. And if it isn’t, thankfully, I can just try something different.

Posted on

Accountability?

Accountability is a term that is used often in organisations all over the world, across all manners of industry. The meaning however can be, and is, vastly different.

Over the course of several posts, I’ll attempt to define how I view accountability for an individual or a team within an Agile organisation, outline some ways to ensure the most beneficial and appropriate application of accountability between product stakeholders and a team is undertaken, and finally discuss how accountability relates to an individual within a team.

So what does it mean? To be accountable for something is having the obligation, the expectation, that you are willing and able to share, discuss and explain the actions taken to achieve some result. To openly articulate the decisions made, the consequences considered, and ultimately justify those individual actions that both were and weren’t undertaken as part of that process. Accountability has less to do with the actual result, and more to do with how you get there.

Oftentimes, it is thought of in terms of blame and punishment – this occurs where accountability is misunderstood, and applied from the paradigm of an assured result, of having a promised outcome that wasn’t completely or exactly met. In this situation, the result has not been separated from the actions that led to it – which is where real accountability should be measured.

How then should accountability be applied, and what are the benefits of espousing it as a value within your Agile team or organisation? Applied from the correct perspective, accountability should foster teamwork and collaborative effort. It should provide direction and focus, and remove the need for meeting after meeting where no real outcome or alignment is achieved.

In order for accountability to be truly effective in this manner, there are certain prerequisites that must be met. The team or individual must have the goals and what will be considered success and failure clearly defined by them, and agreed to by the stakeholders, as well as the consequences of not achieving them. They must understand how and why transparency and visibility into the progress of the team will be achieved, and how external feedback and input will be given throughout the process.

Most importantly, they need autonomy. Autonomy and accountability go hand in hand, and to desire or attempt to apply one without the other is misguided and will lead to discord and a lack of trust. A team needs the ownership and the ability to make decisions on how they are to achieve the agreed upon measures. To have this dictated to them undermines the very notion of empowerment the autonomy seeks to provide, and will ultimately lead to a lack of drive and motivation to work towards the goals of the business. Conversely, without accountability, the focus and alignment with the needs of the stakeholders and business can become unclear, and lead to the team or individual working endlessly to a solution that doesn’t satisfy any immediate need of the organisation.

Applied correctly, accountability coupled with autonomy fosters wider collaboration and an alignment between teams and the organisation’s goals, and that initiative and ingenuity are encouraged and celebrated in achieving them.