Spikes And Stories

Scrum tips and agile insights from a Silicon Valley agile coach

A Simple Model for Better Decision Making

by 4 Comments

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:

[Read more…]

Impact Over Velocity

by 4 Comments

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.

[Read more…]

Navigating Dominant Personalities At Retros

by Leave a Comment

This blog post is part of a series where we hope to provide our readers with facilitation tricks, tips, and tools to make your retrospectives a success.  You can find more of our retro flavors here.

Ever been part of a retro where a single team member (or sometimes the product owner) dominated the conversation?  It’s not uncommon so know that you’re not alone.  But how can we get the rest of the team involved and how can we encourage our assertive member to spend more time listening to his cohorts?  Here are several techniques that have worked for me, and it starts with a conversation I recently had with a co-worker.

This co-worker asked me how much time I spend preparing for some of our company’s ceremonies.  My answer:

I usually spend more time preparing team members than preparing for the ceremony.

Since that sounds frighteningly similar to manipulation, let me unpack that a bit.  Sometimes team members have a hard time wrapping their heads around the intent or agenda of a particular meeting, like the retro.  If I fear that might occur, I like to stay ahead of it by having a few conversations beforehand.

[Read more…]

Spikes: Purpose And Usage

by 11 Comments

Spikes. It’s part of my blog’s name: Spikes and Stories, and it’s a bit of word play, which I’ll explain at the conclusion.  Because of this, it seems only appropriate that I pay homage to spikes and explain how I’ve used them with teams.

They have their origins in Extreme Programming (XP), and I define a spike as:

Work within a sprint that will not deliver any value itself.  Instead, it will create knowledge that may be instrumental in doing or estimating future work.

Why call them spikes?

I don’t know.  I’ve seen several conflicting stories on the origin of the term so I’ll not make it worse by picking a side or by making up another origin story.  Nonetheless, I think most of us will agree that it’s not a very intuitive or descriptive name.  Whatever their origin, their usage is a more interesting story.

Should teams estimate spikes as they do stories?
Some say they should be estimated, and they say so for a few reasons:

  • How do we do velocity-driven planning if we don’t estimate spikes?
  • So the team gets credit for the spike in their velocity.
  • They shouldn’t be penalized just because they don’t know everything.
  • If velocity is a measure of how much work a team can accomplish, credit should be given.

However, I disagree. I say no.  Spikes should not be estimated, and as with so many other things in agile, it comes back to our manifesto which states:

[Read more…]

%d bloggers like this: