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 myth that voluntary overtime is commendable

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

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

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

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

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

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

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

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

 

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.

Why Agile?

I feel a little on the defensive recently, I have heard a Product Owner (ex PM) complaining that he could get it done quicker with Waterfall, and I have heard a number of people asking what was wrong with the old way and why Agile?

Short-term memories, fear of change – especially for a very large project manager community – teething troubles with the transition, and a variety of other factors are probably behind it.  But long-story short I was asked if there were any metrics on the comparison between Agile and Waterfall that we could use to ‘reassure’ some of the senior stakeholders.

After a bit of research I found an interesting survey: Dr. Dobb’s Journal 2013 IT Project Success Survey. Posted at www.ambysoft.com/surveys/

173 companies were surveyed: The companies were asked how they characterised a successful project.   Only 8%  considered success to be On Schedule, On Budget AND to Specification.  Most classed success as only one or two of these criteria.

Success criteria 2

Based on the criteria listed above and even knowing that success may be just one of those criteria,  only 49% of Waterfall projects were considered successful compared with almost 2/3rds of Agile projects considered outright successes.

Successful projects

When considering failed projects (projects that were never finished) nearly 18% of Waterfall projects were deemed failures compared to only 6% of Agile projects.

failed projects

Finally Projects that were considered challenging in that they were not deemed successes but were eventually completed.

challenged projects

Ultimately in my opinion “Why agile?” is the wrong question. The questions should be “How can we improve?” I believe that Agile is a philosophy rather than a Methodology.  I’d go so far as to suggest that if an organization has a desire to continually improve and follows through on that, then they are ‘Agile’ regardless of the methodology they use. And a company that follows an Agile framework without a desire to improve is not.

In other words ‘Agile’ is the answer to the question not the question itself. If done right and done with the right intentions Agile can help many organizations improve and improve further. Agile is not a destination.

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.

Product Owner Role – Overview

I have been asked to give a summary introduction of the responsibilities of the product owner role to a budding Product Owner.  They are due to go on a training course in around six-weeks so this is much more of a high level introduction to the expectations of the role.

Product Owner Overview

I began by outlining some of the core expectation of the role, the delivery expectations and the importance of the role in the process.

But the crucial and generally time consuming aspect of the role is the co-ordination, interaction and management of the stakeholders.

Product Owner Stakeholders

The Product Owner is one of the hardest roles in Scrum, being lobbied by users, the business, the team and others.  Giving time to users to properly understand requirements, understanding the goal and vision of the project/product. Identifying priorities. Being available to the team. Making decisions and all the while knowing you are the single wring-able neck, the one person responsible for the success of the project.

The Product Owner is involved in writing stories, planning releases, setting the product vision, the sprint goals and constantly ensuring that the backlog is up to date and prioritised.

It is not for the feint of heart.

Balloon Retrospective

During the retrospective one of the team suggested the Montgolfier brothers as their icon to describe the previous sprint.  In this case the description was that we were now flying as a team – still a little shaky but flying nonetheless. Balloon I had intended a repeat of the powerboat retrospective, but given the topical reference I modified it to be a hot air balloon <excuse the pun> ‘on the fly’.  In hindsight I think this actually worked out far better as a retrospective tool. The team were asked initially to identify any issues that were holding us down.  Anything stopping us flying or slowing us down.  The team were given a few minutes to identify issues (One per post-it) and then connect them to the Balloon drawing with an anchor rope. We went through the issues raised and identified common themes and grouped them. We also identified issues that could be explicitly added to the backlog as tasks or stories.  What remained were the groups of issues identified as holding us back. Next we moved on to note issues that were either giving us lift or could be done to help us take flight. Again one idea per post-it.  The post-its were placed in the balloon area.  After the team had enough time to run out of ideas, we again grouped the issues by common themes and removed any ‘easy wins’ that we could turn into tasks or stories on the backlog.   What remained were ideas for improving our velocity. Finally I drew a black cloud on the horizon and asked the team to identify abstract fears, issues that are looming or could hit us in the future. Again one idea per post-it and put the post-its in the dark and looming cloud. What we were left with was 4 groups of Post-its. Group 1; Stories or Tasks identified that we could put on the backlog for actioning.  These were specific and measurable tasks.

  • Chase hardware improvements
  • Request Extra Test Resources
  • Agree a data strategy

Group 2: The looming cloud – fears for the future, problems potentially looming. Things that we all need to be aware of but not necessarily react to yet.

  • Limited time and focus for re-factoring
  • Projects get derailed
  • External distractions impacting team
  • Project vs Product
  • The Unknown (Restructuring departments)

Group 3: Issues holding us back.  Areas where we could take action to change, essentially areas we should stop bad behaviour in or out of the team.

  • Lack of proper UI Design is holding us back
  • Availability of external resources
  • Red tape
  • Long-term architecture unclear
  • Decisions without consultation

Group 4: Ideas for steps we could take to improve our velocity, either by continuing good behaviours or ideas for new actions that would improve the team.

  • Learn from group design task and improve on this (Commitment from last sprint, which has been very successful), and identify design issues early.
  • More aggressive impediment removal (I have paraphrased slightly)
  • Improve organisation of BDD tests.

Given our over arching goal of small increments each Sprint, we set about selecting two behaviours (Good or Bad) to focus on for the next sprint.  Each team member was allowed 3 votes.  The can put all 3 on one issue or one on three etc. But no more than three votes. The team voted overwhelmingly for the following two commitments:

  • To establish a template for a UI Wireframe, and to seek 3rd party input into our UI design.
  • To learn from the success of design meetings and improve, specifically to hold a review session early in the story.

The overwhelming feeling of the Retrospective was positive, the team really feels like they are now working better together and improving. Although all sprint objectives were not fully met the team felt they had over-committed and the unfinished task will be carried over to the next sprint and improved upon.