How to deal with sub-optimal implementations of SCRUM

What if you are not aligned with your teammates? It can be challenging sometimes when team members have different interests and are on different levels. I have been on teams with a natural click between team members and team members shared some interest and a drive to improve and I have been in teams where the cohesion was less than standard, so to speak. Roughly 75% of the companies claim to use Scrum. I am curious what percentage of that actually implemented it the way it was intended. Since more than 50% of the projects and teams I worked in did an interpretation of its own, it could very well be that 50% of that 75% is not getting the most out of using Scrum.

Joining existing Scrum team

When you’re joining a running Scrum team, it can sometimes be hard to find your way and be of any influence. Especially when the team and, more importantly, the organisation did not implement Scrum as described in the Scrum guide. In my experience, I have seen a couple of different scenarios. From teams with a project manager as Scrum Master, teams with a Product Owner that has little or no connection with customers, teams who take hours as story points (or worse instead of story points), releases once every couple of months until teams with little or no ceremonies at all. As the new guy, within these teams, it is sometimes hard to turn things around. Most heard reasons are “we don’t need it”, “it’s overhead” and “we’ve always done it this way”. It really feels like that they don’t understand the essence of Scrum. This can really be frustrating and demotivating.

Learning is pain

Well, for me that is one of the things I had to turn into learning points. Because it is not only frustrating for me, other team members can get easily annoyed by a new member telling them how it’s supposed to be done.
So first of all, I have learned that you should start small. I used to start nagging about everything that was implemented wrong in my opinion in an unsubtle way. Not the smartest thing to do, since people can be sensitive to criticism.

In the past, I have joined what I call a challenging Scrumbut environment. The organisation implemented Scrum but does not acknowledge it’s rules and roles, does not empower the team to be self-organised and therefore a great deal of the power of Scrum is lost. Even worse: when deadlines are not met, Scrum is the one to get blamed.

How to deal with this?

Stay positive. And in order to get things moving the right way, you will have to gain some trust. So one day, when a lot of people were off and most of the work was done already, I saw a change to suggest the first try-out or pilot. Since we were lacking all sorts of Scrum ceremonies (we only did planning and stand-ups), I suggested doing a Sprint Retrospective. Retrospectives are the place to look back on the process as a team but also on its behaviour. The goal is not to criticise people personally, but to find places where we can improve ourselves and, most importantly, the team. One thing I notice in the talk about if we should do a retrospective, that people are just afraid to be confronted or personally criticised. The key is here to convince your team members that this is not the goal. So prepare an introductory talk of about 5-10 minutes where you explain the purpose of the retrospective and then just do it. Make sure that everybody has a chance to talk and that team members respect each other while explaining their (suggested) points of action. After that, try to get in recurring on the agenda.

Conclusion

When you are facing challenges in your Scrum team and organisation, the Sprint Retrospective is the place to ventilate your thoughts. Try to avoid direct criticism and stay positive. When the Retrospective ceremony is not implemented (and you are technically not doing Scrum), suggest to try it out sometime. Start with no expectations, aim on gaining trust and move on from there. And remember that a lot of the points to improve can subject you since you are the one that is trying to improve change things.

3 thoughts on “How to deal with sub-optimal implementations of SCRUM

  1. Thomas Verschoof Reply

    Hej Bart,

    Great insight. I’m facing the challenge of willing to try and implement scrum altogether in a team that isn’t a team at all. They are more a bunch of individuals who are solely focused on doing one task that is thought out and estimated by their project leader.

    At the beginning of this year, we tried to at least use an agile methodology using Kanban. Our project leader is telling great stories about how he now has a much better overview, even though he is mis using the Kanban board and there are little to no discussions about what tasks, or rather epics, should be deconstructed into smaller tasks, and what estimated they should get.

    It is really starting to demotivate me because I tried to show them the benefits of using the Kanban board, like how we can have a shared overview so we know what lies ahead, and just as import having an overview of work that is done. Last project meeting I even heard team members complain about not knowing how far we are with the project. They expected their project leader to have a road map ready, but at the same time they don’t see the benefit of sharing what progress they made in between meetings. “Why would other team members need to know what I’ve done yesterday?” was something I am literally quoting right now.

    It feels a bit like your story, at least like the whole scrumbut scenario but we are more of a kanbanbut. I am the external (new) guy, waving around with project methodology slang and how we could improve our project’s processes. That lead us so far that we are using Kanban, but actually only as a sort of facade to hide the issues we are having as a team, or rather, as a bunch of individuals…

    • Bart Numan Post authorReply

      Thanks for your comment and, yeah, it sounds pretty similar. The hardest part is implementing continuous improvement. Because getting the methodology there in the first place can be exhausting (for both you and your unwilling team members). Normally after an iteration, you will do some sort of evaluation like a Sprint Retrospective in Scrum, where you will come up with some things to improve. It’s hard to cope with that, while your team members are not all in and believe what you believe. It is all a matter of collaboration and trust. My next post will be about collaboration, so keep an eye on my blog, it will be live soon!

Leave a Reply

Your email address will not be published. Required fields are marked *