Like many of us, I started my Agile journey by looking at the Manifesto for Agile Software Development. With my team, we decided we’d try our hands at Scrum. The guide seemed quite clear, it made sense, and furthermore it seemed pretty lightweight compared to our usual project management methodologies.
Since our project manager spent a lot of time with our client, it seemed pretty straightforward he’d become our Product Owner. Over the previous months, I had started to lose my proximity with the code, and seemed more interested and curious about bringing people together in order to solve issues. So, I set out to become the team’s Scrum Master.
Actually, in hindsight, the term could be quite scary when starting out, since I had as much experience about Agility and Scrum as the rest of the team. How then could I be considered as someone mastering Scrum?
Over time, we started to become more confident in how to work together as a Scrum Team. We learned a lot from the guide, referring to it as soon as we questioned our way of working. The rules of Scrum are quite clear, which helped a lot.
Look, you’ve got it all wrong!
However, we felt we were missing something. A few things didn’t feel right and I couldn’t put my finger on it.
The sprint planning sessions were actually quite boring, the team didn’t seem to care about what was accepted in the sprint. Since there was no team ownership, I felt I was the one who had to ask “Do you really think we can commit to that!?”
During our dailies, no one actually seemed interested about what the others were doing. People were just doing what they had planned to do, and although burndown charts were visible, there was no real interest in making sure the sprint goal was reached. Sure, people were doing what they were supposed to do, but we were missing the vibe of great Agile teams.
Our review sessions seemed quite stale, with the Product Owner going through all the “done” items without a real involvement of the team. And our retrospectives? They were okay I guess… I had read that it was important to hold retrospectives and gotten a few formats to experiment with.
However, over time, we kept finding issues that were outside of our team’s perimeter, which made us feel powerless.
I’m sure many of you will have identified some things we could have done better. At that time, I couldn’t. The thing is, I got my revelation during a Monty Python movie night, when watching Monty Python’s Life of Brian. For those who haven’t seen it, the movie follows Brian, a guy born at the same time as Jesus, who gets mistaken for the Messiah.
One scene in particular struck me. At one point in the movie, a huge crowd gathers in front of his window, and expects him to tell them what to do. And suddenly, as I was listening to Brian’s speech in front of the masses, it struck me.
We had started our Agile journey with Scrum, and expected the guide to tell us what to do in all situations. And in a way maybe we expected that it would fix all of our problems!
These thoughts raced through my head as the speech continued:
Brian: “You don’t need to follow me, you don’t need to follow anybody! You’ve got to think for yourselves, you’re all individuals!”
Crowd: “Yes, we’re all individuals!”
Brian: “You’re all different!”
Crowd: “Yes, we’re all different!”
Brian: “You’ve all got to work it out for yourselves!
Don’t let anyone tell you what to do!”
Suddenly, I wasn’t sure whether I should laugh or cry. By focusing so much about trying to find answers to our questions in the writings, we had forgotten what Agility was all about. You see, one of the first values of the Manifesto for Agile Software Development puts people and interactions before processes and tools. We had focused on the Scrum process, without thinking about the essence of Agility.
Inspect and adapt, beyond Scrum
So, I changed. Instead of looking for answers, I started to look for inspiration. I started attending meetings and going to conferences, I met people and discussed our issues! And suddenly, instead of seeing a lot of things we were doing wrong, I saw a lot of opportunities for growth and improvement!
I started reading about systems thinking, how responses should be appropriate based on context (which is how I understood Dave Snowden’s Cynefin model).
Based on that, we changed the way we held our retrospectives. Thanks to the excellent references I was given (Agile Retrospectives by Esther Derby and Diana Larsen as well as the Retromat tool), I was able to try out new formats, and after a while some other team members volunteered to facilitate them!
Talking about team ownership, I had read about Christopher Avery’s Responsibility Process. After attending a two-day workshop with him, I had learned how to apply it to myself and coming back to the team, we started identifying at what responsibility level we were. We noticed we were usually in a mix of Obligation, Justification, and Lay Blame. Once we were able to identify that, we started to reflect on whether we were okay with that, or if we wanted to change. It turns out this brought us a new way of looking at the issues we previously thought outside of our perimeter!
So, members of the team started to own their sprint so much that it became more difficult for the Product Owner to change the scope of the sprint during the iteration. During a discussion with the PO, they agreed to move from two-week sprints to one-week sprints. This brought its new wave of challenges: how can we expect to release every week if it takes three hours to put the package into production?
Actually, while the team would have said a few months ago that it was impossible, they now worked together to make this new vision a reality. They started automating a lot of our deployment actions, and came up with a script that would select all packages approved during the Sprint Review. We were using external data centers, so instead of us delivering a package along with an installation document, our partners suddenly received a self-running package and were able to deploy the packages without any issues.
Looking back, I think we learned a lot during our first experience with Scrum. Being used to work with prescriptive methodologies, it was difficult for us to let go of our habits. Starting the road towards more Agility can be scary at first because no one is there to “tell you what to do”. The journey towards Agility is a learning journey. It’s time to stop thinking there’s an answer to every question, and to start a journey of experimenting and learning.
Own these experiences, let the team own them, and make sure to reflect on the result of those experiments. I understand it can seem daunting at first, so should you want to start, it might be useful to refer to Stephen Covey’s Circle of Influence and Circle of Concern (The 7 habits of highly effective people). Map out what you want to try out, and start with those within your Circle of Influence (I would even go as far as suggesting to adding the Circle of Control). Succeeding with those will give you and your team more confidence in trying out more experiments in order to be successful!
I started on this journey some years ago and haven’t looked back since.