« Previous Entries

The Archives

Kanban Man!
Kanban: “Just set it and forget it!”
05.25.08 | Permalink |
Late last year I set up a kanban system for a Yahoo! India team. They had lots of little features and bug fixes to work on, but they didn’t know how to organize it all to get it done. Scrum wasn’t working well because the nature of the work was too dynamic.

Armed with blue painter’s tape (imported) and post-it’s (imported too) I worked with the lead developer & producer to set it up. I briefly discussed the principals that makes the system work: reduce WIP to increase throughput, use the post-it’s as a signal to begin work.

Time for team indoctrination. The lead engineer explained the system to the folks on the team.
1. The producer/product manager will queue up ‘things to do’, limited to 5
2. The developers will take the top items from the top of the queue
3. When the developers are done, they will be placed in the ‘dev done’ slot
4. Then the testers will pick up items from the ‘dev done’ slot and test them
5. When the ‘thing to do’ is done to the tester’s and producer’s/product manger’s satisfaction, it’s ready to release.
I sat back and just watched it unfold. Every few weeks I would go by and I’d stop in to see how things were going. The system was just like a machine; it was systematically pushing features & bug fixes through the team in a very transparent way. The tech lead moved to another project and the kanban system kept working. A new product manager came in and the kanban system kept working.

Ron Popeil sells a Rotisserie & BBQ Oven with the tag line, ‘Just set it and forget it!’ My Aunt ordered the machine. The first thing that you see when you open the box is (I’m paraphrasing from memory) “WARNING! While the slogan may be ‘Just set it and forget it!’ it doesn’t mean you can leave the machine unattended at any time. As with any kitchen appliance involving high temperatures, you must take caution.”

This team, did not literally ’set it and forget it’. But it was a system that worked very for them with few modifications. They were largely in maintenance mode and were tasked with fixing bugs, making performance improvements, fixing production issues and making incremental improvements.
XP, not your mama's process
Velocity is not a transitive property
05.13.08 | Permalink |

In software, one thing is certain — estimates never match reality. Teams build predictable schedules by creating buffers. There are two strategies to do this: 1) by forecasting how much buffer the team needs 2) by computing buffer based on past performance.

Velocity is a way compute how much real time it takes to complete estimated time.

So if I say something will take me 4 hours to build and it takes me two days to complete, my velocity would be 2h/day. That’s useful for future planning because the team knows my capacity (2hr x 5days = 10 estimated hours / week).

A velocity measurement doesn’t say how hard I worked or how much time I spent on the task. It’s merely a calibration tool for effective planning.

My 4 hour estimate (that took two days) from the above example might of seemed awfully optimistic. But that’s not how to see it. I could of ran into an unforeseen complexity, faced an unusually large meeting load, or could have been bogged down with operational issues. Or it might be true, I might just be an optimistic estimator, but with velocity that’s okay. It all averages out.

Teams will also come together to estimate entire features this way. They might estimate how long the feature will take in days. But again, estimated time never equals actual calendar time. So if it takes the team estimates a feature to take 1 day, and it ends up taking 2 days to complete, their velocity would be 2.5 estimated days / week.

Here’s where it gets tricky and controversial…

To get better at estimating when using velocity means getting more precise rather than accurate.

Teams who are good at estimating with velocity will normalize on an inaccurate, but precise value, rather than try to get more accurate. The consequence is that each team (or person) will have their own, unique velocity. Some teams will estimate conservatively and others will estimate optimistically. It is meaningless to compare from team to team or location to location. It just doesn’t make sense. In fact, the moment you start judging teams on ‘improving’ their velocity, their estimates just become more conservative. (Thereby increasing their velocity.)

Some teams have a difficult time using velocity. This is because when a team settles down on a velocity, they question themselves (or get questioned) if it’s not 8 hours of estimated work a day. “How come you’re only planning for 5 hours of work a day! What’s wrong?” (One of the most productive teams I’ve worked with averaged 2hr estimated / person / day!)

Use velocity, but keep in mind that a team’s velocity can’t be compared with other teams. So keep the velocity numbers within the team. If you must report your estimates externally, either take the time to explain velocity or normalize your estimates into real time. Better yet, translate your estimates into dollar (or rupee) values (talk with your finance person to work out some numbers).
Kanban Man!, MMF
The Minimal Marketable Feature (MMF)
03.22.08 | Permalink | 1622 Comments

A Minimal Marketable Feature (MMF) is a feature that is minimal, because if it was any smaller, it would not be marketable. A MMF is marketable, because when it is released as part of a product, people would use (or buy) the feature.

As a counter-example to the MMF approach: While working on an XP team, our team decomposed features into super-small stories. That way the customer (product manager) could pick-and choose from the sub-features to create the big feature. The team would present a list of each sub-feature like a grocery bill — each item has a cost. For example, the customer might decide that pagination (presenting a list of information on multiple pages) just isn’t worth it, because “hey, we only have 25 rows of data right now!”

An MMF is different than a typical User Story in Scrum or Extreme Programming. Where multiple User Stories might be coalesced to form a single marketable feature, MMFs are a little bit bigger. Often, there is a release after each MMF is complete.

An MMF doesn’t decompose down into smaller sub-feature, but it is big enough to launch on its own.

A MMF can be represented as a User Story — a short, one-sentence description.

The format of a user story is:
As a [some user], I want [to do something], so that [I can achieve some goal]

But in contrast to how a User Story is typically used, the team would not break down the User Story into smaller User Stories when using MMFs. Think of it this way: *Gather up all the stories that share the same so that clause — that’s your MMF*.