Background: We are trying to adopt Scrum in my current development team. One of the action items is to hire a ScrumMaster to help us in the Scrum implementation. But there are some articles suggesting it's a waste of money.
In order to convince the management to hire a ScrumMaster, I need to know the benefits of having a ScrumMaster.
How will such help us in the Scrum implementation?
Note also that according to him,
the best thing we can do is to throw Scrum onto the garbage heap of history.
So if you believe a short blog post showing no factual evidence to support his claims, then not just hiring a Scrum Master (SM) but the whole of Scrum is a waste of money. Hence stop adopting Scrum asap and go back to the good old process you previously used (or search the author's blog site for his silver bullet method).
We can start to analyse the post a bit. To me his main point seems to be that the vast majority of existing SMs spend their time fighting fires, and don't have time to what he claims to be the main role of SMs, which would be interacting with outside parties and help optimizing their interactions with the Dev Team. IMHO the relevant quote from the Scrum Guide is taken out of context. Interacting with outside parties is definitely important, however it's only a part of what a good SM does. Other chores include
That's just what quickly came to my mind, surely a lot more could be added. It's certainly true that if an SM spends almost all his/her time doing only the first of these, it is a problem. However, in the best case it may be a temporary problem, and once the crisis is over, the SM may return to a more balanced activity pattern. On the other hand, if the crisis is permanent, I wouldn't say it's a problem with the role per se, rather with the environment where there are so many impediments and/or removing them is so time consuming that it takes up all of the SM's time. And if you have that problem, it is going to bite you with or without SM, and with or without Agile.
My firm belief is that a good SM is worth his/her price many times over, as without SM, the team may just never get even close to reaching their potential top speed and efficiency. If the SM can help the team double their productivity as well as customer satisfaction in, say, one year, was it worth that one extra salary? Of course, missed opportunities are hard to quantify as they never show up in the balance sheet the same way as salary expenses do.
Try to find a good SM with a proven track record and challenge him/her to bring the best out of your team. You may agree to establish a trial period of a few months, during which (s)he assesses the team and you assess him/her. After that, your SM may be able to predict more accurately just how much better your team can get, and based on that you decide whether you want to continue working together.
All this is not meant to say that Scrum is faultless - it has its limitations and problems for sure, and it may not suit all teams and all products. There are other Agile and Lean approaches as well, like Kanban or XP. I think what is important though is to understand that all of these require a big shift in both developers' and managers' mindset, communication and problem solving approaches, which does not come easy and fast. So my suggestion is to make your due research, pick the process which looks most promising to you, get a good coach to help you adopt it properly, and give it enough time to see whether and how it really works. In my experience, most of Scrum adoption failures are due to people not fully understanding the mental shift required and the depth behind its seemingly simple rules.
Disclaimer: I am a Scrum Master myself, striving to prove day by day not being a waste of time :-)
The Scrum Master should also a part of the Project Management organization
The Scrum Master's deliverables should include agile measurement reports / charts that depict fine-grained aspects of each teams' work.
These reports should aid engineering managers, and possibly project managers, regarding where the employees on their teams can improve.
These reports should reveal how the planning, estimating, etc processes can be improved, timebox-to-timebox, or in some other Kanban window
This is really a kind of 'human engineering'
Bringing someone for this role may be appropriate because no one on the related team has the charisma or presence to keep the meeting in order, moderate disputes, etc. This personality characteristic is incredibly important for the role – regardless of whether you carefully word that fact to parties who may need personal development to not feel 'wounded' by hearing it.
I recommend that you "hire for" this role only if the person is thorough-integrated in the org. If their job is only to 'scrum master' one or more teams, then likely this is a waste.
