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.
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.