I have recently had conversations about software development processes and have heard the words “scrum”, “Agile”, and “waterfall” thrown about with tremendous ceremony. I have worked in many places where people use words in conversation in a way that implies that they are important and sacred and to the speaker they have no meaning. “Where are we with Brand and Budget” I might hear someone say. There is an equal and opposite effect when I hear someone say “This Is Not Agile”.
If you have ever uttered these words, you have missed the whole point of Agile.
I am not going to be one of those people who writes a bombastic article that Agile is dead, or that it is a fraud perpetrated on teams by management, and that most of it is fiction.
The deep truth is that most Agile is an approximation anyway because the following user story will never appear on your scrum board:
“As a software developer I need Christmas to arrive one week late.”
So what the hell is Agile, and why does this sound like it makes me so angry?
Before I answer, I want to time travel to 1993.
John was a software development co-op student in 1993 working for Motorola. Motorola had a design center in Toronto where they made devices to help improve communications as a part of 911 software systems. I had the blessed fortune of joining a team to produce highly redundant systems that helped save lives. The work was all hard core modular C programming and designed to work on highly available hardware. This is important because we all had log books, strict documentation requirements, and were also ISO-9000 compliant. The only way our work would have been more waterfall is if we were doing it under a big water feature in Niagara.
The project shipped on time, on budget, and it was a fantastic work experience—even if one of my jobs was to take a copy of the project source code on magnetic tape and walk it to an offsite location to be signed into a vault for safekeeping and redundancy.
Let’s come back to today.
I bring this up because every time I enter into the conversation on how we get our work done, I have to point out that for each team and each product there are different methods that work well, and there is no One True Answer.
This is especially true for Agile teams.
The process of doing work on an Agile team is a conversation between the product customer, the product designer, and the product implementer.
There is one more participant in that process and that is the scrum master.
I have had to adopt the scrum master role as a part time job in the past. I am usually doing one or more other roles at the same time. When I am either volunteering for the role of scrum master, or having it thrust upon me, the first thing that I do is gather all of the stakeholders and declare that I am taking the role with a known conflict of interest and ask for everyone to trust that I will handle that. I also ask them to call me out when I am failing at it, and to keep me accountable.
The scrum master role is not well understood by many people. I have had the great fortune of working with many amazing scrum masters over the course of my career. They help everyone get things done. They are great coaches, they are wonderful listeners, and they are excellent facilitators.
I have also had to work with many scrum masters who struggled with their role. There are a lot of traps to fall into and I do my best to help people work their way through them.
“This Is Not Agile”/”This Is Waterfall”
The number of times I have had to drag people kicking and screaming away from the Semantic Scrum Master debate is beyond counting. It is important to remember that Agile is all about people over process. Anything your people want to do is Agile. Even if you were a fully ISO 9000 certified process and you declared you were an Agile team, you are now Agile. Do you ship software on time or do you improve your velocity? If the answer is no, you are still Agile. You are just doing bad Agile. If your teams really want to do something and it sounds like it is not Agile, just ask them if it helps them get the work done. Measure it over time, and see if you get better at it.
“This is not the way I want it done”
As a scrum master, you are a coach and a facilitator, not a dictator. You have to let go of your notions of control and ownership on anything but team improvement. What works for one team does not always work for another. Your best successes will come by laying out options for the stakeholders to think about, debate, and adopt. Any time I see a scrum master trying to push people towards something, I have to gently coach them off the ledge and get them to take a more team-centric view of how work gets done.
“Measure twice, cut once”
Even more egregious than needing things done your way is making changes to the way your team works without really understanding the data. I appreciated the many times I have been brought into an organization to help them ship faster with better stuff. That process takes a lot of time. You need to get to know the people on the team, and watch what they do. Listen to them, and ask them questions. Make notes for when you are ready to give them options on things they can consider changing in order to improve. I have joined teams very early on with a lot of process dysfunction. I have my own playbook for urgently addressing these situations, although my preference is to take six weeks or so to watch what is happening before I make any changes.
These are the most common scrum master mistakes I have seen. It is very easy to get defensive and frustrated when you make a mistake like this and you are confronted by your stakeholders.
I have had some success in working through issues like this with a number of scrum masters over my career, taking them from struggling with a single team to being able to work concurrently with three or more teams while creating speed and quality improvements on all of them.
Part of this stems from a six hot dog / eight hot dog bun problem in early stage companies. When you get your first full time scrum master you might only have one team. There is a human need to feel like you are delivering some kind of value by changing things, and it is an easy win to make yourself look successful by telling your new boss “hey, look what I just did!” Unfortunately, this might not be what your team needs. You are better served by being patient and learning what your team is capable of doing before starting to make measurable sustainable changes.
If you are contemplating hiring your first scrum master, it might be worth asking yourself if you want to have someone else take the mantle for a while, especially if it is a single team. You will get great mileage out of people you are grooming for leadership, and it will help avoid a number of problems when you hire a scrum master who is likely underutilized and might accidentally thrash your teams in order to show that they are earning their paycheck.
Thank you for reading along. This was a heavy topic. There was a time in my career when I was frustrated with educating my peers and more senior leaders in a given company and I was resentful for it. This post, at some level, is penance. I hope you enjoy it and that you reflect on the people you work with to ask yourself how you can help them be successful—much the way I have assisted a number of scrum masters on their roads to success.
Stay tuned for next week where we will continue to not talk about quiet quitting!
