We continue a series of conversations about self-managing and cross-functional teams with Slava Moskalenko, an industry-recognized Scrum Coach and Co-Founder of Agile.Live. (See the beginning of the discussion in “Self-Managing and Cross-Functional Teams: Insights”, where Slava explains what scrum teams are and the main challenges they face in Agile adoption.) Now, Slava shares a case from his personal experience.
[Slava Moskalenko]: “I thought it was a success, but no — experience, again.” I want to share about my failure at the beginning of my career in Scrum. It is important because of the following:
- People tend to idealize experts. Instead of motivating, idealization often demotivates. A person thinks “I will never be like him” and gives up, instead of making changes and moving in the direction of “Yes, and…” enthusiastically (for different ways to say “Yes”, see Gunther Verheyen’s blog post “Different shades of Yes”).
- Companies need to hear not only the “right answers”, but also learn from mistakes. It is better when those mistakes are made by others.
- The “fail” story is actually a valuable insight that helps to understand Agile better and how to transfer ideas from books to real-life situations.
In 2008, I had the honor to work at Ciklum, developing a platform for a major mobile operator and other projects.
At that time, I was a team leader and worked together with the project manager, senior and mid developers, testers, and other product development participants.
We followed the “old” paradigm known as a waterfall (or cascade) model. I use quotation marks because classic project management is still relevant for many industries. The idea is that we come up with a well-prepared project every detail of which corresponds to the tech requirements. Then we break it into stages, and at the end, finally, deliver the product — “according to customer’s requirements.”
From the organizational management point of view (especially in the post-Soviet countries), each project must have a boss. It is the boss who decides what needs to be done, how, and when. He negotiates with the customer, not the team. Team members are his subordinates or “employees.”
Obviously, this definition of management is not academic, but at least easy to understand.
I liked it. I did the planning myself, I assigned the tasks, I told others what to do. It was my persona that played a major role in product development.
I enjoyed the importance of my “self”, my ability to control everything and everybody, my authority, and the dependence of others on me. I liked “leading.”
When someone could not complete a task, did it poorly, or did not meet the deadline, I lectured such a careless employee. Or made him feel ashamed, or guilty. Paradoxically, the practice of shaming and scolding gave me brutal pleasure!
Then, as an older brother — wiser, smarter, and better — or as a father to a son (even if the “son” was in his forties), I explained how to complete a trivial task.
Finally, the wind of change came (the project manager read a book on Scrum.) In particular, he liked the Daily Scrum idea — fifteen-minute meetings where you could quickly discuss what was done yesterday, what you need to do today, what impediments the team was facing, and what help it needed. Without thinking twice, he gave an order to adopt some parts of Scrum practice.
Scrum was something new for most companies in Eastern Europe at that time. There was a lack of knowledge base and experts.
The company got interested in the “iterative and incremental approach”, simply because it could increase its efficiency significantly. The concept of “self-managing teams” was not seen as something important at that time, because everyone was tired of all kinds of team-building training dealing with such transcendent concepts as “team unity”, “team spirit”, and similar, not really understanding the difference.
We did not realize — to adopt the incremental and iterative approach, we had to create the agile culture of teamwork. Otherwise, instead of the Scrum framework, there will be the “frame” only.
My first Daily Scrum was like a bad first date. Our project manager announced that from now on we would work differently. That raised more questions than answers. Many people in our society declare the “new way”. In addition, we all know that “new” does not mean great, and “great” does not mean new. Therefore, the team members did not change the old habits and waited for the next orders from me as their boss.
We started practicing Daily Scrum. However, I continued to be the boss, and the team continued to be a passive group of subordinates with no initiative.
I asked questions in compliance with the “framework”, but the answers were formal. Everyone knew that it was Slava Moskalenko who was making decisions.
And they were right. I controlled the team. When something went wrong, I looked for the perpetrator and, as usual, explained the right way to him.
Interestingly, the work environment remained positive. Nobody was unhappy. Everyone just got used to working in the old paradigm.
No one wanted to take the initiative, let alone take responsibility. I did not welcome any initiatives either, except for my own. I did not want to lose the “leadership role” and the feeling of superiority.
Thus, from the outside, we adopted some elements of Scrum, but nothing changed inside the team. We held meetings, assuming they were “Daily Scrum”, but they weren’t. We met more for a “status” or “transparency” purpose (so that everyone could see who was doing what.) De Jure, there was a newly created scrum team, but De Facto it was the same old passive team led by a project manager and directed by a technical leader.
The absurdity of the situation reached its climax when I suddenly realized that I was telling my “subordinates” what they should and what they should not say in the Daily Scrum!
My manager noticed that also. Fortunately, he had a supportive attitude and simply helped me to speed up the transition from the old way of thinking to the new one.
I was resisting at first, finding excuses to maintain the status quo (“We can’t be self-managing, because…”, “We need change, but the team is still immature”, and so on), nevertheless in the end I said my confident “Yes!” to Agile (see “The Four ‘Yes’, And Gunther Verhein’s Dichotomy”) and my new life began.
5 things I had to change in myself
The following issues were difficult for me to change:
- Accept the need to share power.
- Release the reins of control.
- Create a favorable environment for the team to solve problems autonomously.
- Do not interfere when the team faces impediments. Trust the team.
- Create a new set of skills for building a self-managing team, the skills related to emotional intelligence, empathy, and the ability to adapt to new circumstances.
9 Points Summary
We considered the case of a bad transition to Scrum and came to the following nine conclusions:
- Adopting Scrum in a “manager→subordinates” paradigm is a gross mistake.
- Before adopting Scrum, we should clearly understand the difference between the waterfall model and the iterative and incremental approach.
- There is no need to keep a boss (king, chief, “leader”) who does not want to share power or put off the weight of his persona in product development. Such individuals will block the initiative of other team members and create a bad dependence on the manager, instead of fostering interdependence between the members of a cross-functional team.
- The team leader does not have to step in when a problem or impediments arise. It is better to let the team find a solution on their own.
- Everyone makes mistakes, and that is normal.
- No need to believe in a “perfect team“. Ideal Scrum teams exist mainly in books. Idealization is often demotivating, rather than motivating.
- Do we want Scrum or its illusion?
- It is important for beginners to have a mentor to speed up the transition to Scrum.
- The task of a leader in Scrum is to create an environment that enables the team to work productively.