Category Archives: scrum-and

Seattle Scrumpocalypse 2012

Are there any conditions in which a Sprint’s timebox can legitimately be extended?  I think I might have found one.

In my Scrum-damentals webcast I’m pretty strict in advising that teams should not extend the timebox of a Sprint, even when things go pear-shaped.  Why not?

You and your team have certain goals as you’re getting ramped up with Scrum:

  • Learn your true velocity based on real-world measurements
  • Improve your estimating and forecasting capabilities through regular feedback
  • Refine your story sizing and task breakdown skills
  • Develop a comprehensive definition of done (e.g. don’t overlook needed work)
  • Over time establish reliable metrics for future forecasting

Extending a Sprint in order to complete all of its deliverables undermines all of those goals.

Besides, there are better alternatives.

  • With the Product Owner’s approval, you can reduce the scope of the Sprint at any time for any reason
  • I personally like a Kanban WIP (work in process) limit to be in place from the start of the Sprint, because if you need to cut scope mid-sprint, it’s a lot nicer to have some completed stories (credit!) and some unstarted stories than all half-finished ones (no credit for any of them!)

This week one of my Scrummy friends presented me with an interesting challenge and got me to reconsider—or rather, refine.

You may have heard that we had a little weather up here in the Northwest.  Being the tech city that we are, nearly everyone (who doesn’t already do this full-time every day) retreated to work from the comfort of their living room and their fleecy pajama pants.  I won’t speculate on what this does to teams’ productivity, but we can safely say that widespread power outages that started on Thursday knocked out all but the most hardcore workaholics (running their laptop on battery, tethered to their 4G smartphone, recharging off the Prius in the driveway, you know the type).

My friend spent his week trying to salvage a Sprint which was scheduled to end on Friday.  He phoned in each day to his daily Scrum.  Standing up isn’t prescribed by Scrum, but lots of teams appreciate the value of a standup and he indeed stood up, pacing the kitchen during the requisite 15 minutes.  They lost time to and were blocked by the storm in various ways that I don’t know all the details of, and on Wednesday he lamented to me that, with all they’d have to cut from scope, they were facing a “failed Sprint” because you “can’t” extend it, not even to account for the weather.

I gave this a little thought and asked, “didn’t you determine your Sprint backlog based on your team’s capacity?”  Of course, he said.  “If a federal holiday fell in the middle of your Sprint and your entire team missed a day, would you count that against their capacity or would you plan around it?”  Don’t be silly, you wouldn’t count a federal holiday as a team Sprint day any more than you’d count a weekend, he said.  (Neither one of us is the tethering/Prius type.)

“So, if nature drops the equivalent of a federal holiday into the middle of your Sprint, why not move the Sprint around it?  If you move the Sprint end date by one day, aren’t you just keeping the Sprint the same length it was before?  The same duration your team had in mind when it accepted the scope?”

So, in my mind, this is a legitimate reason to change the end date of a Sprint.  I’m not sure it even counts as “extending”—the point is to keep the capacity constant.

I also told him that I don’t remember seeing “failed Sprint” in the Scrum Guide

Finally, if you think a little snow is a bad reason to lose productivity during a Sprint, Seattle sportswriter Art Thiel and I invite you to shut the hell up.

Keep warm, Seattle!  And don’t run your Prius inside!

Scrum for One

My customer is a team of one, which means that by the Scrum Guide he can’t be “doing Scrum”.  Whatever.  Scrum still has a lot to offer in his situation.

"Same procedure as every year, James."

My sächsische (Saxon) friends introduced me to the traditional New Year’s programme Dinner for One, in which elderly Miss Sophie’s loyal manservant James, due to personnel constraints, must attend to every detail of her 90th birthday party himself.

Last month, I visited a customer to perform NWC’s first official Scrum Health Check, a new offering I stole adapted from my colleague Martin’s blog post (“Are you doing Scrum? Really?“).  I sent lots of advance-prep materials and brought a beautifully-crafted checklist that I planned to use to determine their Scrum baseline.  But all that went out the window when I arrived onsite and found that my customer was a Scrum Team of One!

And then I tripped over a tiger

Me: First question.  Do you have Development Team(s) of 6±3?

Customer: Um, no.  There’s one other guy, sometimes, but we had this re-org and he reports to another manager now so… yeah, it’s pretty much just me.

Me: All righty!  Our Scrum Health Check is finished.  You are not doing Scrum.  Now, let’s talk about how you can use Scrum to make your… er, team… most effective in your situation.

And that’s what I’m about with Scrum.  Instead of throwing the entire Scrum Guide out the window, we kept it around and talked all day about the other Scrum practices my customer could use: in particular, we identified an ordered backlog and proper structure and focus for the biweekly Sprint Planning and Reviews/Retrospectives, to provide transparency and improve management buy-in.  These were his most urgent needs and we both agreed that Scrum could help—that’s why he picked it in the first place!

"Well, I'll do my very best!"

I consider myself fortunate to have arrived on the Scrum consulting scene right at the time when Scrum is making changes to become less rigid, less religious, and more widely useful (without diluting the structure that makes it so effective).  It would be a stupid waste (for all of us) to turn my customer away from Scrum just because he isn’t canon.

Scrum Renaissance

Are you sick and tired of rigidity and attitude in the Scrum community?  Me too.  So is Scrum.org.  Let’s get over it together so we can get some work done.

Stuff has been brewing in the Scrum world this autumn, and two big events aligned last month: the Professional Scrum Trainer global meetup followed by the ALM Summit.  I’m not a PST (yet), but the impact of the meetup was unmistakable as fired-up PSTs stormed the Summit and they and Scrum.org rolled out both conversations and official sessions with some of the new messaging around Scrum.

My PST colleague Martin is tackling a number of the substantive changes in his blog (“Are you doing Scrum? Really?” and others).  I think he captures well what I’m most excited about: the new language and the new approach do a lot to undo the rigidity and religious warring around Scrum.

To me, the first big hint of changes to come was when David Starr joined Scrum.org back in July.  In his announcement, he pointed out that he’s “more pragmatist than zealot” and wrote favorably about a long list of practices that many folks in the process community have made out to be “competitors of” or “incompatible with” Scrum for some reason.  I know David’s been involved in the Scrum.org world for a long time, but it struck me as potentially a big deal to have him officially on board.

Bringing a measure of tolerance to the process wars

In October, we got more evidence from Scrum.org that change was coming: “Scrum is Open for Modification and Extension“.  A coder might initially say “open to extension, closed to modification”, so it’s interesting to think about why they didn’t.  It’s gutsy for Scrum.org to put itself out there as willing to change the framework itself in response to community feedback.  Modification is formalized, which means it does not seem to be an invitation for immature teams to pick and choose and throw out and make up practices willy-nilly and call them “Scrum”.  I’m interested to see where that goes.

It had a good run

That brings us to the really big news: the death of Scrum But.

I have no doubt that Scrum But, as a concept, was intended to be helpful. I know this because I just finished co-authoring a slide deck built entirely around Scrum Buts: why your rationales are legitimate reactions to the difficulties of Scrum practice and should be heeded, and why a more thorough understanding of Scrum principles is almost always a better solution than a Scrum violation.  I am certain I was trying to be helpful.

Seriously, in the space of two weeks I went from “the trouble with your Scrum But deck is that you keep refusing to spell it with two Ts” to “you’re gonna have to throw out that Scrum But deck”.  Two weeks!  Is this a Renaissance or a Revolution?!

Scrum But is dead.  Long live the Scrum Curve!

The Scrum Curve: no buts about it

I stole this from Martin because it’s awesome and it’s a much more useful way to illustrate the point that matters: Scrum isn’t a boolean, it’s a continuum.  Teams may be doing Scrum to greater or lesser degrees.  Yes!  There is room for variability in practices that we can still call Scrum!  Now, instead of clucking (get it?) at teams for being “Scrum But”, we can help them refine and improve their Scrumminess to improve their performance. Instead of all or nothing, we can fully support incremental adoption and growth over time, including extension practices (like from Kanban) that working together take teams to Scrumfinity and beyond.

Update: It’s a good day for a Renaissance!  By delightful coincidence, Scrum.org rolled out their new front page today.  I’m excited to be engaged with what’s coming next!

Just look what they found space for!