I like cooking analogies to software. Lachlan Heasman recently posted a comparison between Iron Chef and scrum iterations. One missing component was the retrospective. It occurred to me that the chefs must do some sort of retrospective and that it would be interesting to see on TV. So I penned the following to Food Network this morning:
I'm a software engineer and a die-hard Food Network fan. I often use cooking analogies when coaching other software professionals on how to improve their approach to software development. Mise en place is one of my favorites.
I recently encountered a comparison of the Iron Chef competition to software development. One of the components of our approach in software is to use "retrospectives" to look back upon the iteration of software development we have completed to improve how we do things. We revisit what went well, what didn't go well and adapt our approach to learn from our mistakes
It occurred to me that the Iron Chef competitors must do "retrospectives" as well. I can imagine Cat Cora sitting around a table with her chefs over shots of Ouzo dissecting the completed competition and finding reasons to celebrate and opportunities for improvement.
I think it would be fantastic to have a postscript TV show to film the two teams in their analysis of the competition. You could intersperse clips from the actual competition when chefs refer to certain activities. It would also be interesting to hear what the chefs *really* think about the comments from the judges and how they might change what they did based on those comments.
Tuesday, February 17, 2009
Tuesday, February 10, 2009
Friday, February 06, 2009
Iteration Length
What's the right iteration length?
In Scrum, the recommendation is to start with thirty calendar days. From the Schwaber/Beetle book: section 3.6.3 Sprint Mechanics:
"Sprints last for 30 calendar days" and "thirty days is an excellent compromise between competing pressures". Though "Adustments can be made to the duration after everyone has more experience with Scrum".
My first reaction to the number 30 is that this is a nonstarter. What happens when your sprint boundary occurs on a weekend? How do you schedule sprint transition meetings? I know of no calendaring program that schedules meetings "every 30 days". Monthly? Yes. Every n weeks? Yes. But not every 30 days. The organizations I know that have implemented scrum by the book have scheduled n-week sprints, in order to maintain a consistency of scheduling (e.g. Wednesday afternoons are for sprint reviews).
Many novice scrum practioners resort to quoting "the book" when arguing for 30-day, by which they mean quad-weekly (which I will hereafter refer to as monthly for terseness) sprints. Suggestions to shorten sprints (e.g. to 2-weeks) yield objections along the lines of "with twice the meetings, we'll have less time to get work done. We already spend two days in our sprint transition meetings"
First of all, if the team is spending two days on monthly sprint transition activities, something is very seriously wrong. Really.
Sprint reviews (or showcases in the more generally accepted agile lingo) are about showing working software. They should not be about burn-ups and burn-downs and justifying the team's existence. You should never find yourself in a showcase/sprint review talking about the percentage completion of a story. Show the working stuff or sit down.
If you follow this pattern, the showcase/sprint review length should be proportional to the length of the iteration. If your iteration length is cut in half, your showcase should take half the time. After all, you're only showcasing half the functionality! (OK... maybe it's not exactly half. I would argue that two week sprints are more productive than monthly.)
Iteration planning should be a no-brainer. Preparation for the sprint planning meeting is on the business analysts, product owner, scrum master, project manager... everything should be pretty well layed out in advance. It should take no longer than an hour to do an IPM (iteration planning meeting). Unless, of course, you feel that task breakdown is necessary during the IPM (another Scrum approach with which I generally disagree). In any case, the IPM length should be proportional to the length of the iteration.
-begin sarcasm- How 'bout a 3-week iteration? Wouldn't that be a reasonable compromise? -end sarcasm-
Sprintly Retrospectives are another issue. Can you halve the time spent in retrospectives if you halve the iteration length? Probably not. But this, I feel, is not the right question. Are you getting value out of your retrospectives? If not, figure out how to get value. You don't necessarily need all the typical pomp and circumstance of a full-blown retrospective to impart the "adapt" portion of the "Inspect and Adapt" mantra. Too many teams, in my experience, adhere to the scheduling and process of retrospectives without digging deeply into different ways of adapting the team's approach to being effective and efficient.
More advanced teams can consider whether iteration ceremony is even necessary. A more lean approach would be to consider the flow of the work and to simply feed work into the development "machine" at a rate at which it consumes the work. "Inspect and adapt" would be continuous; retrospectives would focus on specific issues or areas of concern (rather than specific time periods across which many different kinds of issues may require attention). Classic iteration planning would yield to on-demand prioritization and estimation exercises - delayed to the last responsible moment. Reviews of completed functionality would be scheduled on demand for individual stories and perhaps with more ceremony when a critical mass of functionality has been completed.
What's the right iteration length for you? My recommendation is 12 days, 6 hours, and 24 minutes. (Oops... forgot the sarcasm tag)
In Scrum, the recommendation is to start with thirty calendar days. From the Schwaber/Beetle book: section 3.6.3 Sprint Mechanics:
"Sprints last for 30 calendar days" and "thirty days is an excellent compromise between competing pressures". Though "Adustments can be made to the duration after everyone has more experience with Scrum".
My first reaction to the number 30 is that this is a nonstarter. What happens when your sprint boundary occurs on a weekend? How do you schedule sprint transition meetings? I know of no calendaring program that schedules meetings "every 30 days". Monthly? Yes. Every n weeks? Yes. But not every 30 days. The organizations I know that have implemented scrum by the book have scheduled n-week sprints, in order to maintain a consistency of scheduling (e.g. Wednesday afternoons are for sprint reviews).
Many novice scrum practioners resort to quoting "the book" when arguing for 30-day, by which they mean quad-weekly (which I will hereafter refer to as monthly for terseness) sprints. Suggestions to shorten sprints (e.g. to 2-weeks) yield objections along the lines of "with twice the meetings, we'll have less time to get work done. We already spend two days in our sprint transition meetings"
First of all, if the team is spending two days on monthly sprint transition activities, something is very seriously wrong. Really.
Sprint reviews (or showcases in the more generally accepted agile lingo) are about showing working software. They should not be about burn-ups and burn-downs and justifying the team's existence. You should never find yourself in a showcase/sprint review talking about the percentage completion of a story. Show the working stuff or sit down.
If you follow this pattern, the showcase/sprint review length should be proportional to the length of the iteration. If your iteration length is cut in half, your showcase should take half the time. After all, you're only showcasing half the functionality! (OK... maybe it's not exactly half. I would argue that two week sprints are more productive than monthly.)
Iteration planning should be a no-brainer. Preparation for the sprint planning meeting is on the business analysts, product owner, scrum master, project manager... everything should be pretty well layed out in advance. It should take no longer than an hour to do an IPM (iteration planning meeting). Unless, of course, you feel that task breakdown is necessary during the IPM (another Scrum approach with which I generally disagree). In any case, the IPM length should be proportional to the length of the iteration.
-begin sarcasm- How 'bout a 3-week iteration? Wouldn't that be a reasonable compromise? -end sarcasm-
Sprintly Retrospectives are another issue. Can you halve the time spent in retrospectives if you halve the iteration length? Probably not. But this, I feel, is not the right question. Are you getting value out of your retrospectives? If not, figure out how to get value. You don't necessarily need all the typical pomp and circumstance of a full-blown retrospective to impart the "adapt" portion of the "Inspect and Adapt" mantra. Too many teams, in my experience, adhere to the scheduling and process of retrospectives without digging deeply into different ways of adapting the team's approach to being effective and efficient.
More advanced teams can consider whether iteration ceremony is even necessary. A more lean approach would be to consider the flow of the work and to simply feed work into the development "machine" at a rate at which it consumes the work. "Inspect and adapt" would be continuous; retrospectives would focus on specific issues or areas of concern (rather than specific time periods across which many different kinds of issues may require attention). Classic iteration planning would yield to on-demand prioritization and estimation exercises - delayed to the last responsible moment. Reviews of completed functionality would be scheduled on demand for individual stories and perhaps with more ceremony when a critical mass of functionality has been completed.
What's the right iteration length for you? My recommendation is 12 days, 6 hours, and 24 minutes. (Oops... forgot the sarcasm tag)
Subscribe to:
Posts (Atom)
