Meet with Confidence

From SCRUM to Kanban

Posted by Jason Collins on
Share this Post:

As many of you regular readers may know, we're an agile development shop. We have been running a process known as SCRUM for quite some time now. We've had a lot of success with it, and we've learned a lot along the way. That's how these agile processes work; continue to inspect and adapt and evaluate and adjust. If something isn't working, put some time and energy into thinking about why it isn't working and figure out a way to improve it as a team. As we've grown and scaled to more small SCRUM teams, we've realized that we could be gaining even more efficiencies because the start and stop points of an iteration tend to slow a team down.

Gaining efficiencies

Enter Kanban. Kanban is similar to SCRUM in many ways, but one of the fundamental differences is there is no concept of an iteration. The process allows for and supports a model of continuous flow. If I had to come up with an analogy, it would be that of mail pickup from a train. The time wasted when a train has to stop, pick up the mail, and start again is tremendous when you are trying to maintain a schedule; instead let the train keep momentum and put the mail out to be picked up as it rolls by. Similarly, a software development team that is comfortable enough with ad-hoc and as-needed meetings can gain efficiencies by not stopping to "pick up the mail". The backlog can be replenished as needed by a very involved product owner. The team can continue to retrospect and adapt and communicate without slowing down the momentum they are making on a feature release.

We began by trying Kanban with a single team that was very operational in nature. This worked well because it allowed the team to deal with those operational issues that came up while still keeping momentum on everything else. They didn't have to worry about the operational issues killing their iteration commitments, which can be a morale hit, even though the business understood the impact that operational work had on the team in a SCRUM process. It was more of a mental victory than anything else.

We've since scaled the Kanban process to a number of feature teams and we plan on rolling it out across all of engineering. The feedback from the teams has been great, and the product owners have been supportive and understanding of the change in how a team's velocity is tracked (cycle time vs. story point velocity). As a part of this process, we also moved from component teams to feature teams, which has been a huge benefit in keeping teams focused on a single project before moving on to the next project. Have you experimented with Kanban? Are you suffering from some of the same problems in your SCRUM process? I'd love to hear thoughts that you may have on this topic!

Jason Collins (aka JC) is the VP of Engineering at ReadyTalk and the self-appointed Chief Happiness Officer. He’s been either writing code or managing engineers for nearly 15 years and has a passion for technology and agile development practices. The happiness of the engineering team is his top priority and he can usually be found wearing a ReadyTalk cape and the infamous “idea helmet” around the office to help keep people motivated and entertained. When he’s not hanging out with his work family, he’s at home with his wife and four boys doing all sorts of geeky things, like playing video games and watching campy Sci-Fi and Action flicks.

Name: Agile Scout
Time: Monday, September 5, 2011

Great story here! Looking forward to more blog posts on kanban as you guys go along!

Name: Jason Collins
Time: Monday, September 12, 2011

We'll be sure to keep everyone posted. So far, the teams that we've converted are really enjoying what they are seeing from the Kanban process. I am sure there will be lessons to be learned from all this, so I'll try to bring some visibility to those as well. We'd love to be able to give advice to other teams looking at making a similar transition.

Name: Susana Cabaço
Time: Tuesday, October 4, 2011

Hi, I didn't quite get what were your problems with SCRUM... I understand for operational non-deterministic stuff kanban can be a benefit, actually more of a combination of agile practices and using a kanban board. Still, a replacement? That is hard to grasp. And it leads me to raise other questions, namely what are the shippable items and how are they planned and delivered... and a few others. Could you ellaborate more on this perspective you shared? Thanks!

Name: Jason Collins
Time: Thursday, October 13, 2011

Hi Susana, Thanks for commenting, I love getting good conversation going about these things. The points you make are completely valid. Here at ReadyTalk, our engineering teams are very involved in supporting the customer care teams when helping troubleshoot customer problems. Due to the fact that our number one priority is always our customers, this adds an aspect of operational type work to all of our engineering teams. For this reason, ditching the stop/start of sprints has been beneficial because more often than not some number of stories would carry over and we felt like the velocity numbers were never truly accurate. With Kanban and tracking cycle time, we are able to average in the time spent supporting other groups, which in theory will help our project estimates. As I mentioned, we are still in the early stages of Kanban so our theories may need to be adjusted as we go and learn more from this process. In addition to having to account for operational type work, limiting the work in progress is very appealing, especially in cases where the QA work actually takes longer than the development work due to complicated load and failover testing. This helps prevent the software engineers from getting too far ahead of the QA engineers. In terms of shippable items, we still work a feature by decomposing it into small user stories, but instead of the traditional set of story point values used in Scrum we are trying a 1/5/10 approach. Over time, we'll be able to average the cycle time for each size of story and plan based on those average cycle times. I hope this answers your questions, but if not please let me know. Thanks! - JC

Comments for From SCRUM to Kanban

blog comments powered by Disqus

Recent Posts

Does your tech company have what it takes to compete in the Colfax Relay?

Does your tech company have what it takes to compete in the Colfax Relay? Living a healthy lifestyle is an important part of the ReadyTalk culture. When we hire, we look for...

Mobile Optimization Explained

How to Better Market to a Mobile Audience Yesterday, we had the pleasure of sponsoring an AMA Webinar, “Conversion Optimization in a Multi-Device World.” Led by Chris Goward, CEO...

Try out ReadyTalk Video Lab for Your Next Meeting!

Ready to try something new? Check out ReadyTalk Video Lab, an experiential video conferencing and VoIP solution that's ideal for small, interactive meetings. We are asking...

Want One-Click Meetings?

Want One-Click Meetings?   Phone number. Access Code. #. Press *2. Pin number. #. Listen to recording of options. Meeting begins. The traditional method of starting a conference...

Love Your Mobile Phone? So do we.

Love Your Mobile Phone? So do we. You probably spend more time with your mobile phone than you do with your significant other. After all, it’s with you at work, your commute and at...

Stop. Collaborate and Listen.

Stop. Collaborate and Listen. ReadyTalk plays an important role for teams who want to collaborate during meetings. Unlike webinars with only one or two presenters, collaborative...

Meetings! Meetings! And More Meetings! How Much are They Really Costing You?

Are you running from meeting to meeting? Are there clear agendas, action items and decisions being made in all these meetings?  Do you even know why you were requested to attend?...

Technology Tools for Remote Workers

Technology Tools for Remote Workers Telecommuting, remote work and flex schedules are rising in popularity. On a recent webinar, Out of the Office: Tips and Best Practices for...

Improving Your Remote Work Experience

Improving Your Remote Work Experience Being a remote employee can be both rewarding and challenging. You’re often reliant on in-office colleagues to communicate important details,...