Tyranny of the Sprint
Odeo just finished week one of Scrum, our new engineering and product development methodology. In Scrum, development is focused around month-long Sprints with the goal of delivering as much production-ready functionality as possible. It’s a management dream, engineers are constantly sprinting all-out and releasing massive amounts of features. No more worrying about motivation or snickering about herding cats. Engineering at full throttle. Hurray for management.
The top question from Odeo-ers hearing about Scrum was, “How much rest do we get between Sprints?” Normal Scrum methodology finishes the Sprint with a wrapup meeting, then the next Sprint starts with an all-day planning meeting, then it’s back to coding. In our case we’ll also have a weekend between since we’re doing Scrum on a 28 day cycle. So that’s four days of rest (non-coding) one of which is an all day meeting.
I guess that does sound intense.
I’d been thinking of Scrum as a marathon, as a way to keep focus between mile markers. You focus on one goal for four weeks then, take a refill of requirements, then settle in for the next four weeks.
Two problems with that. First, it’s called a Sprint so you’ve got to expect people to get pretty intense about effort and expectations. Second, it leaves engineering almost no time for context switching.
The latter is pretty important to me. We’re a small company. We rely on engineers making smart decisions and contributing feature ideas. Back-to-back sprints clearly doesn’t allow for this. What to do?
January 17th, 2006 at 8:44 am
Back to back Sprints do sound depressing. So what solutions are suggested? Even though it’s called a Sprint, perhaps it’s pace should not be stressful and creative/fun stuff should be integrated into it for developers during a Sprint.
January 17th, 2006 at 4:30 pm
That’s one way, make the sprint less stressful. We were thinking about having a week in between sprints. We could include the sprint planning day and the sprint wrapup in that week (Mon and Fri) and then maybe do a hack-a-thon or fix-it day.
January 28th, 2006 at 11:50 am
I find that context switching can be probelmatic.
One big problem with small companies is that they are resource poor. Context switching changes resource assignment within the company, and the suffle of resources effects feature velocity or the cost of engineering efforts.