When a Scrum Master joins a team, there’s so much to do. It’s daunting and sometimes a bit overwhelming. We have so many questions! Where’s the team need our help? Are they entrenched in how they operate or open to change? How do they interact with each other? How receptive are they to me, their new Scrum Master? Today, I’d like to explain one approach that I’ve find successful, and it all begins with a conversation.
The job of the Scrum Master can be a challenging one. It can be made tougher when people describe the role as a “referee.” Making such a comparison implies that the Scrum Master isn’t a member of the team. Worse yet, some describe us as keepers of process, which conflicts with how we value individuals and interactions over process and tools.
A Scrum Master is neither referee nor process keeper. Instead, he is a member of the team with a different set of responsibilities. This is easy to say but not always easy to enact. Viewing the Scrum Master as a team member requires work; however, this work is necessary. After all, trust is vital for every team to succeed, and teams will be hesitant to trust any outsider. So let’s talk about some tips that will help.
We spend a lot of our days talking about epics, stories, and tasks, and in many cases, we assume others understand these concepts as expertly as we do. Sometimes they don’t, and today I intend to take Leonardo da Vinci’s advice:
Simplicity is the ultimate sophistication.
Below you’ll find a table that boils epics, stories, and tasks to their most primitive forms, and it comes at a risk. Some may read this blog post and wish to prescribe these parameters on their teams. They shouldn’t. Others might argue details suggesting that one thing should be another. Today is for simplicity; details are for another day. For example, I write below that tasks should be no more than 8 hours, but what I don’t write about is the nuance:
- Tasks are for the team to find what works best for them.
- Tasks that are less than eight hours allow for team members to touch and advance a task every day.
- Such tasks also make impediments easier to spot when they’re not verbalized.
- Some teams choose not to decompose stories into tasks. That’s okay.
My point is that your mileage may vary, and as long as we clearly understand why we do what we do, then that’s what matters most. So without further adieu, here’s how I simply define epics, stories, and tasks.
As extra credit, feel free to also read about spikes and how they apply to agile teams.
I think every agile team should be viewed as a small startup. When you do so, you can begin viewing senior leadership largely as venture capitalists (VC). They’ll occasionally visit your office, they’ll provide valuable expertise and insights that will help your small company succeed, they’ll paint a vision of your competitive landscape so you can make better choices, and most importantly, they’ll infuse your small startup with cash. This metaphor can only be extended so far, and we could talk endlessly about the complexities of decision making within this model, but we won’t. Instead, I’ll borrow a quote from Martin Fisher:
Knowledge is the process of piling up facts; wisdom lies in their simplification.
So how do we simplify this? How can we paint a simple view to understand which decisions are for our VCs to decide, which is for the start up’s leadership, and which is for those in the trenches turning ideas into working product? Here’s how I answer those questions: