Different cultures are not the problem. Poor team maturity is.

We all know that it is true. People from India always say yes. People from Eastern Europe always say no. The French are arrogant and a Swede cannot make a simple decision even if their life depends on it.

But wait… our close friends and long-time colleagues born and raised in these countries are not like that at all! At least that is my personal experience and what many around me have said, time and time again. So how can this be?

In this article, I will argue that the reason for this apparent contradiction is all about team and relationship maturity. And I find that team maturity is best described by Susan Wheelan’s Integrated Model of Group Development. You may know it from the phrase “Forming, Storming, Norming, Performing”.

I will argue that cultural stereotypes are highly relevant in the Forming and Storming phases, but then have very little significance in the Norming phase and almost no significance in the Performing phase.

Forming

When we first meet and interact with new people, we are in the Forming stage. In the Forming stage, humans as a rule tend to look for clear instructions for what to do and how to act. In the Forming stage, traditional politeness is our guiding star. If we see anyone in the group act out any behaviour that deviates from what we consider to be traditional politeness it immediately makes us very uncomfortable. But what we consider to be traditional politeness is by its very nature very much dependent on what culture we have been raised in.

So in this early Forming stage, we really need an experienced guide who can navigate and translate the politeness cultures of all team members. Mixing people from different cultures without a guide of this kind will definitely cause friction.

But we don’t want our teams to stay in the Forming stage, cultural differences or not, because it is not a very efficient stage to be in. We want them to reach at least the Norming, or preferably the Performing stage where the teams really start producing high-quality work. And to get there, they go through the dreaded Storming phase.

Storming

What is the Storming phase really about? Ask someone on the street and they might say that all teams descend into bitter conflicts. And that usually happens. But it is not mandatory, and even when it happens, the conflict is just a symptom.

People experienced in working with teams know that the Storming phase really is about team members putting all cards on the table to be able to agree on what rules shall apply to the team. That can happen in a shouting match, or in a calm discussion.

What we do in that shouting match, or preferably discussion, is to begin replacing the traditional politeness we have been taught while growing up with a new set cultural rules. Once we have these new cultural rules, our previous traditional politeness suddenly matters a lot less. And this is the true purpose and meaning of the Storming phase and the team can now move into the Norming phase where we see the first real uptick in productivity.

Norming

At this stage, our new team culture is still in its infancy and as anyone with experience knows, old habits will still pop back. When this happens, the team typically moves back to the Storming phase for a bit. And this can and typically will happen more than once.

But in this Norming phase, with its occasional lapses back into Storming, this infant team culture gets polished and solidified until one day it is consistent and robust. And this is the day that the team moves into that Holy Grail of all teamwork, the Performing phase.

Conclusion

So if you hear complaints about cultural stereotypes getting in the way of work, or that idea pops into your head, then you can remind yourself that the cultural stereotypes are not the problem.

The problem is that your team is not in fact a cohesive team, but simply a group of people in the early Forming stage. But the good news is that your team has not yet reached its full potential, and have a lot more to give if given proper guidance and a bit of time.

After-Works as a model for Empowered Teams

The science is clear that empowered teams are more innovative and cost less than non-empowered teams when it comes to developing products. So naturally, all product companies want to have empowered teams for their development. 

But the vast majority fail. Why?

I claim that this is because empowered teams are completely counterintuitive in a corporate context. To make things even worse, the move to empowered teams typically takes a leap of faith, where you need to decide on a completely new way of working and then just hope that it will work out automatically. See my article on the Circle of Safety for a description of a transitional organisation that makes this leap a lot shorter and less risky.

I believe that a company leader must have seen an empowered team in action, to be able to make that leap. I first met empowered teams in the Scout movement, which unlike their own marketing is first and foremost in the business of teaching people how to form empowered teams. The whole nature-thing is just a means to that end. Without that Scouting experience, I don’t imagine that I would believe in the magic of the empowered team either.

But there is one situation in a run-of-the-mill company where I have seen many empowered teams. And that is in the planning and execution of an after-work or company party. Why do I believe that this situation allows empowered teams to emerge? Here is my list:

  • Clear goal: We want a party and we want everyone to have fun. Any employee can understand the value proposition as well as the general scope limitations. The success criteria is typically not quantifiable, but still easy to agree on if it was achieved or not.
  • Freedom: Management usually does not interfere with the details, but at best indicate a date and allocate a budget. As long as the party planning committee stays within the budget and does not break any laws, no questions will be asked.
  • Engagement: Some party committees are drafted rather than volunteer, but often in a company there are some people who engage very passionately and the parties they arrange tend to live long in the collective memory.

The end result tends to be parties that are planned in a short time, use minimal budget, and are very appreciated by the intended audience. 

So the next time you tell a team what to do, mentally picture how you would approach the situation if you wanted them to arrange a company party. Because if you do, chances are that you will have cause to host a party soon enough. 

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. 

The Four Coaches

It is said that “For many reasons, Agile seems to work best when a [line manager] does not assume either the Product Owner or Scrum Master role.” But if so, then who should be that line manager?

The above quote comes from SAFe, and although the latest version of the official Scrum Guide has nothing to say about the topic, it is an often-repeated truth when talking about Scrum. But that obvious follow-up question is not discussed nearly as often. 

In this article, I want to present a thought model that clarifies the responsibilities of the line manager and helps decide who should hold that title. I will present the model, present how we use this model at Nextory today, and finally share and discuss some quotes by great Scrum thinkers on the topic

The Spotify Model

A very well-known answer to the above question is the Spotify Model. In Scrum, there are two leader-type roles, the Product Owner and the Scrum Master. Spotify has extended this model by introducing Chapters. A Chapter is a set of people with similar skills but who may be part of different agile teams. Each Chapter has a Chapter Lead who is the line manager for all members of that Chapter. This means that within a team, not everyone has the same line manager.

To repeat, in the Spotify Model, there are now three leader type roles defined:

  • The Product Owner
  • The Agile Coach / Scrum Master.
  • The Chapter Lead, who is the line manager for all members of their chapter. 

The Spotify Model, if implemented as presented, places the agile coach and the product owners at the same level as the rest of the team, which is in line with Scrum. In addition, the role of the Chapter Lead becomes a natural promotion for an expert within an area who wants to get into management. Who better to be a line manager for a group of experts than a senior expert within the same area?

Challenges with the Spotify Model

T-shaped skill profiles

“The concept of T-shaped skills [is used] to describe the abilities of persons in the workforce. The vertical bar on the letter T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one’s own.”

Software development requires people with deep knowledge of the topics worked on. But agile development works much better if the team members are also generalists. With generalist knowledge, any team member can step in to support in any activity making the team more flexible.

But cultivating this generalist skill set can become challenging when placing a group of specialists within the same field under a line manager who is typically also a specialist within that same field. Within this group, there will be a pride in being a specialist and learning new skills from other areas will not come naturally. For individuals who want to develop in a new direction with a new specialization, they also need to change their line manager which is a big deal.

The Peter Principle

Although it is not explicitly stated, the Spotify Model encourages the idea that specialists shall be promoted to line managers. But the duties of a specialist and that of a line manager are very, very different. So there is a large risk that the Peter principle will result in line managers who are not particularly good at their job..

The four coaches model

The Four Coaches model has similarities with the Spotify Model, but takes it one step further. In this model, four separate leader/coaching roles surround any given individual employee.

These leader/coach roles are:

  • The Product Owner
  • The Agile Coach / Scrum Master
  • The Senior Specialist
  • The People Manager

The difference between this model and the Spotify Model is that the Chapter Lead has been split into the Senior Specialist and the People Manager.

For completeness, here is a more in-depth description of each of these four roles in the context of this model:

The Product Owner

The Product Owner is responsible for the direction to build products that solve customers’ real problems and generate business value. Simply: What is important?

The Product Owner shall have a clear and deep understanding of how changes to the product will be received by the end user. This means that they can typically come from a customer-near background, like sales or customer support, extended with an understanding of how the product is developed.

The Agile Coach

The Agile Coach is responsible for the team and the process. Do the actions taken by the team lead to a valuable product materializing predictably and often?

The Agile Coach shall be an expert in which methods actually work to develop the product. This means that experience in development methodologies in particular is useful. They need to be experts in how to collaborate effectively, ways to have meaningful meetings, and the agile methodologies that their teams make use of. They should also have an understanding of group dynamics to help form solid teams.

The Senior Specialist

The Senior Specialist is a person who is exceptional at a skill that is critical for the organisation as a whole. Typical examples include development, testing, design, and architecture.

They are responsible for coaching and developing the organisation within their speciality. This means deepening the skill of less senior specialists within their own field, and broadening people with another speciality to help them achieve the T-shaped skill sets. The Senior Specialist may also be a team member in a Scrum Team. 

The Senior Specialist typically also has the authority to set minimum standards or define best practices within their area of expertise.

The People Manager

The people manager is responsible for the individual within the organisation. Individuals need to be welcomed when they join and given a path along which to grow. They will be part of a team, but may swap teams as the needs of the organisation changes. They may have one specialty when they join, but will need to grow both vertically and horizontally. Sometimes they want to develop a new specialty and focus on that as their primary job. They will succeed and expect recognition, be demotivated and need support, and sometimes the company will need to let them go. 

All of this is the role of the People Manager.  This person would typically be an expert in motivation, psychology and group dynamics. The natural place to look for people who are good at this is within HR. 

To make this role even more concrete, this role is responsible for:

  • Recruiting new members to the teams.
  • Removing impediments that the individual or the team they belong to cannot remove themselves.
  • Evaluating the performance of the individual and driving the subsequent promotions, compensation adjustments, or removals.
  • Holding regular informal follow-ups with the individual, e.g. a recurring 1-on-1.
  • Plan and scheduling training for the individuals.

How are we doing this at Nextory today?

So have we implemented this fully and as presented at Nextory? Does each person have a total of 4 coaches/leaders? No, we have not.

So if we have not implemented it, why talk about it? Well, this mental model allows us to clearly communicate how responsibility for each individual within the company is shared. 

We use it to check that every individual has access to each of these roles to coach and lead them.

When we want to make an organisational change, which we as a growing company do almost continuously, we can use this mode to reform a new organisation depending on the coaching/leading skill sets available and needs of any given part of the organisation. 

For some individuals and parts of the business, like our design department, the Spotify model makes perfect sense. So we merge the Senior Specialist and the people Manager into one role. In this case, our Senior Specialist in design is also the People Panager for our designers.

For many other individuals, we actually go directly against the opening quote of this article, in that they have their Scrum Master as their People Manager. Even if this goes against the well-known best practice,it has great support among those team members. They feel that the Agile Coachwho is very present in their day-to-day activities is in fact the best person to judge their performance and support them in their career growth. But the Four Coaches alerts us to the specific challenges this might pose and allows us to compensate for this.

And for many small or newly started teams, there is simply one manager who takes all of the above four roles. This is of course a very traditional hierarchy, but such a team can still fulfill all of the famous agile principles and be a great and empowered agile team. 

What does the literature say?

The model of the Four Coaches is still a very new idea, even at Nextory, and still very much based on speculation at this point. But can we find any support for this way of thinking in the writings of seasoned Agile and Scrum experts?

The conclusion is that there in fact exist some references that encourage this line of thinking. So here are three quotes from three respected sources on the topic.

SAFe

In the article “The Evolving role of managers” SAFe states the following: 

“[A]ll employees still need someone to assist them with career development. A manager still has to set and supervise expectations and compensation as well as provide the active coaching needed to advance individual skills and career goals. In other words, managers are ultimately responsible for ‘growing their people’”

I state that the manager described in this quote is very closely aligned to the People Manager role outlined above. This quote in particular, and others like it I have read formed the core inspiration when developing the four coaches model.

LeSS

LeSS has the following to say on the role of middle management

“They should help the team and the Scrum Master with removing obstacles and making improvements. 

This is in line with The Four Coaches model, where the People Manager has the greatest mandate to make broader changes in the organisation. 

“They should teach the team how to improve and solve problems.”

At the team level, I claim that this is the job of the Scrum Master. But at the individual level, the responsibility of this falls on the People Manager. But they should in turn enlist the help of an appropriate Senior Specialists or potentially even external training depending on exact improvement needed. 

“They should Go See to understand what is really going on in the place of work and see how they can best help the team improve their work.”

This would be the largest challenge for a purely non-technical People Manager. But I claim that by being at the place of work, meaning sitting next to a developer or even better next to two developers doing pair programming, can be very enlightening. No engineering skill is needed to understand the body language of frustration, and open coaching questions can quickly help articulate the exact cause. And these are the two main skills that qualify a person for taking the role of a People Manager.

Pete Deemer

Pete Deemer, famous senior development manager and “Scrum Guru” lists the following manager activities in his article “Manager 2.0: The Role of the Manager in Scrum”. I find his list to be a bit of a mash-up, but once split into three groups, some themes became apparent that are in line with the Four Coaches model. So the headings are my addition to his list.

The People Manager should:

  • Help remove blocks that the Team is not able to resolve by themselves
  • Do regular 1:1 meetings with Team-members, to provide coaching and mentoring.
  • Plan training and other skills development for Team-members
  • Plan and manage budgets and financials
  • Do performance evaluations and provide feedback to Team-members.
  • Do career-development and career planning with Team-members
  • Recruit, interview and hire new Team-members
  • Remove Team-members who are not able to perform well within the Team

The Senior Specialist should:

  • Provide advice and input to the Team on technical difficulties that come up
  • Stay abreast of developments in tools, technologies, and techniques the Team is using
  • Anticipate tools, skills and other future needs

The Product Owner should

  • Stay up to date on industry news and developments
  • Give input on what features / functionality the Team should build