This and the following blog articles will share a series of conversations with Slava Moskalenko, the industry-recognized Scrum Coach. He addresses one of the biggest pains that frequently occur in Agile transformation, self-managing and cross-functional teams.
Experts, teams, and companies whose activities are related to product development often complain about the team-related problems they face trying to implement or use Scrum. It is one thing to learn about Agile and another — to practice it.
I had the privilege of implementing Scrum in large companies in the U.S., Singapore, the U.K., and other countries. I gained both good and bad experiences that I want to share here on the pages of Agile.Live.
The fact is that all attempts to introduce Scrum according to the tenets of Agile can be eliminated by a small but insidious nuance — an outdated teamwork approach. You will need a step-by-step strategy to form the Agile culture in teams.
Teams are in the very essence of Scrum. The purpose of the Scrum Master is to create an environment where, in each sprint, the team can create an increment based on the agreed tasks. In Scrum, the “boss” is not a pivotal person to driving a planning process. Still, the team members should take more responsibility for planning their work, assessing the results, and making all the necessary adjustments in the next sprint.
Key Terms and Concepts
Firstly, let us clarify the key terms.
We use self-managing and self-organizing teams interchangeably. Some even argue – which is the right one. I will not waste our time on proving which one is right or wrong. Instead, I will talk about teams as Scrum defines them.
Scrum Guide suggests such concepts as self-managing teams, self-management and cross-functional, cross-functionality. They are the essence of scrum teams according to Scrum. (For more information, see The 2020 Scrum Guide on Scrum.org.)
Self-managing teams mean small teams of 6-10 people that are not organized or managed by someone. Self-management is not something abstract, philosophical, populist, or PR-slogan-like. Sometimes I see compelling posters in the company office – “Teamwork makes the dream work!”, “One spirit, one team!”, “Together, we are strong!”, “Five players, one beat!”, but in reality, the culture is quite opposite to what they declare. Self-management presupposes responsibility for a clearly defined range of tasks that will have to be addressed together in the development process.
These tasks lie in three dimensions:
THREE DIMENSIONS OF SELF-MANAGING TEAMS
There is hardly anything simpler in terms of theory. At the same time, there is hardly anything more complex than “what, when, and how” in terms of practicing Scrum as teams.
Challenges of Scrum teamwork
Regardless of the geographical location (USA, Eastern Europe, Australia, Middle or Far East countries), economy, or industry (IT, banking, manufacturing, etc.), most teams can not immediately “catch the spirit” of Scrum.
Why? What prevents them from making changes quickly and functioning as a professional Scrum team?
Even if you get the best leadership training or experience in product development or know the theory well, there is still a gap, the human factor.
Let’s imagine for a moment a person who is expected to be the change agent. His first goal should be to get rid of the bossy attitude, share his authority among the team members, and not interfere.
But what if the team makes a mistake or took the wrong path? What if the leader has his vision of solving the problem? When a leader holds to the habit of controlling “what”, “when”, and “how”, he believes that helpless specialists will not do the job without his wisdom. The best way to ruin self-management is to cancel team decisions when you don’t like them.
Old-school leaders create the illusion of Scrum. After all, the roles are there, and the team is there, the certificate is there, the framework is there. But the team can still be passive, waiting for the boss’s command, or vice versa — the manager, imposes his will on the team.
Following that human factor, I also made this mistake when introducing Scrum to a small group of four engineers. Fortunately, I had a good mentor in that company who helped me identify my “old-school boss” problem promptly, and the product itself turned out to be successful.
Features of Scrum Teams
So, the team approach to development is at the very heart of Scrum. It excludes complex hierarchical systems or multi-level structures that are usual in classical organizational management. Instead, it is a group of specialists who focus not on “meeting the requirements at their structural level” but on achieving the goal of creating a product that is valuable to stakeholders and customers.
Each Scrum team consists of:
- Scrum master.
- Product owner.
Scrum teams are self-managed – they decide what, when, and how to do it. And also, cross-functional – they have all the skills necessary for successful product development. They, therefore, can decide on their own who will do what and how.
In addition, the members of a cross-functional team can replace each other, help one another, and generally take care of each other. Empathy is one of the critical features of a Scrum team that sounds like fiction, especially for those who grew up in a culture where hierarchy still dominates.
Quantitatively, these are small teams (6-10 people). This limit is intentional as the result of empirical observations. After all, small groups of professionals can use time more efficiently, come to an agreement faster, and demonstrate higher productivity. Building a big team is not Scrum’s feature. Large groups of people will most likely be divided into smaller units, focusing on a particular product.
I want to emphasize, self-management and cross-functionality imply the responsibility of each team member, which significantly affects productivity and quality.
“Self-management and cross-functionality imply the responsibility of each team member, which significantly affects the productivity and quality.”Slava Moskalenko, Scrum coach, co-founder of Agile. Live.
The fundamental difference between Scrum and other approaches is that Scrum teams create value at each stage of product development (sprint), which helps to deliver much more value by the end of the project, in contrast to the older approaches, when the customer can see the result only at the end of the project, not being able to make any adjustments in the intermediate stages of development.