The Circle of Safety: Transition to Empowered

Background

In working to transition a traditional development organisation ot an empowered one, I have realised that most material widely available describe the end state. They describe, very clearly, what an organisation made up of empowered team looks like and the massive benefits they yield.

Unfortunately, we are all human, and simply describing an end state is very seldom enough for a large group of people to over-night change their way of working.

In this article, I propose a transitional organisation that allows teams to grow into fully empowered agile teams without too much frustration along the way.

What does this transition organisation look like?

In a traditional organisation the manager is the single formal point of contact between the rest of the organisation and the team.  This is not the case for agile empowered teams where there is no team manager and the individuals represent the team in a variety of contexts.

With all these different individuals representing the team, it is really important that they all act as ambassadors of the team as a whole, or else the communication and trust between the team and the rest of the organisation will disintegrate rapidly. This means that the team has to have matured to at least the third level of Susan Whelan’s integrated model of group development . A team which has not reached that level of maturity simply does not have the capacity to present the necessary unified front.

To start with, most things will work like in traditional Scrum. Below, I list differences between, or clarifications to, the proposed transition organisation and a textbook Scrum organisation.

The Product Owner

The first difference is that the Product Owner becomes the single formal point of contact for the rest of the organisation and has the overarching responsibility for the entire team. The Product owner has these specific tasks that are not strictly articulated in traditional Scrum:

The first task is to ensure that the team gets the proper input it needs, mainly consisting of the goals that the team shall achieve. However, this also includes providing access to stakeholders and end users in order to be able to get nuanced enough information to be able to achieve those goals.

The second task is to ensure that the discovery phase happens completely inside the team, as opposed to having a list of pre-scoped tasks that the team shall compete. If the discovery work is not happening fully inside the team, then the team has no choice but to remain a feature factory.

The third task is to ensure that deliveries created by the team are properly delivered to end users and results are properly communicated to stakeholders.

These three tasks shield the team from outside disturbances and confusion, allowing the team to mature in a safe space. This safe space is what we call “The Circle of Safety”. By giving the Product owner control of the entire interface between the group and the outside world, the Product Owners are in a position to be fairly held accountable for the work done by the team.

To be clear, I am not saying that the Circle of Safety shall become some form of a no-go-zone. Any team member may still communicate with any other person in the organisation. And anyone else in the organisation may talk to anyone in the team. However, there shall exist absolute and total clarity in that the team members can redirect any requests that they feel disturb their work to the product owner. In addition, the product owner shall be aware of all major communication between team members and the outside world to ensure that this communication is for the benefit of both the team and the organisation as a whole.

All said, this role looks very similar to that of a manager in a traditional organisation when seen from outside the team. This is intentional, as the rest of the organisation can interact with the product owner just like they would with a traditional manager.

In this model, the product owner is also responsible for the team happiness, something that otherwise typically falls on the Scrum Master. Since the product owner is given very large power over the team, including handling all input and output, this makes sense.

The Scrum Master

Since the product owner takes on such a large role, one might wonder if the Scrum Masters are needed at all in this organisation. They are. They are the ones that ensure that this transition organisation actually transitions to empowered agile teams and rather than just remain as a traditional teams but with different titles.

The Scrum masters role is to work inside this circle of safety and ensure the team matures in both productivity and in-team interactions.

Their first task is to ensure that each individual rapidly improves in all of the skills needed to shoulder the full responsibilities of a high performance agile team (e.g. Automation of tests and delivery, Architecture, Clean Code, and Innovative Discovery)

Their second task is to work actively with the team and the Product Owner to ensure the team maturity increases. This involves building trust and resolving conflicts between all team members including the Product Owner. To start with, this will require a lot of workshop sessions and detailed instructions, as the team members will not used to the new way of working and the team generally having a lower maturity in the internal interactions.

The third task is to work to become redundant. A Scrum Master shall look at every activity they do with a critical eye. They shall think about how increasing the teams maturity can make the activity in question redundant. The parent of a friend once told me that “The best Scrum Masters just make coffee”.

The team members

The team members also work inside the Circle of Safety. Their job is to get the necessary skills and interaction maturity so that they can step out of this Circle of Safety as soon as possible.

Their first task is to get good at doing realistic and thorough analysis of work to be started. This will allow them to give realistic estimates on when they can deliver. By committing and then delivering on those commitments, the team builds trust with the rest of the organisation.

The second task is to never deliver a product that does not conform to the minimum standards set by the company, both from an architecture, coding, design, and usability perspective. In this task, we also include mastering the hands-on skills needed to be productive, e.g. Architecture, Automation of tests and delivery, and Clean Code.

The third task is to take an active interest in the discovery of new solutions. This means being a driving participant already from the early stages of an idea, long before any concrete features are even defined. Even at this early stage, the team members shall provide rough cost estimates and provide creative ideas that provide similar value but at a fraction of the cost.

The fourth task is to actively work with the other team members to form robust relationships. The end goal is that a third party coordinator and conflict resolver (i.e. the Scrum Master) shall no longer necessary in daily work.

The fifth task is to creatively and critically evaluate their own work and proposing actionable changes that will have a real impact on the team’s effectiveness.

The Manager

The manager has the overarching responsibility for the individual team member.

The managers job is to ensure that the individual team members in fact perform their tasks as stated above and that any impediments they or the Scrum master raise are removed.

What do I hope to achieve with this organisation?

This organisation allows for a completely fresh team with no experience of working in an empowered agile way to start delivering value immediately. The rest of the organisation can also treat this team as a traditional team for almost all intents and purposes. The Product Owner and Scrum Master together forming the role of a traditional manager building up the team.

If each part of the team takes responsibility for the tasks articulated here, my experience says that it will put the team on a well-defined path to grow into an empowered team. Once the team has proven to itself and the rest of the organisation that they are mature enough, then the Circle of Safety can be removed and the team can interact with the rest of the organisation as a cohesive and effective unit.