Self-organizing and cross-functional teams are a core element in Agile Projects but are not an invention of the Agile Movement. They have been used successfully in Japanese companies and some American companies for many decades. This unique management method, with managers as coaches without management functions and fewer management levels, was unfortunately almost forgotten. With Agile Project Management, empowerment and self-organizing teams have been rediscovered in recent years. Read in this article how self-organizing teams emerged, what their characteristics are and how they function.
Self-Organizing Teams Have Been Around for Decades
The principles, methods and values on which agile project management is based have been around for decades. Most of them come from the Toyota Production System (TPS), which the highly interesting book “The Toyota Way” explains in detail.
The Toyota Production System emerged after the Second World War and was a driver for many effective management methods, such as Lean Production, Lean Management, Business Process Reengineering and Six Sigma. Self-organizing teams were a core element of the TPS and were then successfully implemented in the 1950s and 1960s in various Japanese and some years later in American companies.
Self-organizing Teams were very successful in these companies, but surprisingly they have never really established themselves broadly in the industry. Only the automotive industry has learned from and benefited greatly from the Toyota Production System and Lean Production. Although different studies in the 1990s showed that self-organizing teams lowered production cost by 20-40%, and increased productivity by up to 50% ,self-organizing teams have almost been forgotten until Agile Project Management emerged.
If you want to get a deeper insight into the origins and characteristics of self-organizing teams, I can highly recommend the book by Kimball Fisher: Leading Self-Directed Work Teams – A Guide to Developing New Team Leadership Skills.
What Makes Teams Successful in Product Development?
A key aspect of Agile Project Management is teamwork and the application of knowledge. To learn more about this, let’s make a short excursion into the past.
Hirotaka Takeuchi and Ikujiro Nonaka described the characteristics of successful product Development Teams in the 1986 Harvard Business Review article “The New New Product Development Game”. The content of the article is strongly influenced by the “Toyota Production System” and Japanese product development methods, e.g., at Canon, Honda or NEC in the 1970s. This article describes the key features of successful product development teams with these six points:
- Built-in instability: The management initiates the development process, sets challenging goals and requirements and gives the team the greatest possible freedom in development.
- Self-organizing project teams: The team works like a start-up company, it is proactive, takes risks and has an independent agenda: The teams are characterized by the following three characteristics:
- Autonomy: The teams are self-directed.
- Self-transcendence: Continuous learning. The team strives forwards and always wants to improve.
- Cross-fertilization: The teams work across functions. This diversity promotes new ideas and concepts, leading to more successful products.
- Overlapping development phases: With strongly overlapping phases, the development process becomes faster and more flexible.
- Multilearning: Through learning at different company levels and in groups, through constant exchange of experience and through contact with the environment, one can react more quickly to changing market conditions.
- Subtle control: The management sets enough checkpoints, although the project team organizes itself. The aim is to avoid instability, ambiguities and tensions.
- Organizational transfer of learning: Learned knowledge should flow into the organization in order to improve constantly.
Most of these six points influenced Agile Project Management and modern software development, but specifically self-organizing teams.
The low success rate of software projects in the 1990s was not due to insufficient training of employees or the lack of maturity or the still young computer science and its tools. The main reasons were heavy-weight, sequential implementation methods and insufficient collaboration in projects. Ken Schwaber and Jeff Sutherland recognized this and then developed a successful software development framework from the knowledge of “The New New Product Development Game” and their own experiences—and this was SCRUM.
What is a Self-Organizing Team?
Definition: A self-organizing work team is a group of employees who take responsibility for themselves and their work on a daily basis with a minimal direct supervision. Members of self-organizing teams usually take on tasks, plan work, make production and/or service-related decisions and take action in the event of problems.
Self-organizing does not mean that the team determines its own goals. The strategy and goals (what is to be produced or developed and by when) are defined by the management, the project sponsor or the customer. How the goal is best achieved and with which activities and processes the team defines itself.
Here you find a well writen article about the slight difference between Self-Organised vs. Self-Managed vs. Self-Directed teams.
Translated in the Agile context: Agile projects do not have a project manager, team leader or manager. The Product Owner defines together with the customer, senior management or project sponsor and stakeholders the vision and strategy of the project. The product owner then defines the goal for the release and the next sprint. The development team assesses whether this goal is feasible and then decides for itself which tasks are necessary to achieve this goal. It coordinates and monitors its own work. This means that it organizes itself
The Difference Between Traditional Organizations and Self-Organizing Teams
The following table will help you better understand the difference between traditional organizations and self-organizing teams.
Self-Organization is a Learning Process
For new Development Teams in Scrum, organizing the work themselves is a learning process that is considerably supported by the Scrum Master. Because Development Teams work more closely together and there is no “boss”, conflicts occur more frequently. Here, too, the Scrum Master helps the team to acquire the skills to solve conflicts positively and make decisions amicably. Working together in a Development Team without a leader is challenging—and a Scrum Team has to learn this first.
A self-organizing team is only successful if it defines and lives values, principles and rules. Here the 5 Scrum Values form the basis for successful collaboration.
Self-organizing Agile Projects have the following strengths:
- Increased flexibility and responsiveness
- Greater productivity and faster results
- Improved quality of results
- Higher level of efficiency through constant learning
- Better employee attitude and commitment
- More meaningful, interesting and worthwhile work
These Characteristics Promote Collaboration
What is most important for self-organization, team dynamics and the development of the team is that it should orient itself to the agile values and internalize them. But also, the following characteristics of each individual team member promote collaboration and provides a work environment that generates trust (Larsen, 2004).
- Credibility: Everyone should show consistency and reliability in their role.
- Listening: Everyone should show interest and listen openly.
- Openness: Everyone should open up and not hide behind a mask.
- Empathy: Everyone should be able to put themselves in each other’s position.
- Interest: Everyone should have a natural interest in the team or colleagues.
- Feedback: Everyone should expect feedback and be able to give it independently.
Of course, you can imagine that these are characteristics which are not equally pronounced in every team member and cannot be learned so quickly. How easily they are implemented usually depends on the personality of the team member. You may need to work on it for months, years or your whole life.
Taking Ownership
“Taking ownership” is a core element of self-organizing teams. Taking ownership means acting in the project as if I were developing my own house and spending my own money on it. I suppose everyone of you would do the best for that. Am I right?
You have the authority to act and you are responsible for your own actions.
Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. (Agile Manifesto Principle)
Each Development Team member of a cross-functional, self-organizing Development Team takes responsibility and initiative for their project, their work and the results, as if they were developing their own “child”. Unfortunately, top-down management of traditional projects does not often promote this maturity of ownership.
To take over ownership, two essential components are necessary:
- The management must trust the Scrum Teams and give them freedom and responsibility.
- The Scrum Teams must take responsibility, take advantage of freedom and promote a culture of autonomy, thereby increasing their ability to become a powerful team.
A core element of Scrum is, that the Development Team is not only given great responsibility, but is also empowered. This means, for example, that the Development Team alone decides how many requirements it can implement within the next Sprint. The Development Team also decides for itself how it organizes the work and which work steps will be necessary for this.
Is Everyone in the Team Really Treated Equally?
Should everyone in the self-organizing Scrum team have the same status and be treated equally? According to the motto:
Everyone is equal in my team—everyone sweeps the floor.
Yes, this is usually the case. But in self-organizing teams not everyone in the team always has to be treated equally.
When a very experienced team member says, “This will be difficult to develop”, the other team members should consider this opinion accordingly. If the junior intern you hired yesterday says the same thing, the team members should listen, but give less importance to this opinion. You should weigh opinions based on people’s merits or their believability.
Every team member should receive the respect they deserve—according to the Scrum value “Respect”.
This was a short summary of how self-organizing teams emerged, their characteristics and how they are working in Agile Projects.
Here is More Knowledge
Would you like to learn more about how Scrum can make your Agile Projects even more successful? My book “Scrum – How to Successfully Apply Agile Project Management and Scrum” takes you an important step further!
Do you know anyone who might be interested in this article? Then simply forward it or share it in your network. Thank you very much!
Other Book Recommendations:
Leading Self-Directed Work Teams – A Guide to Developing New Team Leadership Skills
