Many months ago, I wrote my top 10 tips to be a successful Scrum Master. That blog post resonated with many of you, but it was missing something. It focused entirely on mindset and behavior, and while valuable, I thought some practical advice for Scrum Masters might also be helpful. So let’s talk practical with some tools of successful Scrum Masters that will help you and your 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:
Impact over velocity. In other words, don’t just do things. Do the right things. It seems obvious, but how many of us are guilty of deciding the success of a sprint by how many stories or story points we completed? But don’t worry. You’re not alone. Velocity is an easy number to get at, but easy isn’t always best. Or right.
Before we dive into understanding impact, let’s flip the concept. What does velocity over impact look like? If any of these apply to you, it could be a sign of trouble:
- Your team has disjointed or vague sprint goals. Your goals may have little to do with your team’s mission. Or they may be so varied or vague that they provide the team no focus, vision, or enthusiasm.
- The team has too many goals. James Carville once gave Bill Clinton this advice: “If you say three things, you say nothing.” Too many goals are noise; they’re overwhelming. Find out what’s most important, attack it with conviction and discipline, then move on to the next target. Don’t attempt to do everything all at once, or you’ll end up doing nothing.
- A disproportionate amount of sprint work has nothing to do with your goals. Maybe your goals rock. However, when you look closely, do these goals align with everything contained in your sprint backlog? If half your backlog has nothing to do with your goals, this may be a problem.
- Your velocity metric is overemphasized. In the absence of other measures of success, stakeholders associate a high number of completed story points with a high amount of impact. By extension, the team adopts a similar mindset. Remember that people don’t do what you expect; they do what you inspect.
- There’s little or nothing to demo at the sprint review. The entire team has been busy. Days have flown by because there was so much to do and never a dull moment. Yet, when it’s time to demo another increment of your product, there’s little to show your stake holders.
One in a series of posts intended to provide retro techniques to facilitators by way naming a flavor* and then describing tricks or insights to help tackle that flavor.
* flavor – an often implicit vibe, emotion, or general attitude of a team that can inhibit fruitful conversation.
I recently had a delightful opportunity come my way: design a retrospective to help the “Left Brains” and the “Right Brains” on a team figure out why they were having so much trouble communicating effectively.
The problem had emerged as feelings of frustration by both “sides” over the course of several development iterations that were part of a new release. And the more standard retro’s in my toolbox (http://andycleff.com/2014/08/retrospective-exercises-a-toolbox/) were just not producing action items that helped the team improve their situation.
The left brain thinkers continued to be their verbal and analytical selves. And if you hadn’t already guessed it, this group was the platform developers, the engineers. The folks writing the code. Their approach was to process information in an analytical and sequential way, looking first at the pieces, then putting them together to get the whole.
The reciprocal part of the team was the graphic UI designers / UX folks – the right brainers – who relied on visual, nonverbal and intuitive cues, using pictures rather than words. They also generally looked at the whole picture first then the details.
So the goals of the retro:
- Help the “two sides” grok how the other side “thinks”
- Make the root causes for their current impediments and frustrations more visible
- Lay the groundwork for building more empathy