5 . Rome Wasn’t Built in a Day
...and wasn't your ScrumMaster
SUMMARY
Some people say that they have been working in the Agile ways since Dinosaur years. Others tell how they moved mountains as a ScrumMaster. But nobody ever shares how they learned to be a ScrumMaster, how they moved away from a hierarchal/command-and-control way of thinking to truly be an enabler. Nobody shares their story where they were the daemon. Let’s hear this horror story and how in the end the daemon got his salvation.
By Deepti Jain
In 2013, when I was almost at the 8th work anniversary, my “completely-immersed-in-waterfall” organization planned to go Agile.
As the first step, trucks loaded with employees were sent to the Agile Training Institute and we all were baptized to be Agile. We all felt frustrated as there was already too much of workload and our 2-days were getting wasted in some stupid project-management-process training (that’s what everyone in the organization called it).
Day-1 of training was fun. We enjoyed flying paper planes, juggling tennis balls and making jokes about ‘Agile’. But that did not help us understand Agile. I was a ‘Module Lead’ then.
Before we go further in this story, let’s reflect on the title “Module Lead”. A Module Lead is a title given to an employee as promotion, symbolizing growth in the company. As a Module Lead you do work as a Team Lead (leading the team on their work), but the title of Team Lead is saved so that there is something to offer you at the next promotion cycle.
Let’s go back to the Agile Training. On Day-1, when we were going back from the training institute, one of my team reports came to me and said, “Deepti, why don’t we run our new project in the Agile way? We were struggling on the clarity of requirements, the work that we were doing wasn’t getting feedback on time, and then we had to redo a major portion of the already completed work. It was frustrating and tiring.” She said, “if we do it in the Agile way, we will be able to set a frequency for getting requirements, feedback on our work”.
I wasn’t impressed with her awesome suggestion. Instead, I was annoyed. How could she understand what they were talking about in the class, if I could not? I felt pressure to understand it, actually before she could go back and suggest it to our Manager! This is how it works: I am a senior, therefore I need to know-it-all, so that I can offer the best advice.
Day-2 comes and I am all set to win, learn Agile in and out. Thanks to my team report, I was paying attention and listening to what was shared by the trainer: “In Agile, teams decide what needs to be done”. That statement shifted something inside me. And then came the most joyous statement, in Agile teams there are no Managers! That’s it, I felt that Agile was a heaven of freedom. We are free to do amazing things. We can decide how we want to achieve the established outcome. For me that was the key takeaway from that training.
But you see that old habits die hard. I was still thinking of what was the most powerful role in Agile –Scrum Master or Product Owner. I started paying more attention to get clarity. The Product Owner sounded really cool. A smart, powerful role, doing great things in the company. And this Scrum Master guy seemed more like a process guy, always running after people, asking them to adhere to process. But it was clear that to start Agile projects, the entire team and organization depend on the Scrum Master, PLUS s/he does NO work!! S/he only tells everyone what is to be done. Cool! “I will be the Scrum Master for this Project,” I said,
I went back to the office on Day 3 and told my manager this great idea of doing our new project in Agile way, much before my team report could suggest this to him. He agreed and so did our Sponsor and PMO. Wow! I was super excited. I had something new to do and learn.
I was all set to change the world with the superpowers of Agile, and being in this superhero avatar of Scrum Master! I will save the team –enable them to do their job right. Not only was I telling my team what each member needs to do, I was also telling my PO what needs to go in the backlog. I was deciding the priority of each talk and estimating each story for my team.
Aggressively, I was leading the team to greatness. But the team was also baptized with Agile: they revolted and said that as an Agile Team, they should get to decide who will do what, how will they work on each item, how they will collaborate, and how they will negotiate backlog items and priorities with the Product Owner.
I felt that I lost my team to Agile! I felt that the team was confused –they were supposed to hate the Product Owner, instead they started hating me. The Product Owner was supposed to pressurize the team, and I was supposed to save them. Earlier, my team could tolerate me as their Lead; now they started hating me as their Scrum Master. Agile had failed me.
And then suddenly I realized that I was doing everything I hated about my Manager, and other Managers, who always got to decide what everyone else will do, and who always has the final word on right and wrong, and failure and success. I failed in my very first Agile Project and felt devastated!
But my story doesn’t end there, it has a happy ending.
I got another opportunity to be a Scrum Master as I was the first CSM in my Organization. This opportunity was with a new team. I told the new Manager how I had failed with my first Agile Project. I wondered if she still wanted to risk her project. She asked if I had learned from it. I said, “yes.” “Then it’s even better” she said.
I found hope again!
I was the Scrum Master of a new team who was working with a new technology. And I was not willing to repeat my mistakes. My new Manager never interfered in my work and she never took status from me –yet she was always updated on the progress of the team. She was a true fly on the wall. With her, for the first time, I experienced what is true autonomy.
I started learning from my team about the project. They were a great technical team; however, they did not know how to showcase their work and impediments –that’s why the sponsors and Product Management Team started doubting their capabilities. So, as a Scrum Master, I did the following:
- Run effective retrospectives to understand team’s impediments.
- Started documenting and sharing impediments with all team members, sponsors and Product Management Team.
- Set a fixed rhythm for iterations, as well as missing working agreements between Dev and PM teams, such as how to track work progress, a definition of DoD, how to document the exchange of information on requirements (as it was getting lost in the calls), etc.
- Started helping the team present their work and talking about their impediments in Demo calls.
One thing that played a critical role in changing the external impression of the team was sharing the reason why a particular story was not done. It was found that the problem was at PO’s end: the Product Owner was not providing complete information about those reasons, while the team did not know how to express that –in fact, team members were focused only on their individual items, trying to save themselves. This new “sharing” approach –telling everyone “why any particular story was not done”– worked wonderfully for the team. There was no one each man standing for him/herself anymore.
The outcome of this effort was terrific:
- The team was able to deliver ahead of time.
- Product Management/Sponsors were very happy and they retained the team for the following year as well.
- Our project became top project that year and I became the most sought-after Scrum Master –every PMO offered me a job!
- My Manager gave me all the credit for the project success.
If my new Manager had not given me this opportunity and believed in me, I would have continued to struggle for power and control. In retrospective, I can say that was horrible and distasteful.
This experienced changed me forever. After that, I gave up my pursuit to be the next title in the organization. Instead, I focused all my energy in understanding the philosophy of Agile and how to excel in the art of enabling a team.
I started attending meetups to learn what is happening in other organizations. I started going to conferences to know what is new and valuable in the industry, and which tools and frameworks can help me.
In my organization, I spoke to leadership and sought approval to start an Agile CoP (Community of Practice) to learn and share with other SMs and POs. I started conducting training which not only helped other employees and their managers, but also helped grow my knowledge and facilitation skills. In my effort to help other Scrum Masters, I had to work with them on their mindset –and I learnt a lot from their own challenges.
In 2015 I left that organization and became an independent Agile consultant, ran meetups and then conferences to promote open learning, networking and sharing for Agility.
Here are some of my discoveries on this path:
- No 2days training can help you become an Agile Enabler. You have to travel the entire path. So have patience and enjoy the journey.
- Charity begins at home. You can not expect to be liberated when you are standing on the chains tying others. You have to set them free. You are not their boss, but their team member. You don’t tell them what to do, but partner with them in achieving that one goal. You share a common vision, common home where everyone is equal and important.
- Failures are great. They are like bitter medicines that are needed to recover from sickness. Great leaders learn from their and others‘ failures. Failure should be looked upon as opportunities to learn.
- Listen to younger people, they are not cynical and resigned like grown ups are; younger people see possibilities and opportunities that you might not see. When I started learning more about Agile ways of working, I went back to being a kid, who stopped trying to be a grown up who knows it all. You can only grow when you can learn new things, and learning only comes when you approach things with a ‘not-knowing,’ ‘no-ego’ mindset –like kids. It happens when you can ‘wonder’ and ‘wander’.
- Growth is not about designations and titles. As an individual you need to self-assess and constantly make efforts to learn new things, so that you develop a better understanding of things. When you look beyond designation, life is refreshing, there are new things to explore and achieve. That is real growth.
- A bad culture can not create good leaders. Maybe it just creates Managers who execute with command and control. Culture for sure eats strategy for breakfast. If you want to change an organization, change the culture.
- Change starts with YOU. It is for sure not an easy journey, but absolutely worth it. Also, when you work on changing yourself, you learn how to bring needed change in the system.
- Give people psychological safety, and you will see them grow and do wonders.
- Lead by example. You can’t say something and do something else. Your employees are like your children, they see and learn from you, not from what you tell them to do.
- As much as Agile is a mindset and a culture, I realized that holding on to a framework helps. When I say framework, I mean to say a ‘way of working and maintaining a rhythm for work’ that can enable Agility. Scrum is not a bad choice for getting started. After all, why to reinvent the wheel.
I am Deepti Jain and these are my agile-thoughts
2021 © Gurgaon, Haryana, INDIA by Deepti Jain
Active Agile community builder in India. In 2015 she founded “AgileVirgin” to offer consulting, coaching, training and countrywide Communities of Practice.
She is the Director of the initiative Agile Alliance Initiative “Building Future Leaders and Change Agents.”
She loves to connect and interact with people and prefers to call herself a Social Scientist. Always feel herself where technology meets people.