Well to be exact Scrum never really sucks, at least not based on how I see it. But still, sometimes Scrum just doesn’t fit the team or situation, and the best thing to fix it is by not doing it.
For almost a year now, I have been part of a team that is doing mobile development for one of our clients.
When we started, we had a solid approach to do 2-week iterations, we had our kick-off, made agreements on practices and had our first sessions scheduled in the calendar. After this, things started to get problematic.
Chapter 1: The Sprint sucks
It was really good to plan for a 2-week weekly routine, but almost immediately we started to encounter problems where people were not able to attend the scheduled sessions and we needed to find alternative slots. This ended up with having sessions whenever we were able to fit them in, and our iteration lengths started to vary and our capability to deliver potentially releasable content was a struggle. The calendar didn’t work and our iterations didn’t work. One key factor was our client’s hectic schedule. Another was that face-to-face sessions were the most productive, but it was hard to schedule them within the iteration cycle.
In the end, we stopped talking about sprints, planning, or reviews and just started to talk about when we can meet the next time. Now our iteration cycle is based on when we can all meet, and every time we meet we look at what has been done, solve problems together and plan when we meet next and what will we try to do before that.
What this means in practice is that we continuously plan, design and release and in quite regular intervals inspect and adapt face-to-face, and we are super transparent about our progress.
Chapter 2: Stand ups suck
Originally we had regular stand ups with the team, but team members kept having other things that would prevent them from participating and also the mood was always slightly negative. People felt they were a waste of time. First we did the wrong thing and just stopped having them. Naturally, our communication got even worse. We ended up discussing this in one of our retrospectives when one of our teammates said the magic words: “I hate being asked what I am doing!” Ok, so what should we do then? “Tell me what you are doing, and I’ll tell you what I am doing”. How do we manage the discussion? “Lets do it in Microsoft Teams as we are already using it”. In the end super simple, but super hard to figure out.
Now, every morning, the first person who starts working posts to our Stand up Channel what they are working on during that day, and all others answer what they are doing. If there are challenges, we find time to look at them together. If we are all in the same place, then this happens face-to-face. We have continuous communication, continuous focus and high transparency.
Chapter 3: Finding better ways sucks
If we look at the definition for Shu Ha Ri
, a part of me would like to argue that as a Team we are so good that we evolved through Scrum, to something better. But we didn’t. We failed to do Scrum and needed to find another way. Be that the way is better for us, it still might not be better than Scrum, but that does not actually matter.
Chapter 4: Being a Scrum Master sucks
Part of Being A Scrum Master requires that I understand my Team and the team needs, and also the organizational constraints of our clients. In this case, the team needed better ways of working and Scrum did not help. Additionally, our client’s organizational responsibilities made it impossible to ask them to commit to the framework.
It sucks that, in a sense, I failed as a Scrum Master. I was not able to help the client and team adopt Scrum. But if the team is happy, the client is happy and we constantly deliver value, then maybe my failure as a Scrum Master in the end leads to a bigger success.
Well, what does a Scrum Master do if the team is not doing Scrum?
I still facilitate our sessions, ensure that there are no blockers for the team, and support where needed. With the additional time I have on my hands, I enjoy the possibility to work with testing, UI test automation and QA.
While writing this I encountered a new article from Ron Jeffries
(whose way of thinking about this stuff I respect greatly) describing his thoughts on “Agile, Scrum, XP and all that Jazz”. While reading it, I found myself feeling quite confident about how we had progressed.
A while back I had a conversation with a friend from the team where he mentioned something about our Scrum practices. I replied to him that we are not doing Scrum, at least not according to the guide. His follow-up was one of the reasons I started writing this in the first place and maybe the perfect ending as well:
”Yeah, but we are still probably more Scrum than many other teams, who think they are doing it”