A software development team, had been “doing Scrum” for years, since it was decided that Scrum was the “way to go”. A classic. All meetings were conducted, but gave no or little value. It was just accepted like “that’s what happens when Scrum meets reality”. Failed sprints were the standard, frustrations were building and unfortunate leadership mecanisms were “needed” to get things done.
When I was appointed as the ScrumMaster, I quickly realised that I had to do something drastically to gain the team’s trust to Scrum, and to build the team’s trust in me, as a ScrumMaster. Especially because I do not have a developer background. I had to relaunch Scrum in a way I had never tried before…
So I said: “Let’s call off Scrum!”
The reactions were many. Some were puzzled, “weren’t you the ScrumMaster?”. Some were relieved, “great, then I can get back to coding”. And some were sceptical, “Then, now what?”
My reason for doing this was to kickstart the dialogue about Scrum, since no one had evaluated the process for a long time, and I was surprised how well this turned out. I told the team, that their time is very valuable, and therefore it shouldn’t be wasted in meetings with no or little value.
It really got the dialogue going, between me and the team. The dialogue changed from, “how can we fit our way of working into Scrum” to “how can we fit Scrum to the way we work”. This was a huge thing, since we were now using scrum for a purpose, to solve our challenges. The trusting environment were already growing.
In order to keep the momentum in building the trust in Scrum, it was important that the relaunch of each meeting became a good experience for everybody. Therefore, the first sprint planning were not conducted until we had enough backlog items ready, to make it a good session. The first retrospective were not conducted until I knew there were also good things to talk about. The first review meeting were not conducted until we knew we could demonstrate a significant amount of (done) features.
During the process I had my doubts if this was the right approach, but now I see, that there is more energy in the meetings, noone thinks they are wasting time, and we actually get and feel the value of the meetings.
At GOTO Copenhagen 2016, Corey Haines gave a talk with the title “Inspect and Adapt, then what?”. One of his keypoints was: “If something in my process is not working, my first thought is to remove that something from the process”. He used the example with estimation. The team felt they were wasting time estimating, so they asked themselves “Why are we even doing estimation?”. Since everyone was not convinced 100% that skipping estimation was a good idea, they decided to run a trial period. For 2 months. They even scheduled the meeting on which they would make their decision. This made everyone commit to the experiment, because they knew exactly which date the experiment would end, and if it didn’t workout, they could always go back to what they did before. They found, that estimation was not of value to their process in the context in which they were working. They did not estimate from there on.
My own experience tells me that Corey Haines Theory – Removing the part of you process that it not working – is in fact a useful approach. It fosters a constructive dialogue of “Why we should do it” or “why we shouldn’t do it”. An important step for agreeing on what to actually do. Making it a Time-boxed experiment, with a set date of when you’ll make the final decision, is something i would definitely be using myself, as it will create space to “try” changes, instead of “just talking about” changes.
Agile Reflections 