rickgaribay.net

Space shuttles aren't built for rocket scientists, they're built for astronauts. The goal isn't the ship, its the moon.
posts - 303, comments - 180, trackbacks - 35

My Links

News

Where's Rick?


AgileAlliance deliver:Agile 2019- 4/29
Desert Code Camp, PHX - 10/11
VS Live Austin, TX - 6/3
VS Live SF - 6/17


About Me
Hands on leader, developer, architect specializing in the design and delivery of distributed systems in lean, agile environments with an emphasis in continuous improvement across people, process and technology. Speaker and published author with 18 years' experience leading the delivery of large and/or complex, high-impact distributed solutions in Retail, Intelligent Transportation, and Gaming & Hospitality.

I'm currently a Principal Engineer at Amazon, within the North America Consumer organization leading our global listings strategy that enable bulk and non-bulk listing experiences for our WW Selling Partners via apps, devices and APIs.

Full bio

Note: All postings on this site are my own and don’t necessarily represent the views of my employer.



Check out my publications on Amazon Kindle!





Archives

Post Categories

Published Works

Tuesday, September 10, 2013

On Sprint Duration

I recently had a good internal discussion on 2 week versus 3 week sprints getting ready to kick off a new project for a client.

This is a debate that's been happening in the agile community for well over a decade, and while there is now broad consensus 10 years later that 4 weeks is almost always highly undesirable, the thing to remember is that the quality, caliber and discipline of the team is absolutely essential regardless of sprint duration.


I Just Want to Dance!

The most common argument against two week sprints is that the planning ceremonies occupy too much time and effectively reduce the team's delivery time from 10 days to less than 8. This is true for severely under-performing teams. High performing teams should be able to land demo and retro in one day and planning in as little as half a day. If the only time a team communicates is during these ceremonies, the time will drag on even further.

Performing teams communicate and practice dress rehearsals of demos, have a backlog groomed and ready to go and in some cases, might even have stories already decomposed and ready to go (signaling strong alignment with business prioritization). 

Deployment Happens

The other common argument is that deployment time cuts further into delivery time, and now that 8 days is more like 7 days because it takes a day to deploy. This is true of teams that are practitioners of cargo cult agile development. If you don't have unit tests and automated builds in place, you _will_ feel pain each and every sprint.

Snake Oil

One solution to this dilemma that sometimes comes up is to start with say 3 week sprints and then, when the team has "earned" 2 week sprints, reduce the sprint time accordingly. This is an anti-pattern for the simple reason that you can't improve what you can't measure and if you go around changing sprint duration, velocity becomes corrupt. This means that your ability to predict future velocity is severely impeded which affects budget, staffing and obviously has schedule implications.

Why Two Week Sprints Work

Two week sprints are highly advantageous when you have a high degree of risk and delivering new innovation because they provide tighter intervals with which to adapt and adjust. While 3 week sprints can be successful, most often they are merely masking the lack of efficiency of the team and providing a fig leaf to hide behind- in my experience in almost every case, you will find that productive, heads down time turns out to still be just under 2 weeks!

When building a team, you should settle for no less than A-Team players that are going to kick ass and take names from day one. If you do the heavily lifting to invest in building the right team, the sprint duration won't matter nearly as much, but if you are not committed to this from day zero, no amount of sprint duration optimization will save you from failure.

posted @ Tuesday, September 10, 2013 5:21 PM | Feedback (0) | Filed Under [ Processs Projects ALM ]

Powered by: