To be the best, hire the best… for you.

I have recently been reflecting on the impact of our choices when hiring new staff. Over the last few years hiring has been a major activity for me, and so I am particularly interested in what the impact of these hiring decisions has on the team and the organisation.

I have a number of experiences that I feel are relevant and two particular opinions I have recently heard that I would like to discuss.

The first was from a blog post: http://zachholman.com/posts/0x-engineers/   in this the author is critical of everyone chasing after the type ‘A’ engineer, it makes an interesting read and refers to a popular belief that the good software engineers are worth 10x as much as the ‘average’ engineer.  I don’t intend to get into the basis or accuracy of the claims, but I am satisfied that it is a generally well accepted opinion that there is a significant difference in ability, and value of output between those deemed average and the top end of the scale, I have heard figures ranging from 10x as valuable to 1000x as valuable from quite well respected authors.

But ultimately the author compares software engineers to restaurants and concludes that most of the time he would be content with an average restaurant as we can’t always all eat in the best restaurants.  This is the point where I try hard not to be dismissive. The analogy is suggesting that most of us are content with ‘Good’ food and don’t need ‘Great food’ but the reality is that we are not only comparing quality, we are comparing relative quantity AND quantity, if we use his 10x value estimate then what we are comparing is a 1/10th of a ‘Good’ meal to a whole ‘Great meal’  We’d need to eat (and pay for) 10 ‘Good’ meals to get the same quantity/quality (value) of food.

He does have some good points about a good team being better than a star player and I’ll come back to that but I for one am not content with a tenth of a meal.

By contrast I looked at Work Rules! by Laszlo Bock (SVP People Operations at Google)

Lessons from WORK RULES! include:

* Take away managers’ power over employees
* Only hire people who are smarter than you are, no matter how long it takes to find them
* Pay unfairly (it’s more fair!)
* Default to open: be transparent, and welcome feedback
* If you’re comfortable with the amount of freedom you’ve given your employees, you haven’t gone far enough

Laszlo advocates hiring only the best, by hiring the best you get the best output, you certainly have to pay more but you don’t have to pay 10x the salary to get a 10x software engineer, it makes financial and practical sense, a small team of high achievers must be amazing and they clearly are for Google. But…

Here is where the real word kicks in.  Most of us don’t work for Google or Apple, we will not attract the best of the best, most organisations are unable to employ an entire team of 10x engineers, many of us are lucky to hire a few high achievers, when location, salary, benefits, and image are factored in, we can be selective and choose the best of what is available to us, but a good engineer is hard to find.

So I am saying that I don’t want a team where the primary qualification is a pulse, and I am highly unlikely to be able to hire (and retain) an organisation full of 10x engineers.  My world is the grey area somewhere between.

This brings me to what has been an inevitable consequence of the real world – a mixed team.  I didn’t like the restaurant analogy so I will go with cars.

cars

Lets say I have a team of five developers, as a very general rule a team will travel at the pace of the slowest member, and whilst you may be able to improve the speed of the slowest a little, the high performers are stuck at the slowest speed and may well be getting bored and frustrated.  It is no good one or two members zooming-off, knowledge doesn’t get shared resentment grows and very quickly you are at a standstill with a dysfunctional team. An effective team moves at one pace – the pace of the team, and as the original blogger wrote, a team that works well together can actually be far more effective than a single star player.

And this is where things get more messy, as either a Scrum Master or a Department Manager the goal is the long-term development of the team, I value all the team and I’d like to see everyone have the opportunity to develop and get better, a single star-player held back is bad, I don’t want to see that, but equally I am aware that an effective team can be amazing, and then again a dysfunctional team is a disaster. I want to grow and build a team that are greater than the sum of their parts not a group of individuals moving at the pace of the slowest.

So I find myself both agreeing and disagreeing with Laszlo, yes I want a group of the best engineers, but that isn’t going to happen, I don’t live in silicon valley and I don’t have that budget, and even if I did then I’d still prefer a great team of engineers. I believe that a team working well together can achieve far more and far better software than even ’10x’ individuals.

I aim to get that by hiring for the team. I will still aim to hire a team where they are smarter than me if I can but my primary goal is to find someone good that will enhance the existing team, that means I value the ability to communicate over their technical depth, I value their willingness to learn and to question over their certainty of their own knowledge, I value a desire to give customers what they want over a desire for a perfectly engineered solution. I suppose I am saying I value the team over individuals – even star players.

But I have a dark side too, anyone that is holding the team back needs to go, whether they are disruptive or not pulling their weight or simply because they don’t mix well with the others. I think we should be aggressive in hiring the best people for the team but equally aggressive in removing obstacles whatever form they take even if it means changing the make-up of the team.

I don’t want to close before addressing the other items on Laszlo’s list.  I want to voice my agreement over the other points,

* Take away managers’ power over employees

It really makes no sense to hire smart people and then tell them what to do, we hire smart people because they know more than us in their area of expertise – Let them use it!

* Only hire people who are smarter than you are, no matter how long it takes to find them

I agree with the caveat mentioned above, we don’t all have that luxury and for the most part it depends heavily on the next point.

* Pay unfairly (it’s more fair!)

Double what you are willing to pay and be selective. But don’t stop there! Retention is as important as recruitment, don’t lose someone good by being stingy, if you discover you have hired a star, give them a pay raise immediately, I can guarantee that when they go it will be for only 5%-10% more than you currently pay – don’t let that happen and offering to ‘match’ after they have one foot out of the door is far far too late. Let them know you value them now and make it hard for a competitor to lure them away.  Don’t worry if it upsets other people, if they know that reward is based on ability and performance they will respect it even if they don’t like it.

* Default to open: be transparent, and welcome feedback

I am a huge believer in transparency in development, so many projects fail because problems were hidden ignored or deferred or where customers were excluded until it was too late and too costly to change. Be honest and open and learn to see that finding a problem early is a good thing, even if you’d prefer not to hear it.

 * If you’re comfortable with the amount of freedom you’ve given your employees, you haven’t gone far enough

This goes with the first point but let the team lead the way, they likely do know best, and make work a place they want to be, if a team of engineers is happy and enthusiastic you will see an amazing improvement. And trust them.

Trust the team

I shall add that as my own piece of advice for success with software development.  Trust the team, trust their judgement, trust their opinions, trust their concerns and trust that they will do the right thing. In my experience a good team will reward that trust ten-fold.

In my opinion if you cannot Trust your development team it is a failure of management as you have hired the wrong people.

Agile Transition Frustrations

On the back of my good day last week, I have run in to a somewhat frustrating day today.

I have taken it upon myself to challenge the adoption of Agile in the organisation, it has been over 18 months since they adopted Scrum, and there are currently 7 Scrum teams each with a Product owner and there are 3 Scrum Masters and an Agile Coach/Scrum Master.  Sounds great! except that not one of those 11 roles have a job title to match.

In every case someone is ‘acting …’ – they are seconded from another role.  In most organisations that wouldn’t be a problem, you could be pretty flexible, temporarily at least. But in the Civil Service a job description and responsibilities are a big deal, every 6 months there is an appraisal of your work where you are measured on objectives that are constructed based on your job description and designated roles and responsibilities of that job, so unfortunately those in the roles of PO and SM are struggling to meet any of their objectives, not to mention a lack of support and backup as those more senior in the organisation are not familiar enough to formally provide it.  So it is being provided informally by those that are enthusiastic about agile.

So I decided that the time had come and I wanted to press it with HR, I want to create formal roles to reflect the work being done, to allow those interested to be able to apply and those doing the roles to be recognised and rewarded. And then finally I wanted to ensure there was a support network in place. (I could be biting off more than I could chew)

But today I met with two people – one responsible for organising the support network and one from HR, the lady from HR was fantastic, all you could ask for from an HR rep, she seemed genuinely concerned about the people, about ensuring they got the support and had career options and had clarification of their roles and responsibilities. But the support network guy… Now I don’t know if he misunderstood my request, or whether he was irritated by agile or what the situation was, but I felt I was on the back foot, he suggested that ‘some agile advocates’ were so zealous in their agile application that they created a rigid process worse than the ‘traditional’ approach. He seemed to suggest that as agile had no process that formal support was unnecessary, and he then spoke for a while about how the process was not understood, followed or even liked by the organisation, and I must confess at this point I wasn’t sure if he was talking about agile or the professional support network he was responsible for.

I felt very deflated, I really thought I would be pushing on an open door, this was someone (me) wanting to utilise their expertise and help make the system work by making it relevant to those doing the job and I was being criticised for not being ‘agile’  I found myself questioning what I was doing. Was I being un-agile? Was I imposing structure and regulation?

In the end the HR rep concluded very diplomatically that we were not ready for him yet and we would re-convene again without him – phew. But it still made me stop and think, was I doing the right thing?

So I have spent this evening thinking a lot about it, and on reflection I put it down to a belief that agile means no formal process. This is clearly wrong on a number of levels, but in the Civil Service it would be an impossible situation, formal process is so ingrained that you need a very formal process to not have a process.

The agile principle is that we favour “Individuals and interactions” over “processes and tools”. But that is not the same as saying we don’t believe in processes. I believe that the people are crucial and that providing structure, support, training and opportunities is very much the agile way, and if I need a process to do that so be it.  What is un-agile is to not provide these vital people support because a process gets in the way – which is the current situation.

Sometimes being challenged in your thinking really helps clarify understanding, and whilst I left the meeting frustrated I am now very pleased I had that conversation, I feel more certain than ever that it is both right and necessary for me to challenge this situation, and keep the focus on the people. 

Agile in action

For the most part it was a pretty normal sprint, the team read and refined the stories, asked questions and clarified the requirements. One of the stories referred to a text editor where text would be cut and pasted. There were questions about formatting and content and the PO was sure that maintaining formatting was not required and that the text would be standard text.

The team worked through the story and completed all acceptance criteria and everyone was happy, except one of the development team who felt an urge to work closely with the users and get actual examples of the text they used and how they worked. It turned out that one of the source documents was non-standard in the sense that the text editor selected was not able to cope with the source data, when pasted critical characters were lost.  We investigated further, and it also turned out that formatting and layout were also very important to the users in some situations, something not fully understood at analysis.

The team, the PO and the BA worked together, they all got involved and came up with a solution, and we have written a new story to be included in the next sprint, which means a slight delay in functionality being released to the users but as an observer to this incident I was very proud of how agile the team behaved and how smoothly we adjusted to what was in effect a significant blow to the initial design.

That may not sound a big-deal but if you consider that had we not challenged the requirements, had we not had open and effective communication with the Product Owner and the users, had we implemented requirements as written we would have been able to sign-off the work and likely get all the way to release and delivery to the users – weeks if not months later before this problem was identified, by which time the cost to resolve would have been considerable and the disruption to all would have been significant.

This is a great example of where agile can be a great tool.  A situation where the team made customer collaboration a priority over contract negotiation, and responded to a change rather than adhering to a plan.   Sometimes I worry that the benefits of agile get lost, but on days like today I feel like agile really has made a difference.  I feel immensely pleased with the team.

Velocity

I have seen a number of discussions recently about velocity, and generally the harm it can cause when used incorrectly. Most seem to advocate not using it to avoid mis-using it but whilst it is a blunt instrument it is just information like any other metric and for a process that relies on empirical evidence to adapt and evolve it seems odd to ignore a very useful metric, so instead I will try to explain how, when and why velocity could be used to add value.

My car has a trip computer and among its varied metrics it offers an ‘instant fuel economy’ feature.  Why? I don’t know, but to my mind it is a pretty useless feature, but it is there and at any time I can take a spot check and it will tell me how much fuel I am using in mpg.   When racing up the hill to the Air Balloon roundabout foot down it drops to around 20 mpg, when coasting down with my foot off the pedal I get 99 mpg.

If I were to take a single reading half way up the hill and claim that my car does 20 mpg I would get a totally distorted view of the velocity with which I consume fuel, equally if I took a single reading coming down at 99 mpg.    I’m sure most of you would think I was nuts to even consider taking a single reading as an absolute indicator of future velocity. But somehow with ‘sprint velocity’ people think that is okay.

Let me stretch the analogy further. I know that a single measurement is a little crazy to base things on, so let’s take an average over the last 100 miles. That is a pretty solid and reliable metric, most of us would consider that to be a reasonable predictor.   But I have spent the last few weeks only driving around town, stop start, traffic jams, short journeys and so on. But now I have a long trip, mostly motorway, will my average fuel consumption velocity be a good indicator of the next 100 miles?  No it won’t, common sense tells me before I even look that my velocity will be different under different conditions.  A velocity only has meaning if the measured data is representative of the future conditions.  Equally I tend to drive with a heavy foot, but I am quite sure if my father were to drive the same journey in the same car the consumption velocity would be quite different.  The same is true if I drove a different car, the velocity would be different even if my driving conditions were the same.

Velocity tells you only one thing – what was consumed in this car in these conditions. It offers no view of the future, or of alternative conditions.

But I am free to interpret, I can predict, I can guess, I can extrapolate all I like, but it is not the velocity that comes up with these figures – it is me. If I make a prediction and it is wrong, I cannot blame the velocity, the velocity is a measurement of what was, not of what will be.

So how is it useful then?    The most obvious is to say that if I believe that my typical journey over the next 100 miles will be similar to the last 100 miles, similar driver, similar journeys, similar car then it is not unreasonable to expect similar results.  It can be a predictor.

Or let’s say that I am a little bit eccentric and I decide that I want to increase my average MPG and I spend the next 100 miles on similar journeys in a similar car, but I try very hard to improve my driving to be more efficient, in that case it can be a blunt measure of improvement in my driving if the average goes up, I can measure improvement.  I would caution myself very carefully on this particular measurement because it could easily be a change in the road conditions not the driver that is the cause for a change but even so it is a measure – the interpretation of meaning is mine.

Or if nothing changes that I am aware of and the average goes noticeably down or up, it might be an indication of a problem it might be an indicator there is a problem with the car, or my driving, or even just different fuel.

So now I understand all about the velocity of fuel consumption my current average is 50mpg. How much fuel will I consume on my next journey?     There is no way to tell, to even make a reasonable estimate I’d need to know an approximate distance, I’d need to know the terrain and even with all that there are still unknowns, I may hit a delay in traffic, or a diversion, I may get asked to call in and pick up milk, I may even breakdown.  And if I could predict all of that and gave you an estimate, would you trust it to any degree of accuracy?  I wouldn’t, I might trust the estimate to a degree, but I wouldn’t play to fill up on empty on such an estimate I’d almost certainly plan a significant buffer to ensure I didn’t run out of fuel.

I hope most of you would agree with my views on fuel economy, there are simply too many unknowns to make accurate predictions.

And yet, I reset my trip computer fairly regularly every 1000+ miles or so, and on average over that 1000 miles my economy is in the region of 48 ish, it very rarely fluctuates significantly from this. Over a very long timeframe I can get a very accurate estimate, that is consistent 1000 miles after 1000 miles.  That still tells me nothing about the next 20 miles or even 100 but long term I can be consistent.

Another interesting observation is that to get this measurement I am using an extremely accurate tool to measure, I am in a known unvarying state – same car, same driver, similar journeys.  And yet with all this certainty I still don’t trust my predictions to any degree of accuracy I buffer I plan contingency.   But if I stop talking about cars for a moment and I talk about software, more specifically a team developing complex software with a great many unknowns, where the team members can take leave, be sick, have family troubles, they can leave the team, or new people join the team, they can learn new skills, use new tools.  But we are expected to estimate, often to a very specific dates, large quantities of unknown and often very complex work. What is more odd is that those estimates are often taken as commitments.

If a rational person wouldn’t trust a reliable and regular machine like a car to give specific accurate predictions with fairly well known parameters, why do similar rational people expect such accuracy from a domain far more variable, far more complex and far more unpredictable?

My rather long winded discussion on fuel economy is really summed up in one sentence.

There is only one estimate on how long a software project will take that I would trust and that is one given the day after the project is completed.

Otherwise use projection tools like velocity in context,  if the future conditions are likely to be unchanged then velocity can be a useful tool, but the longer the average the better.  And if your circumstances change: the team, the type of work the domain, the tools your current velocity is meaningless until you have enough information to create a new measurement.  And think of your car, what value is an snapshot measurement without context.

Coaching is the easy option?

I have run into a strange dynamic in the agile transition today.   As part of the transition to an ‘Agile’ organisation I have been pushing HR to create and formally recognise new roles, specifically Scrum Master and Product Owner, up until now it has been by unofficial secondment.  Part of me feels pleased that we are getting traction over the move and formal recognition is a major step forward in the Civil Service.

But now I have hit a rather significant hurdle, how grades are classified, the Civil Service – or at least this particular location – classifies and grades roles based on accountability, responsibility and number of reporting staff.  So a servant leader that coaches and supports and has no direct reports comes out classified as a very junior admin assistant, the people doing the role it turns out are two or three grades higher than ‘proposed’ which is clearly a serious mismatch.

The advice has been to reword the job description to add responsibilities and authority and accountability, but that feels wrong to me. I am trying to educate and apply Agile principles to the organisation and this feels like a very unpleasant compromise.

It seems that somehow coaching is classified as an easy skill and the lack of apparent direct accountability and responsibility does not sit well with the pigeon holes that the roles must fall in to.

I have tried explaining that coaching is actually far harder than managing, using coaching skills to help a team discover for themselves what to do next is a very difficult skill, but when done right what they learn gives a far deeper understanding and more likely to be maintained than any amount of compelling, controlling or micro managing task assignment.

Those involved seem to understand and appreciate what I am saying but we are challenging the system, it will be an uphill battle. This is new ground and a transition to Agile is rarely easy and it seems the bigger and more established the processes the harder it is to change.

But I wonder why coaching is seen as an easy option. It rarely is. A coach actually has to be pretty mean, they have to be tough.  We have to turn a mirror on people and often show them some unpleasant aspects of themselves, often they are unaware, which can be even tougher to deal with. I sometimes have to sit back and watch someone fail knowing I could have prevented it – not because I want to see them fail, but because failure can teach far more than correcting them.

I sometimes get pressure from management to assign tasks, or to get the expert to do a job because it is quicker, or to challenge certain behaviours directly. I resist and this can and often does reflect badly on me, but I resist because I believe providing an environment where the team learns for themselves is far more valuable than any short-term gain resulting from taking away their independence.

I see my job as protecting the team and creating an environment to grow and learn. I do this by asking a questions to provoke ideas, I challenge where I see potential, sometimes I stray into leading questions if I think it helps but I try very hard not to provide answers, and if I slip into leading rather than coaching I hope I get someone turning a mirror on me and coaching me how to be better.

I love my job, but I don’t coach because it is easy, I coach because someone needs to be tough and push you to do better.

There is a quote in Lyssa Adkins’ book – Coaching Agile teams, which I will paraphrase a little, it says so much.

A friend likes you the way you are, a coach respects you too-much to let you stay that way.

Anyone that thinks a coach or a Scrum Master is the easy option should try walking in those shoes for a while, it may put a whole new perspective on things.

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.