Being both a Certified Scrum Master and a senior freelance developer has some cons in itself. When you’re asked to help a company with their project, sometimes you end up as a member of the Scrum team.That gives you the opportunity to watch other Scrum Masters working, but also to improve your own skills based on others’ mistakes. Here are 10 things that Scrum Masters tend to do wrong while implementing Scrum in their organisations:
- Scrum Master: I will help the team with their work because I used to be/I am a very good programmer/manager Although Scrum doesn’t clearly state that the Scrum Master cannot be the part of the team, it has twice happened to me that Scrum Masters ended up doing work in the project without officially being part of the team, having their own work etc. That is not only wrong in terms of misjudging work involved in a single Sprint and causing problems with estimation (do we have +1 team member or not?) but it is also very distracting for the team. In addition, it takes the “self managing” attribute away from the team as the Scrum Master is supposed to be the authority in Scrum. But being the part of the team makes the other team members think of the “authority” of the team rather than the correct authority of the Scrum process. It is really hard (and I can tell from my own experience) to distinguish SM role from an active role in the team for someone who knows how to do stuff. But without it it’s really hard to achieve good results because the team will never understand what the real role of Scrum Master is and therefore won’t be able to focus on their own work but will look constantly to the SM for help in development.
- Scrum Master: I will assign tasks as the team is very slow in deciding what to do This is a very common mistake and I must confess that over two years, I’ve only met one Scrum Master that has not done it. The team, especially in early Scrum development stages, is often not used to coming up with their own tasks. For years there was always someone telling them “you do this, you do that”. To change that requires a lot of work and skill from the Scrum Master, but often that work is replaced with impatience. I think this happens for two reasons: according to Scrum, Sprint planning should take up to 8 hours for 4 weeks’ planning. Firstly, for most companies new to Scrum, a 4 hour meeting (for a 2 week Sprint) is just a waste of time; it’s 4 hours multiplied by team members, Scrum Master, Product Owner =$xxx. Too much to invest. Therefore, the Scrum Master is often under pressure (also from the busy Product Owner), books shorter meetings and so cuts the creativity of the team. Secondly, the team hates long meetings. Imagine developers in an 8 hour meeting. There is Scrum Master role needed, servant leader, the coach. As my Scrum instructor, the brilliant Rowan Bunning, compared, the Scrum Master is like a football coach (soccer for some people): he doesn’t play but he makes sure that every team member plays their best. In a planning meeting it’s up to the Scrum Master to make sure that team members have enough time, courage and will to create their own tasks to complete the Sprint goal. It is also up to the Scrum Master to make sure that the Product Owner attends the Sprint planning session, explains everything about the Sprint goal and answers every question. Instead, I’ve seen many impatient Scrum Masters with a lack of Sprint planning organisation ending up starting the Sprint with “we need to do this, so how about we’ll start from doing this first. How long will it take”. This is not only wrong in terms of Scrum, but the Scrum Master often takes the developing authority from the actual developers by misjudging what needs to be done.
- Extending Scrum Time to meet Sprint goal This is perhaps not very common practice, but I have witnessed it with one Scrum Master in a large New Zealand organisation I met recently. Scrum Masters are often mistaken for Project Managers. Therefore the organisation puts a lot of pressure on them to finish projects on time and within budget. So what happens if the team can’t attain the Sprint goal on time and can’t demo the expected product at the Sprint Review? Naturally, we demo finished user stories and move the rest of them to the next Sprint. But in this case (I must say I attended only 2 sprints) both times we never knew when the Sprint would finish because the Scrum Master kept postponing the end of the Sprint to achieve something that the team could show to the stakeholders. This not only created great confusion in the team about how a Sprint should work, but also slowed down the work because a couple of days before the end of the Sprint, we heard about the extension and instead of focusing on finishing the stories we had, we then had to finish all stories instead, creating chaos in the workplace.
- A Product Owner who will give you “most” of the decisions
This is a pearl in my Scrum experience. Again I have just one example but it’s priceless, and I guess easily repeatable. This was in a big organisation, with a large number of managers and stakeholders (probably larger than the whole Scrum team) – and a Product Owner responsible for most of the decisions around the project. I said most, but not all. Since graphic design was a different department, the graphic designer consulted with someone else. Since architecture was important for the company, so the developers asked about functionality from the IT Architect. And so on and so on. The Product Owner was actually not even needed, because what’s the point of having one person taking care of a product if he/she can’t make all of the decisions? Of course, it’s not possible that the Product Owner will know everything, but his/her responsibility is to find out the answers to those questions rather than sending team members around asking the next person and the next to get an answer. This caused a lot of time wasting, and also…
- Inviting stakeholders for Sprint Planning Powerless Product Owners can’t answer all questions, therefore they can’t fulfil their role at the Sprint Planning meeting. Therefore the Scrum Master, instead of working with the organisation and the Product Owner to solve the issue, invites all stakeholders to a Sprint Planning session. I attended (and I’m not joking) a Planning session where there were more stakeholders than team members! And each had their say. Listing the issues connected with that is unnecessary as they’re obvious but the main one is creating an even greater confusion over who actually is the real Product Owner and who do I, as the team member, ask the questions I have about the project?
- Inviting Scrum Master and Product Owner/Stakeholders to vote on estimating tasks
This is a more common problem that I’ve come across. Although it is allowed and even encouraged for the Product Owner to ask about estimates the team makes, it is not allowed for anyone outside the team to estimate tasks they assign at the Sprint Planning session. The perfect Scrum Team is a team full of trust and faith in each other. That team develops amazing results, often exceeding expectations. But to do that the team needs to feel that they can estimate the value of the task exactly as they agree between team members, no matter how big or small the estimate will be. That way, we’re getting real estimates. Inviting the Scrum Master, Product Owner or even (as I saw once) stakeholders to vote creates a psychological barrier in team members’ heads that the estimate has to be satisfactory for everyone rather than realistic.
- Running Sprint Planning before Sprint Review As a Scrum Master or any company employee you can probably name multiple situations where organising a meeting with many people has been a nightmare. Someone’s busy, someone’s on leave, and so on. Likewise, the end of each Sprint, with a day full of meetings, is hard to organise for any Scrum Master, especially in the stages of developing Scrum. But it is up to the Scrum Master to make sure that these meetings are in the right order and well organised. Sprint Review has just one stakeholder compulsory at the meeting: the Product Owner. Other stakeholders can but don’t have to attend the meeting. So even if they’re CTOs and people responsible for the Scrum Master’s salary, if they can’t attend the meeting do not wait for them as they have no use in the Scrum team. So at the end of the Sprint, meetings should ideally be in this order: Sprint Review, Sprint Retrospective, Sprint Planning. Although Scrum doesn’t say when the Sprint Retrospective should be, I like to have it between the Sprint Review and Sprint Planning Sessions. That’s so that if the team didn’t like something in the last Sprint we can easily improve it in the upcoming Sprint at the next meeting. Also, if you run the Retrospective after Planning and there’ll be many negative feelings about the current Sprint, it might be too late to change anything before the next Sprint and the current sprint will be left on a sour note. However, the worst practice I ever came across was running Sprint Planning before Sprint Review due to the lack of time of either the PO or the stakeholders. That way, we not only don’t know what’s approved before we start the new Sprint, but also we might need another planning session after discoveries from the Review session.
- Running Sprint Planning without Product Owner For new organisations, the role of Product Owner is a very difficult one. Ex-Product Managers are used to being really busy, running between meetings and ordering new products from the development department. Scrum changes that role significantly. The Product Owner not only has to work closely with the development team, but also has to be available on request to answer questions. Therefore, one of the big sins is Product Owner unavailability. During the Sprint it slows down production and often leads to misinterpretation of tasks. But the worst possible sin is to run Sprint Planning without the Product Owner. The meeting that 50% of which belongs to Product Owner to discuss, describe and explain the incoming Sprint’s goal can’t exist without the PO. And believe it or not, as a team member I attended two Sprint Planning meetings where the Scrum Master was playing the Product Owner’s role because the meeting clashed with another appointment. We ended up assuming most of the stuff and the Sprint was one massive disaster. Not even mentioning that for about 50% of the Sprint the team didn’t do anything because they didn’t really know what and how.
- Hearing issues on Sprint Retrospective but not finding solutions Unfortunately, this is often the problem of new organisations and a “patronising style” from the Scrum Master. “I acknowledge problems, we’re going to work on it”. Inexperienced Scrum Masters and especially the ones with managing experience tend to take criticism personally as an attack on their position. It’s really hard with managing experience to separate the role of manager from the new role of servant-leader. And it’s really hard to build trust among the team members if the Scrum Master cannot admit that something went wrong. Nothing works perfectly in the first iteration, which is why Scrum runs Retrospectives after every Sprint. As Derby and Larsen say in their well-known work, the Retrospective is to “make good teams great”. So for each Retrospective, make sure that you not only listen to the good/bad things about the last Sprint but that you’re always providing solutions; even if you’ll have to limit reporting problems, it’s better to listen and solve 20% of them on one Retrospective rather than listen to all of them but run out of time (or willpower) to solve them.
- Scrum Master managing work This is not a single example. Many Scrum Masters (including me) come with the baggage of managing experience. When you are a manager you have full control of the team, starting from their work, and finishing on their salaries and annual leave. But as a Scrum Master you have to learn that most of those powers are taken away from you. Instead you have a much bigger power – the power of convincing, the power of coaching. Now your tools are less physical but more psychological. So seeing all of those Scrum Masters assigning work or judging team members when they won’t do their task in the estimated time is really concerning. Remember, the team is self-managing and no matter how bad or good they’re doing, they should and (you have to believe that) they will solve it with your help. But not help with how to do their job, but with the direction of where to look for an answer.
Over the past two years I have worked in/with more than ten different New Zealand companies and I’ve met quite a few certified and non-certified Scrum Masters. And don’t get me wrong, the above examples are not taken from one individual, they are a collection of experiences that I have had working with many different Scrum Masters. There are many great Scrum Masters out there and there are also some who need to work on their performance. But I’d like to think that all of them really want to improve not only the team, not only the process, but also themselves as Scrum Masters, which is why I’ve given my thoughts here. What other issues with Scrum implementation have you seen?