Moving to Kanban, Did Scrum Fail?

Tim Barcz — Fri, 07 Aug 2009 03:25:00 GMT

Several months ago our software team decided to dive into the Scrum process. What we were doing before that simply wasn't working. The project had unstable delivery dates and we knew something needed to change.

Fast forward about four months and we're going to take a shot at using Kanban and leave Scrum behind. Quite surprising since I blogged that Scrum was a pretty good development methodology. Why change if Scrum is so great? Did Scrum fail? Is Kanban that much better? Is Kanban Better than scrum? Read on fellow Kaizenista.

Why Change To Kanban?

The developers that I work with are professionals at their core. For us we want to deliver code, we want to make an impact. We want a consistent process that brings us maximal results. We want a process that aides our development and doesn't impede it.

I work for the world's largest motorcycle parts and accessories dealer. The code we right is in high demand, we want to get it out to the world as soon as possible. Scrum imposes sprints and releases (several sprints) on the team. We found that we don't work that way. If a feature is "done, done, done" we promote it to production we don't wait for an arbitrary end of sprint. This seems to fit better with Kanban.

Secondly we want to reduce lead times, see features get implemented quicker. While we saw a huge improvement with the adoption of scrum, the idea of a pull system versus a sprint backlog would have meant shorter lead time in several cases in the recent past.

There are other reasons, but they all point to our desire to produce more. Upper management has been quite pleased with scrum. They see consistent work being accomplished and goals being met and the team quite happy. I had a discussion with my boss today about Kanban and was initially hesitant given only four months of using scrum. He was thrilled with the idea of us working in ways to improve the process.

Did Scrum Fail?

I was asked my thoughts on a similar question on the drive home tonight by Chris Missal. I absolutely don't think Scrum failed. Scrum was a huge improvement and has shown us that it is okay to experiment and tweak with processes. Had we adopted Kanban several months ago rather than first going through Scrum I believe our Kanban process would not have gone over well. Quite simply we wouldn't have done it right. Now, after having worked in Scrum, we're transitioning to Kanban to address very specific points where we see waste.

Is Kanban Better than Scrum?

Nope, Scrum is a perfectly fine solution and I don't have a negative thing to say about it. For us Kanban seems to work more the way we work.

It's like putting on a tennis shoes to go golfing in then later trading in the tennis shoes for a pair of golf spikes. The spikes are better than tennis shoes but the tennis shoes are better than nothing (barefoot).

It's a better fit. For the way our process flows and how we work, Scrum was like golfing in tennis shoes, it was an improvement but there are better optimizations to be made. If Scrum is working for you, great. For us we wanted to try Kanban.

How are you Going to Start?

First, we don't know much about Kanban. No one on our team carries certification like I do with Scrum. Therefore we're going to leverage you, the community, and our passion to learn and improve. We're going to use post's from great authors and teachers like Derick Bailey who posted yesterday (very well timed Derick) about "How To Get Started With Kanban In Software Development". We're going to become student of Kanban and more importantly process improvement. Ultimately I don't want the fear of something new to stop of from trying something that could help us. You have to experiment, tweak, and never be satisfied where you sit, you can always improve something.

I'll keep you all posted as we go forward. My hope is that the improvement we saw with Scrum will be magnified and we'll see similar improvements with Kanban.

Will keep you posted.

Scrum - A Not-so-bad Development Methodology

Tim Barcz — Mon, 18 Aug 2008 19:49:59 GMT

When I first graduated from college I worked on embedded systems where the process was a formal, military grade process. When developing software I typically thought about what document I had to write next and what document(s) I may be missing. In general, the MIL standards turned me off a bit to process, and for awhile left me thinking that process is an obstruction to true development. As a 21 year old, you think code = development. That was/is an immature point of view, but it was not a viewpoint that I was easily dissuaded from. Further it's a point of view that many out there still hold dear, and not all who hold that view are recent college graduates.

Recently a small group of us decided to give Scrum a try and are using it to drive our current project. Other than this effort, there is no formal process methodology in place. My goal is to help change that in my new position. Over the past several years many high value projects have never been worked on because there was no common backlog of all of the things that need to be done.

In my last job at Geonetric we adopted Scrum after the absence of a formal methodology and it provided a much needed framework around which to develop. Many CEO's are not this up front with their deficiencies, but Eric is pretty awesome and very honest in his evaluation of Geonetric:

As we were in the middle of developing the newest version of our VitalSite product last fall, we weren’t making the progress we wanted-even though the whole team was running full tilt and putting in its best efforts. We had always been a bit informal about how we developed software-somewhere between draconian rigid requirements and completely freeform cowboy (and cowgirl!) coding practices. The problem was that being in the middle wasn’t working. So, we looked at some of the newest practices in the industry.

Eric goes on to list the benefits he's seen since adopting Scrum:

Since adopting Scrum, the first two releases of VitalSite 5 have been on-target, meeting both scope and deadline requirements (5.0 in January and 5.1 in May).

Software development is accelerating each sprint - we’re approaching twice the speed we had last year.

There’s much more collaboration between disciplines

The morale of the software team is higher

Quality of the software we’re delivering is better

With results like that I can see why a CEO would like scrum. As developer though, I like scrum in that it doesn't get in my way. There is administrative overhead to Scrum to be sure. However it's very "XP" in that there aren't scads of documentation to write. Generally as a software professional I like to write code and solve problems and for the most part Scrum allows me to do that. My development does not feel slowed down by Scrum, which I believe for most developers, is a must in order to be adopted willingly.

One side effect of scrum is that is causes me to think about the process in a pleasant way. This morning at our standup meeting, a fellow developer and I got into a discussion about how his extra exploratory work in the evenings should be factored into our sprint. Should we could his work towards our sprint commitment? Will his work negatively/positively affect our velocity for future sprints? From my experience, developers typically don't worry about this stuff however with Scrum the sprint commitment is something that should be taken seriously. As such it was good to see developers, of which I was one, having talks about other things that just the code.

I'm sure many other processes out there could achieve the same thing. Scrum for us, both in this job and the previous, provided a nice framework that was palatable to developers. In that respect I'm perfectly happy using Scrum. I will keep my ears open for new ideas and processes, but I think for any development methodology to be successful in an organization, it has to be readily and whole-heartedly adopted. We've enjoyed Scrum so far and as such, it's a not-so-bad development methodology. If you aren't using a methodology or your current process isn't working, you should give Scrum a try.

Tim Barcz : Scrum

Moving to Kanban, Did Scrum Fail?

Why Change To Kanban?

Did Scrum Fail?

Is Kanban Better than Scrum?

How are you Going to Start?

Scrum - A Not-so-bad Development Methodology