Wednesday, February 11, 2009

Infusing some Kanban...

The team I am working with was starting to have a few issues. We had too much on our plates, lots of noise, and the CEO was raising concerns that we weren't focused on the right things. We also had a feeling that the sprint end and begin was a magical flurry of stressful activity.

So we've implemented some changes:
  • Our cards on a wall board is now restricted. Only 5 things can be in flight at a time. Everything is still in VersionOne; but only the top 5 get the explicit visibility of being important enough to be covered every single day.
  • The CEO (highest level product owner) is responsible for filling and prioritizing the +5 queue whenever there is an opening. These are the next 5 things expected to move into flight.
  • Our standups are no longer going to be asking the 3 questions going around the circle in the sequence we lined up around the room. Instead we are going to first talk through the top5, and then use the time remaining to discuss other notables as people need to. The team is responsible for taking their turn by importance and not going in sequence.
Our hope:
  • This will shift focus from what "I am working on" to what "the team is delivering for the company".
  • We might not get to every topic since not everyone will have an explicit turn, but we guarantee that we are talking about the right things.
  • Outsiders can attend the standing meeting and easily see certain items and their status as opposed to hearing about an item across people throughout the meeting.
  • We force the business to shift from magically identifying 5 things every Friday (1 week sprints) to constantly filling a pipe of work every day as we empty it.
  • It is easier to see if our commitments of date and cost are at risk and communicate that to stakeholders because the topic is covered at once. (Our commitments are more safely limited to the top5.)
We see how it goes... (like many issues, we'll implement changes and slowly snap back to a happy medium as we learn and grow)


  1. Although we are only applying Scrum, I tried once to apply one of the practices of Lean

    Our product owner said "he would be happy" if we finish a couple of items, yet, after estimation we could only schedule 85% of the tasks, and that 85% won't produce a deliverable

    So instead, i thought of adding some days to the sprint so we can schedule the whole requirements and the whole team felt happy when we could have something to demo at the end of the sprint

  2. Depending on how long your sprint is, this might be a good way to get rolling in the early phases of the project.

    Teams should always be aware that smaller is better... but it takes some coaching or experience to learn how to slice stories (what I'm hoping you meant by tasks) in a way that delivers business value in small pieces. Hopefully your sprint is never longer than 30 days... I prefer 14 days, but right now we are running 7 day sprints.