At Digité/ Swift-Kanban, we had a great visit to the LeanSSC (now Lean Systems Society) last week in Boston. Having been in the market for just about a year, it is heartening to be recognized and even be told that we are considered one of the top 2-3 Kanban tools that are out there.
An exciting part of the conference was our announcement of our support for Scrumban (or Scrum features) besides our support for both iOS and Android tablets. Those who came to the booth and saw a demo really loved our embedded support for release/ iteration planning, time capture, burn-down/ burn-up charts and all of the other new features we demonstrated during the show.
Someone from a competitor’s booth next to us in fact said we were pretty much the first Scrumban tool in the market, a possibility we had considered and talked about, although somewhat hesitantly!
The labeling of Scrumban was a matter of some discussion – both at the booth but more interestingly at the Monday (or Tuesday) morning Lean Coffee session organized by Jim Benson, where I posed the question – Scrum –> Kanban = Scrumban or Kanban? In other words, when a Scrum team uses Kanban to improve their processes, is the end-result that they begin using a combination of Scrum and Kanban (Scrumban) or do they essentially start using just Kanban for software development? Luckily for me, this question got the most votes and ended up being discussed for quite some time.
There were some great people at the table besides Jim – Jason Montague, Jabe Bloom, Alexei Zheglov and Joe Campbell amongst others and multiple opinions emerged around the table. Most people felt that it would really depend on the team. The more mature the team, the greater likelihood that they would be able to get away from the “constraints” of Scrum such as using the time-box – and thus just be using a Kanban process. By implication, the less mature or less ‘self-organized’ teams would continue to use the time-box within the overall framework of Kanban. Thus they would be using a Scrumban process.
A second perspective was that most teams might use Scrumban as a transition phase before moving over completely to Kanban, giving up the time-box and to a more continuous delivery model. (I should clarify that while the time-box was the main feature of Scrum being discussed, other aspects of the difference between Scrum and Kanban were also discussed.)
Finally, someone who joined towards the second half of the discussion added a third perspective – that if the purpose of Kanban was to help you improve what you are already doing, it is perfectly possible to believe that they may come out of that experience with a “better Scrum process”!
An added point that I wanted to get everyone’s vote on was whether Scrumban was a valid term that described either a transition or a longer lasting phase of a team using both Scrum and Kanban. Most people around the table agreed that it was a valid phrase to use. All in all, it was a great discussion and a learning experience – and I look forward to reactions from other prospects and customers of SwiftKanban for further validation or repudiation of the premise!
Looking forward to the LSS13 in Chicago in April, 2013!
Co-founder/Sr. VP – Product