If you are a Scrum Master already you definitely had this question addressed to you. If you are a Product Owner or Developer, I am sure you have asked yourself “what is this person doing all day?”. If you are a manager of any kind (i.e. Project, Process, Delivery, People, Coffee, ‘I am a manager, but don’t know what I am managing’) you ‘ve asked the question “what is a Scrum Master?”.
Let’s just forget for the moment the various types of “managers” and concentrate on the actors who hopefully have an understanding of the Scrum framework. So far the dominant opinion on the matter is that a Scrum Master is needed for new teams and as soon as the team reaches a satisfactory level of self-organisation and awareness (whatever that means) then The Scrum Master is no longer needed. . Well, it sounds tempting. Especially for “managers” who still refer to people as “resources”.
The reality I have experienced so far is almost identical. The enterprise recruits a Scrum Master to implement the Scrum process. The Scrum Master works with the team(s), explaining how Scrum works. Then after 4-5 Sprints, the team gets the grasp of the framework and then they are able to run the Daily Scrum by themselves, interact with the other teams without asking a proxy etc. So far so good. Should the Scrum Master leave then? Let me ask this first: Does the team deliver every Sprint? If yes, does the team deliver every Sprint according to the DoD? If yes, does the team implement engineering practices that will boost its productivity and ability to deliver (e.g. CI, CD, TDD, Clean Code etc.)? Does the Product Owner act as a Product Owner and not as a Project Manager? Are we getting direct market feedback at least once a Sprint? Does the PO calculate the ROI? Are we working on the most important Product Backlog items first without external interruptions? Does the PO know how to measure and deliver more value?
Now, let’s assume that all questions above are answered with a definitive yes. Then what is the Scrum Master doing all day? First the Scrum Master can have coffee, as to achieve all of these is a significant accomplishment. OK, coffee consumed now let’s answer the question.
Firstly, since your Scrum Team is so successful that will be translated into more revenue. More revenue means expansion, expansion means more recruits. Who can coach those new Scrum Teams?
Moreover, the Scrum Team is usually an island within the wider organisation. which means, that maybe the software development department has embraced agility, however the rest of the organisation has done so yet. And because software development coexists with marketing, sales, human resources, C-Level management we constantly have bottlenecks and queues. It is therefore the Scrum Master’s task to expose those “impediments” using the Scrum framework and the success of the Scrum Team (assuming of course that there is one in the first place). For example, coach Human Resources to hire the right people with the right agile mind-set and preferably change their name to something else. Coach sales to understand the Scrum framework so that they can better interact with the Scrum Team. Coach executives and managers and show them that Scrum is not a silver bullet whose implementation can solve all our problems using Harry Potter’s magic stick. What Scrum does is that it exposes all weak points and then it’s up to the people affected to solve them. In general, seek to create a learning organisation, as continuous learning and improvement is crucial. And last but not least, the Scrum Master should pursue self-improvement as well. Try out new ideas, new patterns for the Scrum events, learn a new skill and never stop questioning and challenging the status quo. What we know today might be irrelevant tomorrow.
To summarise, there is no directive within the Scrum framework about when the Scrum Master should leave. As I like saying, you are free to jump out of the window instead of taking the stairs. But you must first think what is most efficient. If you dismiss your main change agent as soon as some events and task-boards have been established, then be prepared to cope with stagnation. Scrum has people in its core. Yes, it’s true that all the technical practices can nowadays be implemented with the push of a button, but still some people have to press that button. And if these people are not getting out of their silos, then there is a real problem.
NoAgile 