A Day in a Life of a Scrum Master
It's 9:30 am.
The Scrum Team gathers around their team desk to hold the Daily Scrum.
Jamie, one of the team members, highlights a problem that he faced yesterday:
"I cannot deploy the code into the staging environment due to pipeline issues.
I need help from the infrastructure team.
I raised a ticket, but since they had so many things in the queue, it's not been prioritised yet.
Daniella, could you help us remove the impediment?"
Daniella is their Scrum Master. She's a new member of the team. This is her second week and so far she's been mostly observing and learning about the team dynamics.
She replies: "I see. Let's talk after the Daily Scrum, so you can help me understand the situation a bit better."
Jamie nods his head in agreement.
Daily Scrum ends.
Daniella and Jamie meet to discuss further.
After a quick chat about what they were up to over the weekend, Daniella goes into the topic:
Daniella: So, you mentioned that you were not able to deploy your item?
Jamie: Correct, the build seems to be hanging and taking too long to complete. The jobs don't get executed after running for a while.
Daniella: Have you had a chance to check error messages in the console?
Jamie: I don't know how to do it. I don't even have the required permissions to investigate the issue further. That's the Infrastructure Team's job anyway.
Daniella: I understand. Does it happen frequently?
Jamie: Yes it does. In the previous Sprint, half of our stories were blocked for 2-days due to a similar issue, and the Infrastructure Team did not care whether we could meet our Sprint Goal or not. They are always too busy doing other stuff. That's a massive impediment that needs to be removed asap!
Daniella: Jamie, to be honest, that makes me wonder what the actual impediment is here.
Why do you think the team usually depends on another team or external subject matter expert to be able to achieve the Sprint Goal?
Jamie: We structured the teams in that way.
Daniella: Is this how the team members prefer it to be though?
Jamie: I think we could use a DevOps know-how in the team with required permissions. That would decrease our cycle time from Development to Done. However, we think that's not in our control.
Daniella: Why?
Jamie: As I said. That's the structure. This is how we do things here.
Daniella: What if you have a chat with the team to explore your hypothesis about the deployment/tooling know-how in the team? And if they think that's worth trying, I am happy to support to you to make an experiment on it.
Jamie: (Reluctantly) Yeah, let's see.
And they go back to their business as usual.
It's 1 pm. Daniella sees Adnan, a member of the Infrastructure Team, in the kitchen. She just becomes curious.
Daniella: Hey, Adnan. Hope you've been doing well?
Adnan: Hi, Daniella - right, just fire-fighting.
Daniella: Why is that?
Adnan: Inbound requests are coming from everyone, from every team. This is literally impossible to support the system. Let me show you our backlog, there are 3 items in progress I am working on at the same time.
Daniella: I see now. Because one of the other team members also raised the same problem and how it affected their team's progress. I think there are too many things on Infrastructure Team's plate and there is no explicit WIP limits.
Adnan: No, there is no WIP limit. That wouldn't work already since the head of engineering comes and resets the priorities, anytime she wants.
Daniella: Alright, things get interesting, but let's go one by one. If you were allowed to, how would you structure the team & process differently?
Adnan: I understand that an Infrastructure Team may help to initiate and coordinate the environment changes that entail large architectural innovations, tooling and automation.
However rather than centralising the DevOps knowledge, I'd prefer to devolve these skills to Scrum Teams. That's still possible to form a chapter, community of practice (or whatever you call it) which can regularly catchup to align and discuss how to improve practices & tooling.
This would help the teams in terms of broader learning, improving the capability to respond to change and problem solving without depending on others outside of the team.
Daniella: Is there anything prevents you from experimenting this idea with a volunteering team?
Adnan: I really don't know how it can work since we make top-down decisions on how we design our team structures and processes.
Daniella: I understand, there might be organisational conventions, and we may not have the full picture that would allow us to see all potential drawbacks and consequences.
What about running a workshop with the people who want to explore this idea? I'd be glad to support?
Adnan: That sounds good to me.
Daniella: We've got Jamie from the Team X. Who else should be involved & consulted?
Adnan: Nice. I have a few other names to begin with.
Problem Statement and Experiment
Following day, they run a workshop and use a template (similar to Hypothesis Driven Development) introduced by Daniella, as a complementary practice to create the problem statement and capture "what, why, how?" of their experiment. It looks something like that:
Problem Statement:
[Team X] was designed to [create a usable/valuable "Done" increment at the end of the each Sprint at latest].
We have observed that the team isn’t meeting this goal [since they have not all required skills/permissions to get their job done without depending on external sources in a Sprint],
which is harming [the cycle times, the morale, and the overall planning capability of our business]
Experiment:
We believe [having deployment/tooling skills & permissions within Team X]
will improve [their flow and capability to deliver their Sprint Goals]
we will understand it's succeeding when [Mean Time to Resolve of infrastructure related issues decreases 100%], [Avg. Engineering Cycle Time decreases 20%], [#Times the Sprint Goal not achieved due to an infrastructure related issue < 1] after a month.
The team members are engaged. All internal stakeholders have been involved and consulted. No subject matter expert thinks that the initiative would create a potential bottleneck for the other teams working on the same product. They see it as a survivable experiment.
The team also is aligned with the Product Owner to ensure he had a chance to discuss points of contention that would slow down the team in the first Sprint.
They understand, since there is a new team member, that may increase the internal communication channels (n(n-1)/2) and the existing team member may need to devote some extra time for this person's learning process.
Happy path.
All good, right?
Some 'more likely' scenarios.
Let's see the other side of the coin...
Daniella will be pushed back.
The team will be pushed back.
Most likely.
The team members may say: "Rather than chasing pipe dreams, please go chase Infrastructure Team to prioritise this impediment. We need to get these tickets Done"
Or a manager would question and belittle the framework: "Scrum is not pragmatic. It's too idealistic about cross-functionality. That won't work. Why? Because I say so."
That's alright. Probably they have a point given the context they operate in.
If Daniella keeps being curious with good intentions to understand their needs, she will probably learn a lot about the different and helpful perspectives.
She will also realise how fascinating that is: "sometimes two people disagree and say different things, but without being aware of that they fundamentally mean the same thing".
At that point, she thinks her job is to create a sense of community by facilitating consensus around the smallest experiment with potentially highest return of investment.
A Scrum Master's main responsibility
Let's start with the purpose of a Sprint.
A Sprint aims to create a "Done" increment (at the end of the time-box at the latest, and it can be more than once during the time-box) that is meeting the Definition of "Done".
DONE means the increment should be in a usable state by the customer so the Product Owner may choose to release it.
So the Product Backlog can be adapted against what's learned and the most valuable steps perceived that would get the organisation closer to their goals.
There might be various things impeding the team/organisation to achieve this and the Scrum Master's main responsibility is to make sure these impediments are removed.
The hats a Scrum Master wears come in different shapes and sizes.
8 stances of a Scrum Master is an insightful resource about Scrum Master role, if you want to dig deeper into that.
For me, "impediment remover" comes first.
A change agent, servant leader, coach, mentor, teacher... All are enablers for removing impediments.
Well, next time when a team member comes to the Daily Scrum and says "Jenkins is stuck. Infrastructure Team is too busy. My item is blocked. Help me Scrum Master.", before suggesting/taking a potentially pre-mature action, question (and make the team question) what the actual impediment is:
- Can it be resolved by the people who are doing the work? If not, why?
- Do they usually need support from an external subject matter expert to achieve their Sprint Goals?
- Is there any plan to close the skill gaps in the team so they can be less dependent to people outside of the team?
- How does this skill gap affect their engagement and team identity?
- Have they created a dialogue to make an experiment to explore a better way to accomplish their work?
- When the team wants to make an experiment, does anybody shut them down by using their superior position in the organisational hierarchy or political influence?
Certainly more.
These are probably the actual impediments and constraints in the system.
Of course, when there are more unknowns than knowns, and limited time to act, we need to work the problem with keeping "The Art of the Possible" in mind.
As described by Ken Schwaber: "We do the best we can with what we have."
It does not mean "protecting" the status quo, though.
And yes, If we cannot create uncomfortable/sometimes awkward dialogues around the actual impediments and only focus on “fun” retrospectives, we are complicit in the problem.