Schwaber and Beedle's Scrum book introduces the pig and chicken fable to illustrate a point. It goes something like this:
Chicken:
Let's start a restaurant!
Pig:
What would we call it?
Chicken:
Ham n' Eggs!
Pig: No thanks. I'd be committed, but you'd only be involved!
The story is used to illustrate a difference between
a) the core team members - the "pigs" who are committed to the success of the project (blood sweat and tears maybe?) and
b) outside contributors - the "chickens" who contribute but are presumably not "sacrificing" for the cause
First - I think the analogy is confusing. I always have a hard time explaining it and I haven't heard a coherent verbal description of the concept. There's got to be a better way to make the point.
My higher purpose here, however, is to extinguish the point.
A commonly cited rule is that "only pigs can talk in the stand-up". There is an underlying premise here that anything a "chicken" or non-core team member has to say is wasteful of the team's time. A corollary perhaps: anything a core team member has to say is important.
I have participated in stand-ups where chicken "contributions" have been extremely valuable. Example:
pig: "My computer monitor froze last night; I need to order a new one"
chicken: "Stop by my desk after stand-up. I have a spare"
pig: "Today, I'm meeting with the product owner to review stories for the next iteration"
chicken: "Product owner is out sick today. Let's talk after stand-up about rescheduling or doing it remotely"
Or how 'bout a chicken who participates in the stand-up and shares relevant information. Maybe the normal contribution is "pass" (meaning - there's nothing of import to the team to share). But maybe she's got something important to say:
chicken: "Yesterday, I met with a group of 6 customers to review the prototype. Feedback was overwhelmingly positive. They had some good suggestions. Today, I'd like to sit down with Joe to review some of them and get stories added to the backlog".
What a great contribution to the stand-up! The team gets a valuable shot in the arm (positive feedback) and Joe gets a heads up on some work for later that day.
I've also witnessed many examples of core team members' verbosity and sharing unimportant information.
pig: "Yesterday I had a one-on-one with my manager and worked on my mid-year performance review"
Huh? It seems that this information is being shared not for the benefit of the team, but to justify someone's paycheck for the time they spent in the office.
pig: "I ran into an issue when creating the xyz service. When I compiled the code, I got an Exception in the compiler. I stepped through the compiler assembler logic, but couldn't figure anything out. I then spent about an hour on Google looking for the cause. I finally found this bizarre reference in a Japanese website - thank goodness for Google translation - but it's kind of funny how they botch the translation, I mean, it's not exactly the King's English. Anyway, I translated it, and found someone had this issue because they were running service pack 1 of the IDE without the next two patches on a MacBook Pro running Boot Camp. I installed the patches and still had the problem. I tried a bunch of other things after that and finally got things working. I think clearing the cache did the trick. I thought I'd be done yesterday, but that issue set me back a bit. Barring any other bizarre issues today, I expect to be done with the story by end of day.
OK, I made all that stuff up. This guy needs some coaching on being more succinct. There's some valuable info in there ("hey everyone - make sure you have those two patches", and "I should be done today") but it's buried in irrelevant detail.
My general point is this: I think the chickens/pigs designation is more harmful than helpful. Common sense - about what's valuable to share - should carry the day. Open and honest conversations with *all* participants about expected behavior in stand-ups and beyond should trump this arbitrary dividing line about whose voice should be heard when.
Showing posts with label Scrum. Show all posts
Showing posts with label Scrum. Show all posts
Saturday, June 18, 2011
Tuesday, February 17, 2009
Iron Chef Retrospectives
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.
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.
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)
