Abstract

I’m going to step into a minefield, because in this post, I’m going to share my subjective experiences with Scrum, and I’m going to share the reasons why I moved from Scrum to XP + Kanban. I’m using the minefield metaphor, because every single sentence I’m going to share can be exploded with good explanations, mostly from advanced scrum practitioners.

Again, this post is going to be very subjective, and is based on my experiences from the last two years. So please keep this in mind, and be gentle when you share a comment.

The Background

Every organization is different. Ours is a strange one: we inherited Scrum, while the organizations we were working with were still doing waterfall. Scrum has a very different terminology, and since nobody else is doing it, they do not understand us. We had a lot of problems from misinterpretations. Story points are a good example.

For example, we told the project management that we are going to deliver 400 story points. They asked in reply how much that was in man hours? We answered that in Scrum we don’t count man hours, we are working with story points. They insisted on the man hours, and since they pay our bills, we gave in and made an estimation in man hours. Almost the same happened with sprints, because the higher-level organizations had release cycles of six months, while we had sprints of two weeks. This means that we deliver a lot of features in one giant step, and lose all the benefits of continuous delivery, like faster feedback on our product. And the list goes on.

After a while, I had the feeling that we are doing several things unnecessarily, and our management does not understand our output, and they don’t care what we are doing internally. Some of us made conversions between our Scrum measures and the company-required measures, which turned out to be a disaster. No one can make a good conversion in this situation. We started to fail, but not at the beginning, but at the worst place ever: around global delivery dates. Additionally, we spent two years trying to change our environment, and the way how people think in this environment. We failed at it, of course. The environment is huge, one small organization cannot make a difference, unfortunately.

My first thought was that we may be doing Scrum wrong. And the next one was that maybe Scrum is not the agile method that we should choose. There are lots of methodologies out there, we should try them out, and after that we’ll see whether we did Scrum wrong, or it just wasn’t for us. Henrik Kniberg has a very entertaining and thoughtful presentation on this topic. I highly recommend reading it.

So I decided that we are going to try out the Kanban methodology. The principles of Kanban would help us handle frequent changes and the diversified work item backlog. However, Kanban isn’t a software development methodology like Scrum. You cannot do Kanban, you need a process on which you apply the principles of Kanban. I usually hear the expression that “We are working in Kanban“, which is partially true. Actually they are working according to their process following Kanban principles. There is a difference. A very well known and good example is Scrum-ban. It is a Kanban system which is applied on the Scrum methodology.

We needed a process under Kanban, and I chose eXtreme Programming. I needed something without an exact requirement on iterations. XP also talks about iterations, but it is not based on them that strictly. DSDM was a candidate for 5 minutes, but it is also iteration-based. Crystal was also a candidate, but since we already have experience with XP, we know its principles – although we still have to practice –, I chose XP.

Read more »