In conversation with a new Scrum Master, I was asked:
“What should be on my to-do list in the first 90 days as a Scrum Master?”
Great Question!
First, I shared a little about my first 90 days as a Scrum Master. It was 2007 and, like many, I was introduced to Scrum in a 2-day training course organized by my employer. When the dozen of us returned to the office after the training course, we agreed we would try Scrum and I volunteered to be the Scrum Master.
Then, like any fool with a new power tool, I started “fixing” things.
I declared that a Sprint had begun; I gathered the various to-do lists we had each been assigned and I called it a “Product Backlog”; I scheduled a 15-minute daily meeting; and I drew a burndown chart on the whiteboard for all to see. And in short order, I ran into our greatest impediment: competing priorities! So, I pestered our Vice President to decide “Who will be our Product Owner?”
That approach didn’t work well. Don’t do what I did!
An eager Scrum Master may want to invoke change in the organization. It’s easy to grow impatient. But it’s a mistake to nudge the system too far, too fast. First, because humility and some wisdom is needed to understand which changes will be welcomed by everyone and compatible with the company’s culture. Second, because the system will always kick back. For every change a Scrum Master will try to implement, there is some probability that the outcomes they want will actually occur, but there will also be unintended consequences.
I have made such mistakes in the past.
I’m Older Now and (Maybe) Wiser
I’ve met many teams over the years and my approach has changed significantly. Here’s some advice I offer to new Scrum Masters in their first 90 days with a Scrum Team.
1. Observe the implicit and explicit agreements they have.
Implicit agreements are those that can go unsaid — everyone just knows.
Explicit agreements are those that are formalized somehow – they are written down perhaps, maybe they’ve been debated or inherited.
Either way, make note of those agreements. And help others notice them too. And, in particular, notice where the implicit agreements and other common behaviours/actions do not match the explicit agreements. For example, I find myself with my clients saying things like, “let’s understand what is already true about our ways of working” and “let’s notice that the way we say we do X is different than the actual way we do X”.
One of the ways a Scrum Master can serve a team is to help everyone adhere to the working agreements of their team. For example: find out if they’ve all agreed to try Scrum. If not, I wouldn’t force it — rather, I’d find out what they have agreed to. Maybe there’s unanimous agreement to try a 15-minute daily meeting and a weekly planning event. OK…then help the team uphold those. Ask if they’d like to try other parts of Scrum as well. Seek new agreements – it’s in this way a team evolves to be more self-managing.
And one last remark about working agreements: whether they are newly formed or you have joined an established team, it’s important to acknowledge that some patterns may be working well. Honour what is working well. (I’m channeling Esther Derby here, credit to her is due.)
2. Help the team make their Definition of Done visible and understood by the team and their stakeholders.
It is essential that the team members and their stakeholders understand the quality they can achieve each Sprint. The purpose of a Sprint is to produce a ‘Done’ increment — so, when a developer says “this Product Backlog Item is done”, everyone must know that that means.
What conditions of satisfaction were met within the Sprint with regard to that Product Backlog Item?
Was it designed and coded in the Sprint?
Were unit tests written?
And is it known to be secure, fully functional in multiple web browsers and on multiple devices and various screen sizes?
Is the User Interface on brand?
Was the new functionality tested with actual users?
Was it deployed and confirmed to be working in a production environment without defects?
…and so on.
For each of quality criteria, the team must understand what they are capable of, routinely, each Sprint. And, for example, if they’re unable to have their work of the Sprint translated in a multi-lingual system or unable to update the user guide to match new functionality they built within the Sprint, then those unsatisfied quality criteria are impediments. Likely, they are dependencies: the team likely depends on others outside the team to perform the translation or to update the user guide — those dependencies must be understood and made visible as limitations to their Definition of ‘Done’.
3. Organize a meal for the team.
Go for lunch, perhaps. Sharing a meal together can enable dialogue beyond the work and establish trust between people who don’t otherwise interact often.
In the best teams I’ve worked with, personal relationships were formal and informal, in the office and beyond.
For example, consider arranging a meal during Sprint Review! This is an event that combines the Scrum Team and their stakeholders. Sprint Reviews in some companies are constrained and ceremonious, and I don’t think that’s optimal. When these individuals can achieve informal, cordial, trust-based relationships, the flow of information and feedback can be more transparent and honest.
Enjoy!
While this isn’t an exhaustive list, I do hope it’s helpful.
What To Do In The First 90 Days With A Scrum Team