What makes a good ScrumMaster 2

Scrum has only three roles: the Product Owner, the Scrum Master, and the Dev Team.

Scrum names three roles because the framework needs all three roles, they are all as important as each other and all are vital to the successful implementation of Scrum.

But of the three key roles the Scrum Master is the least understood and most easily confused.

Is a Scrum Master necessary?, is it full-time?, is it just another name for a Project Manager?, or a team manager? Can we manage without one?

These are just a few of the questions posted endlessly in forums and asked in organisations newly adopting Scrum. [Spoiler – the answers are that if you are doing Scrum right then: Yes, Yes, No, No, No.] As for the mandatory “but we ignored x, y, and z and Scrum worked for us” follow-up comment – I’d say something may have worked for you but it wasn’t Scrum, and unless you can describe what you did in a framework that can be clearly described and reproduced successfully in a variety of situations then your justification for not following rules doesn’t help anyone else. Which brings us neatly back to the need for a Scrum Master to help adopt Scrum correctly. Once Scrum is established, the teams are performing well and have confidence in the Scrum framework then the burden on the ScrumMaster diminishes, but in the early days don’t underestimate the effort required to build a Scrum team, especially in an organisation new to agile.

Confusion

Let’s start with some of the things they are not: They are not the manager of the team; they are not a project manager; they have no authority; they are not an all knowing Jedi master; they are not senior to the dev team or senior to the Product Owner, and they are not the Stig.

The goal of a Scrum Master is to help the team improve.

That’s all, they have no responsibility for delivery of a project, or the quality of code, or testing or reporting, or enforcing good practices, they have no line management responsibility. Their one and only responsibility is to help the team get better.

This can be achieved by teaching, coaching, facilitating, and removing impediments.

It is about influence not authority.

To be a great Scrum Master you need to be the sort of person who gets as much satisfaction from enabling a team to achieve, as you do achieving something on your own – and be content not getting any credit for it, because you won’t. You must also be willing and happy to surrender control to the Product Owner and the team. The ScrumMaster title is a reflection of responsibility not rank. It will quite often be necessary to sit back and watch a team make a mistake, because they will learn far more from that mistake than from you stepping in and forcing them to do it your way.

A Scrum Master is an advisor not an instructor.

A good Scrum Master is a coach, ideally they have a good understanding of good practices, hopefully from practical experience. A Scrum Master that “has been there and done that” is a huge bonus as they can bring experience as well as theoretical advice. The caveat being that they give advice – not impose their own way of doing things.

It may be the SMs role to coach a team on XP skills; or automated testing; or on public speaking; or negotiation skills; or help with story writing; whatever the team needs to improve. It also involves teaching the team Scrum practices and helping them identify where they can improve. The ScrumMaster will likely coach the team and the Product Owner and hopefully broaden this scope to other parts of the organisation over time.

But this is all done without authority, the SM has no authority over the team or the PO, the SM cannot make the team follow Scrum processes, but should help the team understand why the processes should be followed so the team can then choose to follow them.

A ScrumMaster may encourage adherence to rules the team has committed to follow, but cannot impose rules on the team. A Scrum Master should never tell someone to do (or not to do) something, more often you will hear them say “have you considered doing x” or “have you considered the implications of not doing y”. The SM is not responsible for rules being followed.

The ScrumMaster as a coach

A Coach is probably the best analogy for what a Scrum Master does. If you compare them to what a sports coach does for their team. They encourage; they watch and they advise; they guide; they protect from distractions; they can be constructively critical; they identify ways to strengthen the team in skills or teamwork; they push the team to perform to their best; they strive to improve. They also coach the team to manage resources to ensure the right people are assigned to the right tasks on the team – you likely wouldn’t put your star striker in goal, for example, but you may encourage a back-up to be used sometimes to avoid critical dependency issues later.

A Sports coach is usually someone who has a deep understanding, and appreciation for the sport and wants to share this with the team, sometimes they are previous players, sometimes just armchair experts.

How Many teams can a Scrum Master work with?
*An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.

But if you can envision a team that has a great time accomplishing things no one previously thought possible, within a transformed organization, consider being a great ScrumMaster.

A great ScrumMaster can handle one team at a time.

We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.

*(Taken from Mike James ScrumMaster Checklist)

The ScrumMaster is a Scrum Expert

To be a good ScrumMaster you need to be an expert on Scrum, you need to know the framework, but that is not enough. You also need to understand it and to have applied it, Scrum is as much about application as it is about knowledge. To coach it effectively you need to believe in it and be interested in it beyond just training, it is on-going learning, developing new skills and ideas, and discussing it with others, a ScrumMaster should be a Scrum enthusiast.

The ScrumMaster as a radiator

A Scrum Master is also responsible for encouraging the team to be transparent, for radiating information to the wider community, this might be task boards, training, printed roadmaps, burndown, velocity charts, a variety of graphs, even a publicly displayed backlog. Scrum is about transparency and sharing information both good and bad is crucial.

The ScrumMaster as an evangelist

A ScrumMaster is also responsible for spreading the understanding of Scrum to the wider community, for helping the organisation understand the need for continual delivery, and how and why Scrum Teams work the way they do, helping the organisation interact with the Team, and understanding why they can’t interrupt them or why they can’t change direction or add work mid sprint.

Top tips for being a ScrumMaster

Independence – To be successful you need credibility and respect, that is far easier if the team doesn’t know you. You start from a clean slate. If you move from being a dev to being a SM on the same team you take with you a lot of past preconceptions you of them and them of you.

Objectivity – Get involved enough in a project to understand it and to advise, but not so much you are taking charge, your role is to coach not lead, if you feel yourself leading step-back. A lot has been said about having no authority but you do have a lot of influence, try to use it to influence the team to get better not to influence the product.

Take it slow – Improvement comes slowly, try not to change too much too soon, create an environment where improvement is encouraged, and change things one at a time. Not all changes are positive, and not all changes have an immediate impact, but don’t stop trying to improve.

Teamwork – encourage teamwork above all else, a team that works well together will make everything else easier.

Keep quiet – If you are talking then others are not. The Scrum Master should be encouraging the team to discuss and resolve problems not solving them for the team. Before you speak think twice, take a breath and guide don’t direct.

Summary

Scrum is fairly easy to understand but is extremely difficult to master, and being a ScrumMaster in my opinion is a very tough ‘easy job’. The expectations are high, the responsibilities unclear, and the rewards are indirect, and because the goal is improvement the job is never done. At times it may appear to look easy, but I can assure you that when it looks easy it has probably taken a lot of effort to get to that point.

The Confusion Over Story Points.

In my last post I referred to the myth that Scrum Masters can make themselves redundant, the other most common and persistent myth I regularly hear is that Story Points are a measure of complexity.

No, no, no. Story points are just about relative size. That’s it, nothing more. There really is nothing complicated about it.

It is all relative

A small ‘simple’ task is not the same as a large ‘simple’ task. And a small ‘complex’ task that I can have done in a quarter of the time of a large ‘simple’ task does not warrant a higher story point estimate. It makes no sense to estimate that way.

My advice when estimating stories is to pick a cross section of stories, pick around a dozen typical stories of varying: scope, sizes, complexity, uncertainty, and any other factors that might affect the time and effort involved. Discuss them and get a feel for the stories and then sort them smallest to largest.

Next take a story in the middle and stick it in the middle of a white board on a horizontal line drawn across the board. Next take each story and estimate how much effort relative to the stories already on the board mark each story on a number line, hopefully you will get a flow after a while. E.g. The next story is 3/4 the size of the first so i put it 3/4 of the way between the end of the line and the first story.

When all your stories are on the line pick a scale that you think looks right. Just Try it and see, each set of stories will have a different distribution, if you initially pick a number too low and things feel squeezed, just try again. E.g you pick the story in the middle and using Fibonacci numbers call it 13pts where does this leave the rest? Do they fall easily into other Fibonacci numbers? stories around a 1/4 the size of the first would be a 3 and so on.

That is now your scale, and regardless of how your definition of done changes, or the team changes, the relative scale remains.

If you are lucky enough to have a team room with space to leave those stories up on the wall on the scale line that’s great, if not then take a picture. From now on when estimating any story you can say how does it compare to ‘x’, x was a 13pts and this is similar, or this is 50% bigger than ‘z’ and that was a 3 so this is a 5pts. By keeping everything relative to the initial stories and you keep the estimates consistent.

But what about complexity?

Complexity, and uncertainty, or time consuming interactions between layers or departments are all just considerations that affect the size. “That task is complex it may take me a bit longer”, “That task is unclear I’ll need to take some time to understand this aspect of it – it will take longer” all we are saying is that it is just relatively larger, there is no trick to it. It might help make life easy to say – this story looks very similar to 5-point story ‘x’, but has some uncertainty (or I’ll need to liaise with another department) therefore we’ll estimate an 8. It is the fact that complexity adds time that makes it a bigger estimate not anything else, it is just another factor in comparing the relative size.

Comparisons are so much easier than raw estimates.

When estimating new stories all you have to do is pick a story and say: “will this take longer than reference story x?” or “will it be less than reference y?” with enough reference stories there should be a suitable comparator to find a similar sized story and give it the same points value or a bit more or a bit less based on a considered factor. After very short time you will instinctively know the scale and estimating becomes quicker and easier. Your refining becomes a series of comparisons e.g. “this involves more testing than story x” or “it is like ‘y’ but with a bit more to the UI” etc. Comparisons are so much easier than raw estimates.

What about ideal hours or ideal days?

Some teams use ideal days or hours for estimates but that is subject to change according to the team, the team changes and the estimate changes, what if someone is off sick or on holiday? and more confusingly it implies a commitment to a particular amount of effort, what if your DoD changes and suddenly you are writing automated regression tests for each story, suddenly the scale us blown, but a relative estimate is always relative.

Sometimes after a while teams begin to drift, it may be worth having a refresher of the initial stories and initial estimates just to calibrate your estimates periodically, maybe even add new reference stories to keep the scale fresh.

Just remember it is all relative

Just remember it is all relative, and then it is easy!

What makes a good Scrum Master?

The Scrum Master job is proving to be quite an enigma, management seems to struggle to see the value, there are numerous myths about how a Scrum Masters goal is to make themselves redundant which further fuels the confusion of management as to whether they are even needed, others have a view that a Scrum Master role is part time, and a Scrum Master can effectively cover 2 or 3 teams, I even saw an advert recently for a Scrum Master to have 5 teams!

There are endless discussions on Scrum forums about a split SM role a mix of Dev/SM or tester/SM or even Product Owner/SM and each time I wonder if they don’t understand the purpose or the value or have simply had some really awful SMs and just see the role as a glorified meeting chair and someone to do the admin. A good Scrum Master can have a huge impact on a team.

Then the flip side of that is that the job description makes a Scrum Master seem relatively straightforward, but anecdotally in the company I am currently working with there are 7 scrum teams and in the last year they have had 10 people attempt the role, mostly they were just covering one team. The attempts have been a Dev/SM, a tester/SM, a former PM, a Product Owner/SM, a former Dev and a dedicated SM covering 2 teams. Generally speaking the attempts have been unsuccessful, and never as a result of a lack of Scrum knowledge, or the ability of doing their previous role, those selected were generally senior and very capable, but clearly that alone is not sufficient.

Some struggled to balance a split role, some underestimated what the role of SM involved some were too soft, some were too hard some felt that they could not effectively perform a split role and wanted to revert to their former role, others were simply not a good fit.
It seems an odd thing to say but in my opinion the job of Scrum Master is as much about personality as it is about skill set.

So what makes a good Scrum Master? My summary would be two ears and a very hard nose. Most of the time is spent listening, being an advisor, scanning for problems, counselling and coaching, offering guidance when asked. Is essence making use of your ears. But less frequently you need to stick your nose in – even when not invited, and you may get resistance. You may need to challenge senior management, or actions in the team, you may need to intervene in conflicts or resolve difficult impediments, you may need to resolve disputes, and you may need to challenge the team. Hence the hard nose, you have no authority so this is often simply only backed by your personal gravitas, your confidence and the credibility you hold in the team and the organisation.

But even then there is so much more to the job which may explain why it is such a difficult role to do well and may explain why the number of job adverts for Scrum Masters has rocketed in the last few years.

Gravitas, confidence and credibility (and trust)
To be effective you need to be able to communicate with senior management as one of their peers, you need to have the confidence to challenge their decisions and offer advice and guidance for this you need credibility.

On the flip side though, you need to work closely with a team. To be effective they need to see you as one of them, they need to trust you, to be open and honest with you. They need confidence that you will act in THEIR interests and that you are there for them.
They too also need to respect you, if you are giving them advice they need to believe you know what you are talking about and for this a sense that you have been there before and got the t-shirt really helps.

Objectivity
I work with a fantastic Product Owner, he is very well respected by everyone and prior to my joining he did a split PO/SM role. He will be the first to tell you this is a bad combo, but he managed it remarkably well, but had the good sense, the confidence and the credibility to know when to ask for help. (As an aside I think a willingness to ask for help and knowing when to ask is a strong skill that far too many people lack or see as weakness).
He and I see the roles of PO and SM as a partnership, we work very closely together, but that is not to say we don’t challenge each other regularly.

He considers the most significant attributes I bring to the table are independence and objectivity and I am inclined to agree. By being slightly removed from the team and the project, not having responsibilities, or deliverables and not being personally invested in the code or the design I can bring an independence in my advice, my suggestions are not encumbered with an agenda or a vested interest, just a desire to improve the team and do the job better. This may be one explanation why the SMs plucked from the team have struggled.

A final problem that a Scrum Master faces is that there is no measure of success. A successful project is down to the Product owner, he takes the responsibility, shared with the team. Problems in a team reflect badly on the Scrum Master, but when a team is doing well the reverse is not true, the credit – quite rightly goes to the team.

Think of a sports star and his coach, if a sports star does well he is showered in praise, if he performs badly he fires his coach. The team is the talent, the coach is responsible for enabling them to perform at their best. The reward is seeing the team do well.

My final comment is to address the myth that a Scrum Master should be striving to make themselves redundant. Again I’ll compare to a sports team, if you pick the best team in any sport, they have reached the pinnacle of their profession – top of the league, winners of a cup. Do they then declare they no longer need a coach? I doubt it, even the best sportsmen and sportswomen at their peak have room to improve and it would take shocking arrogance to believe there is nothing more that can be improved or learned in any profession and in particular a team context.

The myth that voluntary overtime is commendable

I was chatting to a friend last night, he is a manager of an IT department and I used to manage a software department before I became a Scrum Master so we tend to talk a lot about management techniques and especially how a lot of the successful traditional techniques map to Scrum.

It is performance review time and the topic of conversation got around to a frustrating belief by some staff that working long hours without being asked is something that should have an implied reward.

I can’t speak for all managers, but for the two of us I can say that we consider it to be the opposite, when someone works late on a regular basis without being asked, we see that as a red-flag. Certainly not to be commended and very likely a sign of problems.

I used to pride myself on being a good manager, I felt I was fair and sought to do what was best for my employees and the business, sometimes it was a fine line and often not easy. But one of my strongest principles was to be fair. I would never assign someone more work than I felt they could handle (that is not to say I didn’t seek to challenge them), I would always check they felt it was fair and I would always say very clearly that they should come back to me if they had problems, and I would review on a regular basis usually weekly.

As a Scrum Master the roles are reversed, the team tell me what they feel they can commit to and they review with each other on a regular basis (at the daily stand-up) and keep a track with a burndown chart.

So in either of these scenarios is there scope for voluntary unpaid unrequested overtime? (The answer is No) In the case of assigned work if you cannot get it done in the allotted time then it is a failure of management – either I have incorrectly assessed the amount of work or I have misjudged the individuals capability to do it, and unless I have opportunity to be aware of that I cannot correct it and the cycle will repeat. The same is true in Scrum, the model is built on empirical evidence, if your estimates are low you learn and adjust next time, working extra to meet a commitment hides problems and perpetuates failing cycles, it also causes imbalance in the team, makes pair programming difficult and sends mixed messages to others. Very simply as a manager or a Scrum Team you cannot fix a problem you don’t know about, and commitments are achieved as a team.

So should you reward someone for working late, for their dedication and loyalty? or should they be reprimanded for their lack of transparency, their lack of courage in challenging an inaccurate estimate, their failure to communicate an excessive workload or lack of knowledge/training/understanding to achieve the objective?

If I ask you to work overtime I will do so with a very heavy heart, I know that it is not good for you, or the business and any gain is short-lived. It will only be in exceptional circumstances. So if you do overtime which conflicts with our team plans or expectations please don’t expect to be rewarded. That may sound harsh but I value communication far more than you giving extra to offset a failing elsewhere.