Old joke…

I heard a joke today, probably stolen, adapted, evolved and old. But it made me chuckle.

“What is the difference between and admin assistant and a Scrum Master?”

Answer – “about 50,000 a year”

It made me chuckle because I have spent the last month or so ‘discussing’ with HR why a Scrum Master should be a senior grade, but all of the objections were on the basis that a Scrum Master was merely a facilitator and admin assistant. Explaining was fun, and eventually they agreed to the higher grade.

But the reality is that a large part of the job is unglamorous, it is admin, it is chasing people, it is watching for anything that stops the team performing and often that can simply be making coffee, or booking meeting rooms.

I have come to the conclusion that a Scrum Master could be described as a team manager that has learned to supress their personal ego, and that it is about doing whatever it takes to enable the team to succeed and if the most useful thing you can do is make coffee then be proud you can be part of the team. It is about forming a good team, then trusting the team to deliver and getting out of their way, not forgetting of course keeping any obstacles out of their way.

The reality is that sometimes the Scrum Master challenges are trivial, but more often they are subtle and challenging and require a lot of skill, deep insight and a bucket load of experience to resolve.  It is one of the toughest jobs to do well and deserves every penny when you get the right person.

The value of a ScrumMaster

In June 2014 a new ScrumMaster was brought in to work with an existing and established development team

At the point of joining the team had already raised concerns about environments and tools but the team had been unable to express specific issues that could be resolved, these problems had been intermittent for most of the year.   The team was composed of a BA acting as Product Owner, a Lead Engineer, three other developers and two testers with the addition of a ScrumMaster this made a team of size 8, which equates to an approximate cost to the business of around £600,000/$1,000,000 a year.

The team measure their productivity using a term called velocity, which is how much work measured using a relative scale is achieved over a period of time. The amount of work fluctuates for a variety of reasons, holidays, sickness, bugfixing, mistakes, environmental issues, focus or context switching, support requirements, spikes etc.  It is an anecdotal estimate of productivity only. But has become the industry de facto standard for measuring improvement. This had been recorded over the previous year and the documented average for the 12 months preceding the new ScrumMaster is noted below as 100 basis points per week.

Velocity can only be used to compare a team with it’s own past performance, i.e. it is a relative scale, not an absolute measure but in that context it is very useful. But should be used with caution. In this case the team had an existing Datum and a set of benchmark stories. The Datum was not modified and the benchmark stories remained in this period, thus there is a consistent base level for comparison.

Year 1 (Prior to ScrumMaster)

image001

The new ScrumMaster, spent some time with the team, observing and evaluating. He sought to identify problem areas and any behaviour in the team where improvements could be made. But unlike a conventional manager or trouble-shooter he did not issue directives on changes to behaviour.

The team scheduled regular ‘retrospective’ meetings where they review the past time period and look for ways to improve.  The ScrumMaster used a variety of techniques, to coach and guide the team to focus on areas identified either by the team or by the ScrumMaster as problematic or where improvement could be made. The ScrumMaster collected and compiled metrics to aid this analysis, and facilitated meetings to be productive in deconstructing problems in a non-negative manner.

By using this approach the ScrumMaster did not solve the teams problems, he did not offer ‘his’ solution to the team, nor issue directives for improvement. The ScrumMaster worked with the team to enable them to become aware of their problems and the ScrumMaster created an environment where the team were empowered to solve their own problems. The ScrumMaster uses his past experience to identify problems and may steer the team to suitable solutions, but relies on the team to solve their own problems.

In the following quarter there was a notable upturn in velocity (productivity)

Year 2 (First quarter after ScrumMaster)

image002

The ScrumMaster is responsible for creating an environment where the team can reach a long-term and consistent performance – a spike or a blip is not considered sustainable, so it is important to not seek to boost productivity with short-term fixes like overtime or cutting quality. The aim is sustainable pace and sustainable quality over the long-term.

The ScrumMaster continued to work with the team identifying more bottle-necks and waste, removing impediments and coaching the team how to work around impediments or resolve them themselves, there is always room for improvement in a team.

The ScrumMaster also spent time coaching the Product Owner and Programme Manager on expectations and in their interactions with the Scrum Team, including challenging the Programme Manager on how his priorities are fed to the team so that the team could focus to be more effective.

Year 2 (First full year with new ScrumMaster)

image003

Velocity is only one measure of productivity and is largely anecdotal, however it is the only real measure we currently have available.  The productivity improvement should be considered in that context. However, there is a clear and notable improvement in the productivity of the team over the 12 month period.  The team deserves the credit for the improvement as they have improved themselves.  But by adding an experienced ScrumMaster to an existing team he has been able to coach the team into identifying ways they could improve and in doing so doubling their productivity – a significant change in just 1 year.  In this instance it could be argued that the ScrumMaster’s coaching of this one team has resulted in £600,000/$1,000,000 worth of added value to the business and assuming the team does not regress this is an ongoing year on year gain. 

It is not often possible to measure the impact on a team, and velocity is a fragile tool for that, but I hope it is clear from these metrics the value that one person can have on a team.  It is highly likely that Year 3 will not have the same growth but even if the new velocity can be merely sustained the value to the organisation is significant.

Live to work, not work to live.

It is often said that happiness is about finding balance in your life, sometimes this means making time for the different aspects of your life, work, hobbies, family and so on, but what if balance is achieved by taking pleasure in all these endeavours? Not simply making time for each but making sure each is fulfilling in its own way.

Too many people seem to suggest that they dislike work, or that it is a chore to be endured for the pay cheque. I find this an odd perspective. Why would you spend 40 hours a week, every week, doing something you endure? Chances are you spend more time at work than anything else. 

I am very lucky, I have a job I love, although I also love my bed and find getting out of bed on a morning difficult sometimes. But once I am up I am itching to get to work, I have ideas and plans and normally can’t wait to get started, at the end of the day there is usually more I want to achieve and it is only self-discipline that makes me come home at the end of the day, I set myself a time box on my working day to avoid taking on too much or allowing work to take over, I try hard to only rarely exceed it, this is a personal choice and I’m aware is not common but works for me and is something I encourage in teams I coach. 

I have covered this before but being clear on what you can achieve in a working week is vital. To quote Dickens.

“Annual income twenty pounds, annual expenditure nineteen pounds nineteen shillings and six pence, result happiness. Annual income twenty pounds, annual expenditure twenty pounds ought and six, result misery.” Charles Dickens.

My philosophy is similar – if your workload can be achieved in the time available the result is happiness, if your workload exceeds the time available the result is stress and unhappiness.

If you work extra hours to get the extra work done, the result is that next week the work will grow more and then more, until at some point you will collapse or be forced to set a limit, so set the limit now where you are able to do so objectively.
When it comes to job satisfaction it is fair to say that my job is not saving the world, I am not doing something overtly exciting or grandly creative, the teams I work with are about streamlining business processes to increase automation, reduce errors and reduce staff to save the government money, as a 7 year old I was hardly saying “when I grow up I want to save the government money”. But nevertheless I love my job, I work with some really nice people and we are working hard to do a good job. I take pleasure from achieving goals, and especially seeing teams and individuals develop, I take particular pride when my advice or coaching bears fruit.

Life is shaped by experience and I have found that no matter what the work there can be pleasure in it. In the past, I have been a debt collector, I owned and ran a small retail bookshop, But I have spent most of my career in software development, some interesting projects some much less so, but it has been only rare occasions that I haven’t enjoyed work. My first post-university job was with Bell Labs working on GSM, the established guys got to work on the roll-out of GPRS, but the new guys got the ‘dull job’ we had to fix bugs on an old C++ Unix system, but it wasn’t dull at all, we had a largely absent boss so we mostly organised ourselves, every bug was a puzzle, a challenge and a learning experience (I hope that doesn’t sound too pretentious because it really was enjoyable) we had a small team that were great fun, we would lunch together most days, we had a pretty poor softball team that played in a league and lost most of the time, and we often socialised together, because work isn’t just about the work it is about the people. 

My worst experience was also at Bell Labs, the team had an ambitious boss, he wanted a juicy high profile project and so he turned down anything that didn’t fit this requirement and so the team went through an idle period where we quite literally had nothing to do, it was sole destroying, we would come to work for our required hours but there was nothing to do, we read, and looking for training, we talked and we played silly office games, we formed a league for Ball-in-the-box a game where we threw a mini American football the length of an office to bounce into a photocopy paper box, after many hours playing we became quite adept. But what we were not allowed to do was work on something, we had to be ready for the next plum project.  Thankfully a senior manager saw what was going on, and transferred the team to UMTS (3G) this was a lifesaver the morale was getting pretty low.  I find it odd that my worst experience was where I was paid to do nothing but chat have fun and play games, for me at least I get pleasure from being busy and doing something I see as productive and valuable. 

Perhaps the most influential aspect in anyone’s life is their parents, I was a “vicar’s kid” or “son of a preacher man” etc etc, my father was a minister of religion and I was the 3rd of 4 children, the only boy, as a result I have developed a pretty strong rebellious streak, but what surprises me looking back is how much my father’s work has influenced me, as the leader of a church he was an archetypal servant leader, a church is a voluntary organisation, the minister is employed only with the support of the church and he has very little power, his job is to lead and to serve. It is extremely challenging and often unrewarding. 

So now like him I am the servant leader, only in business, I see myself as having two roles one to serve the team and one to lead them to achieve, and what I have learned is that it is important to create an environment where your team can enjoy work, this is a paradox for many as the assumption seems to be that if you are having fun you are not being productive, my experience is the opposite – not being productive is no fun at all.  

Make work an enjoyable place to be and people will work harder, make them feel invested in the organisation and they will work harder still, create a team spirit and collective sense of purpose and they will amaze you.

Trust is often lacking and this is a real sticking point for many managers and businesses, but my opinion and experience is that the normal situation is that people have an inherent desire to work hard and achieve and give the opportunity they will, what often prevents this are people or processes that restrict or control, managing should be about setting goals and guidelines, creating a framework to achieve not a culture of control.

My number one piece of advice for a ‘task’ manager is to give a team a clear goal and stand back, you will be amazed. 

Your only three jobs as a leader are to remind the team of the goal, to remove any obstacle in their way and most importantly  to Trust them. 
As an aside for business leaders I’d also suggest if you want to build and retain an effective happy and productive workforce, to indulge them (sensibly) make them feel valued, give them the best tools – generally whatever they ask for, the cost is likely a fraction of their salary and tiny compared to recruiting and training a replacement if they are lured away, give perks – for example issue everyone an iPad and a pluralsite subscription, this costs very little(and is tax deductible) in comparison to an average salary (far less than 1%) but I’d bet your team would feel valued and would broadcast what a great employer you are, and chances are they might even do some training too. Provide coffee and snacks, encourage social activities, make time for the team, if people feel it is a great place to work recruitment becomes easier and they WILL work harder. And lastly pay more, especially to those that have proven themselves, being generous early saves a fortune later, if you are not paying your best people well above average it is inviting them to leave.

Back to Scrumdamentals

It has been a pretty difficult few weeks for me, busy, busy, busy and frankly more management than coaching. Cue air violins!

In the division I am working in there are three Scrum Teams, up until now I have been responsible for two and the third has tried a number of ways to accommodate the lack of a Scrum Master, one member of the team took on the role for a while on top of their other duties and a Project Manager took it on for a while, again on top of other duties. But these part-time roles have been unsuccessful and I was asked to take on a third team.

I was very reluctant to dilute my other responsibilities and expressed this to the department head, and so we agreed it will be temporary and I’ll be training a new Scrum Master for that team to take over in a few months. Which is great but also means I now have responsibility for three teams and training of a new SM, and we will be losing one extremely valuable member from a team.  As I say Cue violins, but my concern is not just workload, it is the teams themselves, one of the teams already feels I don’t spend enough time with them and spreading me thinner wont help with that. So that is problem 1, 2 and 3 but my other and now more serious problem is that the final team is in a state of flux.  The Product Owner has moved on to a new role and it has been difficult to find a replacement.

A Product Owner is a difficult role, and seemingly undesirable. The product is essentially a suite of very closely integrated sub-products with what is intended to be a single front end, the product cannot easily be split because of how closely coupled it is, but the system is so complex there are at least three Business Analysts and an Architect who when combined cover the understanding of the system. The chief architect is ultimately the product owner, he makes the call on the roadmap and the priority of content into the system, but doesn’t have visibility of the fine detail at an individual story level, that is down to the BAs who are doing it on top of their other responsibilities. So prioritisation is at Epic level, with the BAs prioritising the smaller individual stories.

And to cap it all we have hit a spate of recruitment and retention issues. We had decided that the volume of work was such that we would expand and have a second team on this product, but over the last few months two contractors have left, primarily for family reasons (and higher rates) and a very experienced member of the team has got a promotion so he too has left, and as I say another team member has volunteered to be trained as a ScrumMaster, all told a major impact on one relatively small team. So I have been very very busy recruiting (30+ interviews over the last 3 weeks). I have spent the last couple of weeks almost exclusively interviewing and screening CVs. Thankfully offers have been made and I’m hopeful we will have a new team up and running in a few weeks.

But it is essentially a brand new team; a new Product Owner Dynamic; and a major new piece of work.  A new Product Owner, and 3 new proxy product owners(Business analysts) a new Scrum team comprised of a former tester and 4 new former developers (I say former as once in a Scrum team I hope they will all see themselves as a cross-functional team).  All this got me thinking. At first I was anxious about the disruption, I am also anxious that the Product Owner representatives are not dedicated to what is a major product, but after some thought I realise that disruption is the wrong word, the team can’t really be disrupted, there isn’t enough left of the old team to call it a disruption.

New Structure

What we have is a fantastic opportunity, we can create and build a new team from scratch. It is not often you get to join a team at the beginning and are able to shape it to be the team you want to be a part of, usually it is a case of fitting in. But the new team members are joining a high profile new product together and get to shape it as we collectively see fit.

All of the team have had some exposure to some form of agile development they seem strong developers and eager to use Agile, so there will be a degree of Scrum training and coaching but for me the crucial task is to build a team first, get them working together, learning strengths and weaknesses and growing into a team.  I still have a lot of worries, especially about growing a new team whilst also supporting the existing teams, I cannot give the teams as much attention as I would like, but I am actually pretty excited about the prospect of helping build a new agile team.

I have been trying to think of a good place to start, no doubt the level of Scrum training will vary so I thought that I might try a combined Scrum Training and team building exercise. My train of thought led me to http://www.lego4scrum.com/  it is my hope that when they get on board, I will set up a session for them and mix it up with the other existing Scrum Teams. I plan to write up a review after the event which I will post here.

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.

Scrum Master

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.

Story Points 1

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.

Story Points 2

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.

Story Points 3

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 ‘Zone of Acceptance’

One of the challenges of an Agile Coach, or anyone in a management or leadership role is establishing what I have seen referred to as the “zone of acceptance” for individual team members.

The Zone of Acceptance is a term for the tasks an individual sees as something they are prepared to do as part of their job.  This can relate to tasks, overtime, meeting attendance and more.

In a traditional model where work is explicitly assigned, this took the form of a team member saying “that’s not my job” when asked to do something on the periphery of their role. E.g. being asked to write documentation or attend a meeting outside core hours.  This is a confrontation that can be handled directly, the team member can be coached to broaden the scope of their ‘zone of acceptance’ and have it explained that sometimes responsibilities extend beyond core hours or core responsibilities.

However, when you move to agile it becomes much harder to deal with.

As an aside, in my house I will sometimes come home to find the kitchen bin full or overflowing, if I ask why it has been left like that my wife with very matter of fact reply – That’s your job.  I don’t doubt that it is, but it is a hard line, if I want to challenge it I can, the responsibility is clear.  But conversely my behaviour in a different situation is far harder to manage. My wife may ask me to change our daughter’s nappy (or diaper as my wife calls it), I will generally willingly comply, but I very rarely volunteer.  I would never say it is not my job, but by subtly avoiding doing it I am implicitly saying so.  She can ask on a regular basis but that in itself undermines the equality and self-organising nature of marriage. The reality is that she is not asking me to take responsibility, nor is she demanding assistance, but my help is appreciated.  What I need is to broaden my ‘zone of acceptance’ and to be more proactive in my support.

The same becomes true in a Scrum team, if I were to hear someone say ‘that’s not my job’ or “I’ll hand that to a tester” or similar comments, they can be challenged. But far more common is seeing the team members forming natural silos for work, an often agreed line in the sand where work is divided and not challenged.  They will avoid tasks they are not interested in or don’t see as their role, find excuses for working on tasks they see as theirs and in some extreme cases work on something outside the Sprint to avoid picking up a task that doesn’t fall into their zone of acceptance.  This behaviour may not even be visible, a Scrum team can actually be very productive forming mini-silos, but that doesn’t make it right.

I see the role of a Scrum Master to challenge these silos, to encourage team members to broaden their zone of acceptance, and to get the team to inwardly think that it is their responsibility to get involved in Story writing, and coding and testing and be active in meetings, to volunteer to write documentation and present the Sprint Review, and to challenge those that don’t.

“But I’m a tester I don’t know how to code” – is a common argument. My response – “So what!” a lot of coders I know would benefit very much from having a tester on their shoulder asking if they had considered this case or that case, challenging the use of TDD and actively engaging in what and why things are being coded even if they don’t understand the code itself.  And perhaps more controversially the opposite is true, having a developer sit on the shoulder of a tester and see what and how and why certain tests are performed can help improve the way a developer writes code. I think we can make passable testers of most developers and vice versa, teams should want to challenge boundaries.

By this I am by no means suggesting that we create a team of jack of all trades – I am actually very much against that, expertise should be encouraged and my view is that testing and development are very different skills and expertise in either should be valued. But my view is that the comparison of skills needed for a sprint will often form a huge amount of overlap. If a product or sprint is a puzzle, chances are that there are a few parts that require specialist ‘Blue’ or expertise in ‘Red’ skills but the majority of the work is shades of ‘purple’ something that does not require expertise in either.

purple jigsawBut now what? We understand the problem, we know it is hard to spot and hard to challenge, so how do we expand the zone of acceptance?

The first step is nearly always acknowledging there is a problem. Discuss it with the team – maybe as part of a retrospective and see if they recognise it as a problem. Let the team find ways to solve the problem. Once they see themselves as a team it becomes easier as they will be seeking ways to help each other rather than for the easy way out.

One team I work with identified this themselves and their solution was to put a sign on their task board that said: “Have I done this before?” And another sign that said “Is this on the critical path?”

have I done this before

The idea was that when selecting a task to do the team member would stop and think: First whether they were taking a task that someone else could take and learn that task – or maybe they could pair and teach someone else; and secondly is this the next best task for the sprint or am I taking an easy option?  It is a written reminder and a challenge, and a challenge I’d encourage the other team members to make.

This barely touches the surface of this particular problem, and I’ll no doubt come back to it, but there should be a desire by the individuals on a team to (sensibly) broaden their zone of acceptance, for the focus to shift from what is the next best(or easiest) task for me to what is the next best task for the team.  And more significantly for this to be supported and encouraged by the team; the Scrum Master and the organisation.

Impediments

As a Scrum Master there are all sorts of things that get flagged as impediments that you are expected to resolve, some trivial some simply impossible.

My favourite of late was in a planning session, a member of the team said “please take this biscuit away, I have had far too many”  I stepped in seeing an impediment to remove and … ate it. Once again balance restored and my duty done!

But looking back I think the most persistent impediment is recruitment. Most of my teams over the last few years have been composed of a good proportion of contractors and/or growing teams. There always seems to be more work than we have developers.   I have recruited an average of 3 people a year for the last few years, sometimes spikes of recruitment sometimes just the odd replacement. But recruitment is time consuming. For each person hired, 4 or 5 are interviewed, for each person interviewed there can be 5+ CV sifted and considered.

I estimate each new hire consumes close on a full week of effort when you factor in interview time, preparation reading CVs and chasing recruiters, and often of more than one person involved in this process.

The bigger cost may be the impact on the team, a new person is disruptive, they change the dynamic of the team. They are unknown and may or may not live up to expectations.

Retaining staff is hard, the Inland Revenue continues to make life difficult for independent contractors and they are fearful of the implication of long contracts, and a buoyant contractor market means they can move around easily. Recruitment of permanent staff is much harder and a slower process. In the Civil Service because of the austerity measures permanent employees face an assurance of no pay raise or bonuses for the foreseeable future and the offer of below average wages. I still see the occasional good candidate but pickings are slim.

Multi-tasking TV viewing

I was aimlessly watching a movie on TV recently, and after about 20 minutes or so it went to an Ad break, I cannot bear TV adverts it is like scratching nails on a blackboard for me and knowing the breaks are quite long I switched to another channel and saw another movie that drew my attention. I watched that for a while – until the next Ad break and switched back, this went on for most of the movie(s).  By the end I realised that I had watched enough of both movies to claim I had watched them, but had missed so many crucial plot events that they both felt hollow and disappointing.

What is so interesting about this experience is that it is such a good metaphor for being a Scrum Master of two teams.   I’ll come back to this in a bit.

There have been many studies on multi-tasking and context switching (I believe there is a distinct difference – think the difference between juggling and plate spinning) and one that I read recently – http://www.infoq.com/articles/quantifying-impact-agile suggested that if you split someone between two tasks/teams there is a loss of 20% productivity, 3 teams 40% loss etc. I suspect that this is an implicitly accepted value by management and considered an acceptable loss. But it is my opinion that only applies to work that can stack or be put on hold.

If someone is split 50/50 between two teams answering emergency calls say, if they are not there when the call comes in then the call is missed. If the call centre is for the fire service, the loss in productivity and availability is consequential.

Back to being a Scrum Master for two teams.  The prevailing view in the industry is that a Scrum Manager can effectively support two teams (some even believe three), but the prevailing view amongst Scrum Masters is that to be truly effective you can only support one team.

My experience is that I cannot context switch this job. It is not possible for one team to pause while I deal with the other, the sprint goes on relentlessly, problems do not wait for me to return, and often problems lurk until I leave to manifest.  While I am giving attention to one team I am ignoring and neglecting the other, when I try to remain aware of both I run myself ragged and finish up giving neither attention. I was even asked to take on a third team – which I refused saying I couldn’t give them the attention they need.

So what is the answer?   The obvious answer is to say that if money is no object and recruitment was instant and effective and new starters hit the ground running the answer is to hire a good Scrum Master for each team.  Sadly that is not the case, there are three development teams and only one Scrum Master and although they are attempting to recruit another, the sad truth is that good Scrum Masters are very hard to find, and underlying all this there is a limit to the budget. A real-world problem that is not easy to solve with a text book response.

That is a little doom and gloom, and most of the time I can support two teams and I think I do a good job. One team is more mature than the other and so I generally split my time 70/30 and both teams seem to be improving (my definition of success). My problem is that I know I could do a great job if I could focus on just one. But is it worth the total neglect of the other?