Shopzilla Technology Blog

I’d been hearing murmurs about Kanban for the last six months or so but I only knew the basic concepts: it was a ‘pull method’ of Agile development that was picking up momentum and limited the amount of work the team took on at a given time. However, no one in the company was talking about it or implementing it on their teams and I hadn’t seen it in action yet. We’d toyed with maybe trying it out with one of the Bizrate teams but decided to hold off since January was rather hectic.

After a turbulent Q1 that threw our normal scrum process into disarray, it became obvious to the Bizrate operations team that we needed a change.

• A series of production emergencies made it apparent that although scrum gave us flexibility, it didn’t enable us to react to rapidly shifting business priorities. Even though we moved stories out to accommodate unscheduled work, the two week cycle wasn’t a good fit for how often our business changed – both in priorities and releases.
• Our team’s sense of commitment was constantly being eroded.  There was no way to protect the team’s focus. At the start of an iteration they’d implement a strategy to complete the body of work but the shifting priorities prevented them from executing.  The commitment went from, ‘We WILL get this done’ to ‘We’ll try, but it depends on what happens’.  What was the point of committing?
• We tried a dedicated resource to act as a fire chief for production emergencies but found often there were so many fires that tied directly to revenue that we actually needed the support of the entire team.
• Perhaps most important of all, there was so much waste. The team would start on something and have to abandon it mid way to support an emergency story.  Or, in other cases, we’d finish development & testing on a story but the effort to release was separate and could take two days or a week before the feature hit production which was becoming a source of frustration for the product team.

So when Kanban came back up in discussions it seemed like the perfect time to try something new. We knew a few things were going to have to change:

• The team would decide on a work in progress limit, or ‘WIP’. By limiting the number of things that are in progress at one time, the team works as a whole to deliver that piece of functionality and everyone owns getting those stories completed.
• Stories live on a Kanban board (Japanese for ‘sign board’) with a minimum of three columns: Ready, WIP & Done. Bizrate Ops has opted to only use these three general columns but other Kanban practitioners elect to have more.
• No more iteration planning. Kanban replaces this with small, adhoc meetings that happen as a new story is pulled in.  Only those who are going to be working on a story are involved in the conversation, cutting down on team members sitting through discussion on a story they don’t ever touch.  Same goes for demos. Retrospectives stay intact – what kind of an Agile team would we be if we never inspected & adapted?
• Priorities in the ‘Ready’ column are in constant flux. This gives the business team the flexibility to decide, as often as needed, what the most important story is while limiting the impact to the team and reducing wasted effort.

As part of implementing Kanban, the Bizrate operations team agreed we needed a new definition of ‘done’.  We decided that ‘done’ would no longer mean marked business accepted; instead it would mean live and available for use in production. This is a super exciting shift that pushes us to release things as soon as they’re ready, since a new story can’t be pulled in until we release and can see the feature in production.  If we’re at our WIP limit and there’s not any engineering to be done developers and front end engineers jump in to help execute test cases, run regression on release candidates; whatever it takes to get the story moved over to ‘Done’ so we can start on something new.

We’ve been using Kanban for the last 8 weeks and we’ve already eliminated some of our major problems with scrum.  Limiting our in progress work has greatly reduced abandoned stories.  Since applying Kanban we’ve only had to swap out one story and it came right back into the queue.  The business no longer waits for a release window; the team is eager to get a feature live so they can start something new.  We’re constantly delivering business value – as soon as a feature is blessed for production it’s deployed. Things hit production as soon as they possibly can; no more features languishing while they wait for a release window, and the team is empowered to see them all the way to done.

It’s Not All Roses

There are new obstacles to work through and we tackle these issues in our retrospectives.  Kanban makes bottlenecks and inefficiencies visible and we’re realizing that, although we’ve cut down our release preparation and deployment time, we still spend a lot of time on this step in our process.  At the outset, the team knew that adjusting the definition of done to include release to production would be painful. Adopting the mantra “if something’s painful, do it a lot”, we’re slowly but surely reducing the time taken to release. As we continue as a team, this won’t be the last time we need to adapt our process to meet our needs, but that’s the luxury of being Agile.