Self-managing as a route to top teams

Teams are the fundamental units of Agile development.  The primacy of teams goes right back to the Takeuchi and Nonaka paper in the 1980s.  The first of the Agile Manifesto Values promotes “individuals and interactions”.  The name “Scrum” was chosen specifically to focus on teams (representing the tight binding in rugby).

One area which distinguishes successful technology companies most is how the company builds teams.  To be effective as an Agile organization, we need to make teams the primary unit by which development works.  As a concept, that sounds straightforward.  However, building effective teams proves to be one of the major challenges in implementing an Agile approach.  Building team focus and empowerment runs counter to many traditional management ideas.

What is a team?

A “team” means more than just a grouping of individuals.  Traditional organizations build groups for convenience of labelling or managing.  The traditional (scientific management) structure is to use large functional groups with a resource manager.  The group will generally be a set of people (functions) with similar skills.  Individuals are deployed to specific work (projects) as their skill becomes needed. 

In this functional/projectized the individuals are working independently or in temporary project.  There should of course be an overall plan.  However, the plan is held by management external to the functional group.  Each individual is delegated their own tasks.  I’m sure that people will recognise the spectre of the Scientific Management model here.

A team is something more than a collection of individuals.  The key difference is that the team have a shared goal or vision and a collective accountability to deliver this.  They are working together to achieve this goal.  We see this in Takeuchi and Nonaka’s “rugby” model.  To progress down the field in rugby requires individual commitment towards a shared goal.  No one individual can score alone.  But individuals have a high level of commitment to ensuring that the team scores.

[A team is] a small group of people with complementary skills, committed to a common purpose, performance goals and approach for which they hold themselves mutually accountable.

“The Wisdom of Teams” – Katzenbach and Smith

Self-managing

Central to the idea of effective teams is the concept of “self-managing”.  This is a stark contrast from the approaches promoted in Scientific Management.  In Taylor’s approach, the teams are passive.  Workers execute work. Management is a separate activity which is managed outside the team.  There is a different class known as managers who execute these activities. 

If we are to break the Taylorist mould, we need to bring management into the team.  This is the concept at the heart of self-managing teams.

What exactly do we mean by “self-managing” or “self-organising” teams?  Takeuchi and Nonaka were insightful even back in the 1980s.  They refer to what they call “self-organising” as one of their central principles of the new way of working.  They look in some depth at what “self-organising” means and describe it as follows. In this play we will look specifically at autonomy (the others are covered in other Plays). 

We aim to understand what really makes a “self-organizing” team.  Once we understand the components, we can ensure that we build our own teams.  Understanding Takeuchi and Nonaka’s breakdown will also allow us to match this up with the Scrum concepts.

Team autonomy

Two terms “self-managing” and “self-organizing” are being used here to cover what Takeuchi and Nonaka call “autonomy”.  Sadly, as with so many Agile terms, there is confusion between these and no agreed meaning.  The Agile Principles refer to “self-organizing” teams.  Takeuchi and Nonaka also use this term.  The Scrum Guide used “self-organizing” until 2020 and replaced this with “self-managing”.

In general, there is an acceptance that “self-organizing” means “able to decide how to perform the work”.  This focusses specifically on work management. It does not imply that the team choose which work to do.  The focus is on the “how” not on the “what”.  Given a deliverable such as a feature or release, the team “self-organizes” around delivering that work.

The term “self-managing” is related but slightly different.  Taken literally it implies that the team does not have external management.  A more general interpretation is that a self-managing team has more autonomy over the delivery of value.  A self-organising team is assigned work but chooses the approach to use.  A self-managing team is assigned objectives and chooses how best to achieve them.

I prefer to use “self-managing”.  Moving away from Scientific Management ideas is key to team autonomy. Given more team autonomy, delivery of value is the best focus for that autonomy.  Of course, like all Agile terms, the definition of these is not standardised and other interpretations are used.

The concept of team autonomy is fairly straightforward to describe and understand.  However, do not imagine it is straightforward to implement.  Team autonomy is a significant challenge to fit into an organization. This is especially true if we are moving an organisation from traditional management towards greater team autonomy. And there can be risks about autonomy related to Groupthink.

Strong autonomy

The degree of autonomy may vary substantially between different teams which consider themselves “self-managing”. Takeuchi and Nonaka used “self-organizing”.  However they clearly meant a level of autonomy beyond that expected for most development teams. Their model looked at business units with both commercial and development elements.  In Takeuchi and Nonaka’s paper, autonomy could be extreme.  The case studies which they were examining had typically been given money, some guidance and coaching.  However they had often been supplied with little other support from the parent organization.

What we might call “strong autonomy” models like Takeuchi and Nonaka’s have been implemented in some organisations. Haier is a good case study.

Haier moved from being an unsuccessful manufacturer of refrigerators to the world’s largest white goods manufacturer.  As part of this they completely rethought their organizational structure several times.

They moved first from a traditional hierarchy, through traditional business units.  Then to an inverted pyramid of two thousand autonomous teams each responsible for profit and loss.  Finally they radically decentralised and extended team autonomy.

Haier reorganised to four thousand “microenterprises” each running as independent organizations.  Under the approach which they call RenDanHeYi, employees group in microenterprises.  These are typically five to twenty employees in a flat structure.  Each microenterprise innovates around specific opportunities.

The meaning of the name “RenDanHeYi” is that each employee should directly face users, create user value, and realize their own shared value.  As part of this transformation all mid-level management was removed.  Around twelve thousand managers either joined microenterprises or left the organization.

Good practices

In most scaling organizations we will not be aiming for “strong autonomy” or taking the radical path of Haier. However, as an Agile leader you should be prepared to manage the concerns, especially from existing managers.

Schwaber describes self-organising teams as deciding how to achieve the work (rather than what needs to be done) and it is important to ensure this language is understood in the organisation.

Teams must be more than just a grouping of individuals. Team leadership will be central to ensuring that they work autonomously and are able to take effective decisions.