Posted on

What could possibly go wrong?

What could possibly go wrong?

This has been for quite a while now, one of my favourite aphorisms. It entered into the common vernacular of a small group of developers who I worked very closely with, and remain great friends with to this day. Going to the Casino by Philadelphia Grand Jury would often get spun up when the turn of phrase would be especially applicable. And in the days of a rapidly growing startup, with a bunch of self assessed superfly developers on board, this was regularly the case.

I still use it to this day, with reference to any number of things, be it at work, home, or otherwise. I’ve used it as a means to display my own confidence in something – delivery and context with that meaning is important, so that those hearing it interpret it as such. However it is more often than not used with a heavy serve of cynicism, irony or sarcasm – it’s usually applied with a negative connotation, not as a positive or supporting observation. It’s used when you’re on the edge, taking a risk, or simply don’t care. None of these are especially confidence inspiring, and not something you’d therefore want to hear in your team or organisation.

I recently attended a course and the relevance of this question and how it could be used to empower and support, rather than undermine day to day and longer term decisions and actions became clear. But it needed a slight adjustment, a change in how it was phrased, and the meaning and power that it then carried was completely different.

What’s the worst that could happen?

When framed like this, and posed thoughtfully and with purpose when considering a problem, proposing a course of action, or reflecting on some personal decision, we are able to really identify the risks, what we are afraid of, and what is stopping us from taking the next step.

From a business perspective, considering this question when planning a feature can allow us to identify the major issues with the proposal, and therefore work to mitigate those risks, or remove them entirely. It may even lead to a re prioritisation of that feature all together if the answers to this question highlight major potential pitfalls. Conversely, it can validate the assumptions made throughout inception and definition, with the answers providing further evidence as to the viability and feasibility of the project. Nothing can be more reassuring than looking for the worst, and finding that it has been catered for.

Alternatively, in an environment and structure that supports and promotes the ability to “fail safely”, the question identifies those outcomes which are less desirable that should they eventuate we need to address immediately, and those which if we fail, are acceptable outcomes that we can learn from and develop ourselves or the product with respect to. I’ll cover the concept of failing safely in another post.

The question can be even more effectively applied when assessing personal risks, or perceived shortcomings when making a decision that might affect your career or personal life. You might find that when answering this question, the fear that was held was misplaced, and the results or outcomes that were stopping you from making the decision weren’t as bad as first thought, or weren’t likely to eventuate. This can often be the case when facing some question over competence, or ability to fulfil some role, and the fear of failing or the presence of imposter syndrome is holding you back from taking the next step forward. Of course, the truly self aware and honest application may raise issues that do need to be addressed before continuing, which is still a hugely beneficial result.

So I challenge you – the next time you face a personal decision or are looking at a solution to some problem, instead of simply taking the easiest or safest option, or conversely flippantly dismissing the risks, ask yourself, what’s the worst that could happen?

What’s the worst that could happen? 🙂

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.