I’ve often thought that a Scrum Master is like a Police Officer. A Police Officer first learns the law and then has the job of upholding the law. Most of what a Police Officer does is around the law but not necessarily just the law. Police officers are responsible for keeping the peace. Ensuring that event attendees, from sports to music, are kept safe and having a good time. They attend road traffic accidents and clear up the mess. They might deliver bad news to you if a loved has been hurt or injured and is in hospital. They might provide an escort through heavy traffic to safe guard a precious life giving transplant organ. They look for missing children. They attend schools to advise our children how to stay safe.
The list is endless and mostly not about the law. This is similar to a Scrum Master. In this case the law is the Scrum Guide. The Scrum Guide tells us that the role of the Scrum Master is “promoting and supporting Scrum as defined in the Scrum Guide”. In other words upholding the rules of Scrum, much in the same way that Wikipedia defines a Police Officer as “empowered by a state to enforce the law”.
The Scrum Master’s job therefore is to make sure, primarily, that everyone in the Scrum Team is sticking to the Scrum rules (enforcing the law). This could be the role of a “Good Scrum Master” as suggested by Geoff Watts in “Scrum Mastery” but the same book might also describe a “Great Scrum Master” like a Police Officer that has duties wider than enforcing the law.
So what are the wider duties of a Scrum Master?
A “Great Scrum Master” should be responsible for
Like the Police Officer, the list of Scrum Master duties is endless, and mostly not about the Scrum Guide. So if you find that your Scrum Master is sticking only to the law, point them at this list or Geoff Watts book on “Scrum Mastery” and set them on the right path.
Two common themes that usually stand out when looking at high performing companies are shared goals and shared values.
All Teams should have a shared goal. Shared goals provide direction. The way forward. It means the team is aligned with a common vision directed at achieving specific results or outcomes. Without shared goals a team is rudderless. How do they know what’s in and what’s out? At a management level shared goals allow you to monitor the state of the team and circumvent any problems or issues when they arise because everyone knows what they are doing. Or do they? What happens when goals aren’t enough?
“Values tell you what to do when you don’t know what to do” – Tom McCoy, former EVP at Advanced Micro Devices
Sometimes you need more than a goal to help you. Shared Values promote good team citizenship and give guidance when making decisions. With the team singing from the same song sheet of values then any decisions they make will be in concert with each other and team members will be more engaged. When considering new team members, shared values define the team culture so it’s easier to determine if potential candidates will be a good fit for the team.
So what should your teams shared values be and how do you find them?
Shared values will obviously be different for each type of team and below I have identified some I think would be relevant for a software development team. I pulled these from a large list (see examples) and I think it’s worth having a pool for the team to discuss.
|Simplistic||Fun||Lead By Example||Humbleness||Responsible|
** Some of these mean the same thing but one word can mean different things to different people. Your mileage may vary.
A useful team exercise is the following:
Gaining consensus on this may take some time and you might need several iterations of the above exercise before the team is ready to publish it’s shared values. Ultimately, if you can can promote team member engagement then the results are sure to follow.
Often during sprint planning we struggle with story size. It’s a bit like Goldilocks – either too big or too small, never just right. In this post I’m going to examine the first case, stories that are too big.
Mike Cohn has a group of techniques he calls SPIDR. This is an acronym for Spikes, Paths, Interfaces, Data and Rules. Let’s look at these in more detail.
Quite often the reason we can’t split a story is because we don’t have enough information or we just don’t understand it. In this case we create a Spike (a short investigatory piece of work) and time box it to a couple of days. Once that time is up we either report back with more detail to help split the story or we go back to the Product Owner for more guidance.
Sometimes our Product Owner or Architect will have a flow diagram that outlines the system. From this it’s easy to identify the happy and unhappy paths through the application. In order to split the story we would typically start with the happy path and work from there.
Our applications typically have a user interface implemented through a browser. When we split by interface we can choose to implement by browser type or maybe by device type if we’re considering mobile or desktop platforms. Other times we can split by the amount of functionality we put into the interface. It might make sense to provide simpler functionality or less styling in the beginning.
We may be able to split if we have subsets of data. For example we may have a website that only deals with certain types of customers such as pensioners or students, or people in certain locations or country.
All applications have business rules. One way of splitting a story is to remove the need for a specific rule if it makes the story implementation easier. You can then add another story that fully implements the rule later. For example, in a financial application we may have a rule that a user can only perform a limited number of financial calculations per day. Our story could relax this rule for the first implementation.
Working on user stories is always easier when they are the right size. Now we have five useful techniques for splitting stories; Spikes, Paths, Interfaces, Data and Rules. See my other post for what to do when a user story is too small.
A friend’s organisation recently asked how he felt about moving to the Scrum Master role for his department. As the conversation progressed, he came to realise that firstly, there was going to be no progression into the role (their Scrum Master had just left) and secondly, it would be in tandem with his current Developer role.
This started alarm bells ringing. He always had Scrum Master in his peripheral vision, from a skills extension perspective, much the same way you get those floaters in your eyes that you can’t quite focus on. However, he always figured that it would be a gradual thing. That somehow the organisation would bring on board more Scrum Masters and a Community of Practice would develop, meaning that he could then learn from a range of people and experience different takes on the role.
A Community of Practice was not to be. Their only Scrum Master had gone and there was no-one to take his place. This was the reason for the conversation and here comes my big no-no; the split role of Developer and Scrum Master. I firmly believe that the role of Scrum Master is a 100% commitment. Splitting time between the two roles is about as un-harmonious a combination as cake maker and car mechanic. Imagine how much hand washing you would have to do if you had just changed the car oil and then intended to make some scones. Multi-tasking between Scrum Master and Developer requires about as the same level of metaphorical hand washing and you don’t get to lick the bowl.
Splitting the role could also bring team conflict. While having someone that understands the development challenges of the team could be an advantage, the team capacity would be reduced and more likely unpredictable throughout the sprint. This would be hampered further while trying to come to grips with the Scrum Master role. How would you prioritise between the two?
Worse still is that his department is composed of two teams working on different backlogs. The intention would be that he work as Scrum Master for both teams and remain Developer in one. How would he split his time?
No, splitting the Scrum Master and Developer role remains a definite no-no and that was his answer.
Working in the Finance industry means that quite often I come across User Stories that have a time constraint to them. It’s quite common that when the financial year approaches several applications need updating due to compliance and governance regulations. How do you highlight these items in the team backlog so that they are dealt with in a timely manner?
In “Fifty Quick Ideas to Improve Your User Stories” by David Evans and Gojko Adzic they suggest using “Best Before” dates. This is a really simple but effective idea that we’ve been using to make time constrained User Stories stand out in the backlog so that the Product Owner or Development Team can spot these during refinement sessions.
All we do is put a due date in the PBI title that is a few weeks ahead of when the work is required. Sometimes we’ll have two PBIs; one to do the work and another that has a specific due date to put the change into Production. Easy!
So start using “Best Before” dates on your time constrained User Stories.