A tale of two engineers.

There are two ships traveling a busy shipping route, each ship has a complex engine and the engineering team has a chief engineer. Both ships are a similar age and size.

The first ship has a very busy chief engineer running this way and that, fixing any and every problem that comes up, he knows every inch of the engine and many parts of it are custom made by him. He is dirty and oily and hard working, whenever there is a problem – and there are many problems – he is on hand to fix it. He is dedicated and hard working, he works long hours and is always ready and willing to get his hands dirty. Without him the ship couldn’t function.

The second chief engineer has spent his time not fixing things, if a part is unreliable he has replaced it, if a component is troublesome it is gone. If there is a problem he ensures one of his team fixes it (with guidance initially) and will encourage them to spread the knowledge so that after a while he rarely if ever gets his hands dirty. He is rarely dirty or oily and it is a very rare situation to see him fixing anything. On many voyages he can seemingly sit there with his feet up doing very little in maintaining the ship and can use his time on other productive activities. Frankly if he missed a voyage the ship would probably run just fine without him.

Now which in your opinion is the better chief engineer? I know which one I would rather have on my team.

It is often said that the goal of a good Scrum Master is to make themselves redundant, I take exception to this a little I think as in the tale above it is possible to create a situation where you are not necessarily needed all the time. But I wonder how long a team would last as a top-performing team if the Scrum Master was taken away, perhaps in the short term no one would notice, but growing and shaping and coaching a team takes time and effort, but slipping back into bad habits can happen quickly. Creating a situation where the Scrum Master has time to do other things is a good thing and a reflection of success not a sign he is not needed. A Scrum Master that is essential to a team is one that has failed, in fact if ever you feel you have an employee you are overly dependent on you have a serious issue.

How many top athletes would say “I’ve reached me peak I no longer need my coach”? My guess is that if they feel they have reached their peak they will seek out a new coach that can push those limits further.

A good coach or Scrum Master guides the team to independence, and then pushes their limits further. They may be more useful elsewhere but that is very different from becoming redundant.

It’s my way or the highway…

The last few months have been pretty busy for me and so I have dropped out of the online community for a while. Over the Christmas break I had some free time and so I ventured back in, caught up on some reading and tried to get a feel for the common issues of the day.

What I found was post after post condemning just about all things ‘Agile’

“Ban the use of Story points”

“Agile is dead”

“Scrum/KanBan should be sent to the scrap heap”

“We don’t need: Scrum Master/Product Owner/Agile Coach/QA”

There were some even suggesting that Agile had run it’s course and we should go back to Waterfall.

I found all this very disheartening, on one hand most of these were from people presenting a new idea or new techniques, and it is sad to say but in our culture it seems the only way we seem to know how to sell something is by presenting everything else as bad or with Click Bait statements, we all want to get noticed. But when did ‘Agile’ become so black and white?

For me Agile has always been first and foremost about inspecting and improving – finding better ways. But that doesn’t automatically make anything that differs from your approach Bad. And it certainly doesn’t make everything New to be Good.

There is not one Right Way.

In almost every case the examples/justifications were examples of poor implementations of Scrum/Kanban; incorrect use of Story Points; or a person being ineffective in a role, or in some cases there were teams that had matured to a point where they were no longer getting benefit from a tool or a role.

But not one of those examples makes the tool or the role Bad. In each and every case the team should inspect and adapt, and identify improvements. If one team decides that Story Points do not add value for them, that is great, that team has found a better way that they can deliver software.

But that doesn’t mean that other teams that find them effective are automatically doing it wrong. If you find you can use a tool effectively and it works for you, then use it. Just keep inspecting and improving. If a tool doesn’t work for you or you find an alternative tool that works that is great too. But try to understand why you are using a tool, what is your desired outcome and is there a better way for you.

As an anecdote, I was using a drill to make holes to hang shelves, I carefully marked and measured and then drilled. A friend was with me and he picked up a cross-head screwdriver lined it up on the wall and hit it hard, punching a hole in the plasterboard wall, far quicker than I was doing with the drill. The technique was great for him in that situation, but when faced with wood or brick it was not suitable, and in both cases I still needed to measure and mark.

Tools are context AND user specific, what works for one user in one situation does not automatically work for all users in all situations.

The same goes for the roles argument, I agree that there are some teams that have the versatility, the right mix of people and the capability to work effectively without one or all of the roles, but that doesn’t mean they are an ideal we should all strive for. Many teams find they are far more effective with those roles, and I would consider that to be just as much an ideal state as the other. If your team is effective and improving then you are demonstrating an Agile mindset. Our goal should be to improve how we deliver software, not strive for someone else’s idea of utopia. Concentrate on improving YOUR team rather than mimicking another team in a different situation.

Declaring your way the only way is not demonstrating an Agile Mindset.

Explain the benefits, do not attack the alternatives

If you find a way that you feel works well and you want to share it, then explain what problem it solved and why you felt it improved the way your team worked, share that example, but please don’t do so by declaring all other tools WRONG. What is right for you may not be right for everyone. You will just sound like a Snake Oil salesman.

Don’t reinvent the wheel

Having said all that we don’t need to reinvent the wheel and discover everything ourselves. We can benefit from other people’s experience and advice.

Both Scrum and Kanban and any of the tools mentioned can be badly applied, but when implemented with the guidance of someone with a genuine Agile Mindset (rather than a blind by the book interpretation) they can be excellent foundations from which you can evolve, by inspecting and improving, they are not the end point but a safe and structured starting point.

The same applies to the named roles, having someone with an Agile Mindset that can help create a foundation of understanding of the roles and when and where they add value can provide a structure and consistency that allows you to grow from a starting point that has proven to be effective for many.

Do not stand still.

But most of all, whether it be Story Points or the need for a QA, inspect regularly, assess what problem you are trying to solve in terms of outcomes, if you feel a change will show improvement then experiment and review. Small changes are generally preferred, it is easier to see the impact and easier to undo if the results are not what was expected. Understand what you are changing and why so that you can properly assess whether the change was beneficial.

I have seen teams conclude a Scrum Master/QA/Product Owner is not necessary after all they can cover the role themselves (usually as the result of cost saving measures or because they are presented with a false notion that good teams don’t need help). Sometimes this works, but more often the responsibilities are performed less effectively when distributed among the team and so the net result is a reduction in the effectiveness of the team.

There are certain expertise and mindsets that often come with a role that is not fully appreciated until it is gone. This generally and understandably gets neglected when it isn’t the core responsibility of the team members.

Let the team decide

If a team feels they need a change I’d have far more confidence than if the decision was made by someone with little or no exposure to the team, or on the back of reading a blog suggesting “good teams don’t use Scrum Masters/Story Points/Scrum/etc.”

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)

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)

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)

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.

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.

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.

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!

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.

But 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?”

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?