Blog
What Should a Scrum Master Really Do?
A Scrum Master is Like a Police Officer
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?
Scrum Master Duties
A “Great Scrum Master” should be responsible for
- Organising and Facilitating meetings.
- Actively encouraging and running story workshops or feature mapping sessions.
- Insisting on a project Inception meeting and facilitating it.
- Ensuring the Product Owner has a refined and prioritised backlog
- Encouraging the team to define definitions of Ready and Done then ensuring the team holds itself accountable to them.
- Encouraging the team to use good software development practices and ensuring the teams holds itself accountable to them.
- Ensuring the Product Owner does not pressurise the team into taking too much into the Sprint Backlog.
- Monitoring the teams happiness levels to identify areas of concern and helping them work through it (see my team survey post).
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.
How to Improve Team Engagement With Shared Values
Shared Goals and Shared Values – Two Sides of the Same Coin?
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?
Discovering Your Team’s Shared Values
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.
| Collaborative | Integrity | Client Value | Innovative | Transformational |
| Respectful | Ownership | Empathic | Ethical | Relationship Building |
| Openness | Speed | Courageous | Democratic | Information Sharing |
| Simplistic | Fun | Lead By Example | Humbleness | Responsible |
| Enthusiastic | Passionate | Evolutionary | Diverse | Perseverance |
| Urgency | Egalitarian | Autonomy | Kinship | Reliable |
| Optimal | Welcoming | Transparent | Accountable | Results Driven |
| Quality | Rigorous | Determined | Reciprocal | Improvement |
| Excellence | Creative | Open Minded | Moral | Honest |
| Resourceful | Productive | Focused | Social | |
** Some of these mean the same thing but one word can mean different things to different people. Your mileage may vary.
Team Exercise
A useful team exercise is the following:
- The Management team identifies a set of values (20 to 30).
- Hold a team workshop where the team goes through the list from the previous step.
- Gain consensus from the team on the values they want to share (6 to 8 values). It’s important that this is done by the team. If your team is large you might want to facilitate smaller groups that identify 2 to 3 values then get the whole team to pull these together for the wider team to get 6 to 8 values.
- Publish the team values for everyone in the team and organisation to see.
- Remind the team members to hold each other accountable to their shared values. This could be done at a daily stand-up or retrospective.
Rinse and Repeat
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.
A Great Way to Write Release Notes
The Trouble With Release Notes
This week I have been shepherding our latest release into the production environment and I got stuck with the task of doing the release notes as well. The trouble with release notes is that they are boring and unloved.
The Problem
Release notes tend to be just lists of changes which hardly makes for inspiring reading. If you’re bored when writing them then why would you expect anyone reading them to continue to plough through the dross. You won’t necessarily have a large audience and you don’t need to write the next best seller but you can make them more engaging and easier to digest for those that do read them.
What Makes for Good Release Notes?
Wikipedia defines release notes as “…documents that are shared with end users, customers and clients of an organization…[that] detail the corrections, changes or enhancements made to the service or product the company provides”. This means that you have an audience of internal and external users that want to know what has changed in your product since the last release and so you should help them do this as quickly and pain free as possible.
In order to digest release notes it makes sense to order them into sections which means you have to do the work of sifting through the changes to categorise them for your readers. I finally settled on a template with help from this post.
Release Notes Template
- Release Title and DateThis should contain the name of the product, the version and the date of release.
- SummaryThis should be a headline description of what’s in the release. A few sentences should do.
- NewList any new features and functionality here. This might be at the user story level and could include links to the work item.
- ImprovementsOutline what changes and enhancements you have made to existing features. Again, include a link to the work item if you can.
- FixesPut your bug fixes so that your users know that you are removing errors from the system.
- Operational ChangesThese are under the hood changes that are not necessarily important to the users of the system but should be tracked. Include items here such as infrastructure changes or changes to deployment.
Example
Summary
This release introduces the ability to delete bits and bobs from the settings screen and enhances the reporting screen by adding a back button. The save to disk bugs have been fixed and the server hostnames have been tokenised as part of the deployment process.
New
Item 48923 Delete bits from settings screen
Item 48924 Delete bobs from settings screen
Improvements
Item 51344 Provide a way back from reporting screen
Item 48555 Restyle reporting tables to fit on mobile devices
Fixes
Item 48871 Error when save to file when filename longer than 12 chars
Item 48872 Error when save to file when filename has underscores
Operational
Item 48801 Tokenise server hostnames during deployment
Add Humour
I’ve also had some success with a slightly more humorous version, but you might have to think carefully about your audience.
The One Where (Summary)
…
Awesomeness (New)
…
Twerks (Improvements)
…
How Did We Miss These (Bug Fixes)
…
You Don’t Need To Know (Operational)
…
Love Your Release Notes
Ultimately, making your release notes clear and unambiguous shows that you are committed to engaging with your end users and can only help with the success of your product. Do your readers a favour and love your release notes.
The Best Ways to Split User Stories
The Goldilocks Scenario
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.
Techniques to Split Big Stories
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.
Spikes
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.
Paths
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.
Interfaces
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.
Data
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.
Rules
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.
Goldilocks Gets Her Porridge
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 Definite No-No for Scrum Masters
Moving to Scrum Master
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.
The Definite No-No
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.
Conflict
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.
Why Do We Always Forget About the Documentation?
The Agile Manifesto
The Manifesto for Agile Software Development states “Working software over comprehensive documentation” and for a long time many teams and individuals have taken this to mean that we don’t need to document our software.
Writing documentation can be hard. Not everyone is a fantastic wordsmith, especially in the development community where, mostly, we just want to build stuff. However, the same manifesto also states “Individuals and interactions over processes and tools”. What better way to enable individuals than to have decent documentation. Documentation that points you in the right direction, that explains things in ways that the code never can. Documentation that records design decisions so that those same interactions flow well.
Use a Software Travel Guide
Simon Brown, in his book “Visualising Software Architecture“, and Patrick Kua in his talk “Travel Guide to Software Systems” both advocate a “travel guide” style set of documentation. They argue that context setting is a necessary component of software development in much the same way that you would use a travel guide and map as a way to orient yourself in a city or country that you are unfamiliar with.
The travel guide concept is useful because it suggests a lightweight approach; something to get you started on your journey. An entry point into the tangled mess of an unknown software application. It can outline areas to watch out for. It can serve as a reminder for those who have travelled there before, including ourselves since we can often forget where we’ve been in this modern world of multi-tasking on projects.
What to include
What are the best things to document? Simon Brown suggests at a minimum you should include the following:
- ContextThis should outline what the software project is about. Who the main users and stakeholders are.
Include some kind of context diagram. - Functional OverviewThis expands on the context to outline the use cases of the system. What are its main features. What is the business workflow the system replicates. Some facts about the domain and glossary of terms.
- Quality AttributesThese are the non-functional requirements of the system such as scalability, performance and security.
- ConstraintsThis might include standards or protocols the system follows or constraints of the technology being used.
- PrinciplesThis can be about the culture around the development. Some examples here include coding standards or styles, logging, always use dependency injection, use Swagger rather than RAML, prefer thin client,
position of brackets, naming of tests. - Software ArchitectureHere you might find architecture diagrams (component/sequence/flow diagrams).
Discussion of the key architecture patterns, perhaps layering strategy. What are the deployable units. - Infrastructure ArchitectureWhere the software is deployed. Describe the physical hardware, database servers, message buses. Who maintains it. Backup and Disaster Recovery strategy.
- DeploymentHow the software is deployed to the infrastructure. Automated/Manual processes. Configuration settings. Deployment rollback strategy. Data replication.
- Operation and SupportHow the system is run and monitored. How problems are diagnosed. Housekeeping tasks. Data archiving.
- Development EnvironmentSetup of tools and environment needed to develop the system. Build and test instructions. Username and password location.
How to Start
Start by imagining that you were on-boarding new people to the project. What do you think they need to know? Create answers to those questions and build up the documentation as you go. Make sure everyone is involved and above all remember to keep it light, exposing the essential details.
Don’t forget the documentation.
Can’t Add Hostnames and Culture Setting in Umbraco
Error – Hostname Already Exists
I recently had a situation in Umbraco where I wanted to add a “Hostname and Culture” setting but when I clicked “save” I kept getting the error “Domain has already been assigned”. This was in Umbraco 7.2.8
After much searching on Stack Overflow where people were suggesting that I hack the domains table I decided against it since I’m using a Production system with no access to the Live database and no easy way of recovery without filling out oodles of paperwork to get Operations to undo my errors – embarrassing to say the least.
The Solution
Finally, I realised that Umbraco wasn’t lying to me. The domain name was being used. I had a previous content page which was similar to the one I was editing and it used the domain name but it had been deleted. It was sitting comfortably in the “Recycle Bin” and when I removed it from there my problem was solved.
Lesson learned – clean up your “Recycle Bin”!
UPDATE – It seems that Umbraco 7.5.4 has an improved error message that indicates where the duplicate is.
When Umbraco Deletes Go Wrong
Deleting Files in Umbraco
I recently came across a situation where one of our Umbraco editors had to do some work for a client. The client had some financial information contained within PDF files that were loaded into the media folder of their Umbraco site. This information had become outdated or linked to newsletters that were no longer relevant or even on the site.
The client had stumbled across the documents while doing a Google search on their site and asked our editor to remove the items, which the editor promptly did. However, a few weeks later the client did the same Google search and found the documents still available. Eeek! Needless to say the client wasn’t happy and we looked foolish.
What Went Wrong?
It turns out that while our editor did a straight forward file delete and the link was gone, the associated file was still languishing in the media folder. This happened because Umbraco, effectively, does a soft delete and puts the media item in the “Recycle Bin”. The associated media files are only actually deleted when the “Recycle Bin” is emptied (or the specific item is emptied from the “Recycle Bin”).
Once we realised this, we were able to remove the offending files and they were no longer accessible from Google (Google still held them in it’s index for a few days until it crawled the site again).
The Fix
The moral of the story is “empty your Umbraco Recycle Bin” when you’re deleting.
My other post about duplicate hostnames is also a symptom of this.
A Simpler Version of the Spotify Health Check
Spotify Health Check
Everyone loves Spotify, right? We hear of Spotify being the Nirvana of Agile Development because they have all sorts of wonderful processes that fit right into the”Agile” landscape. Well, in my department we had heard of the Spotify Health Check. This is a way of measuring and visualising how your team is doing. It gives the team a sense of where you can improve on things such as teamwork, health of codebase, team mission and learning.
We tried it. It’s quite a convoluted process and the team soon drifted away from it so we thought we would try something else. Step forward our Team Happiness survey.
An Alternative
The Team Happiness survey is a set of 7 questions that we answer once a month. Each question has a “how much do you think you do…” flavour, with the answers being “least” to “most”. The survey is done using Survey Monkey and is totally anonymous. The results are collected and weighted to produce a trackable score and we can then use the results as data in our Retrospectives.
The idea came from “Creating Great Teams” as part of how they monitored the teams after they had self selected. We’ve taken their health questions and added to them to get our own model. Here are our questions:
The Survey
Thinking of the previous month at work. On a scale of 1 to 5 (1 least, 5 most), how do you feel you…
1) Are doing meaningful work (purpose)
2) Are allowed to focus on one thing at a time (productivity)
3) Have direct influence on how we work (autonomy)
4) Work in a team where people support each other (support)
5) Work in a team where people challenge each other (challenge)
6) Have been able to learn new skills (mastery)
7) Can be creative at work (creativity)
So far we’ve had a few eye openers (to do with team mission) and somethings that aren’t a surprise (such as multi-tasking and focus). I’ll keep you posted on our progress with this.
One Great Idea for Tracking Time Constrained User Stories
Time Constrained User Stories
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.
The Solution
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.
