Home > Agile, planning > First impression of going Kanban

First impression of going Kanban

I can admit that going scrum for me can be described as the following process:

  1. Well, this is not hard
  2. Why don’t anyone care about this but me? Why do I even bother?
  3. Oh, crap. I’ll just go on and try to make it work.
  4. Ok, it doesn’t work cowboy style. Let’s go hard core.
  5. Great…. Flow… Finally it works.

This took me about a year. A hard bought year, both for me and the project. But when we finally went Scrum all the way, it actually worked like clockworks. Great. I loved it. Then everyone started talking about Kanban. Oh no, a new buzz word. But scrum worked so well? I started collecting links on delicious but never took the time to actually read them. Why should I. Scrum works, doesn’t it?

Yes, it does. Sometimes. But sometimes chaos is overwhelming. And either you fight the currents or you just go with the flow.

Scenario: one project with one team. A rather long list of requirements of which we know we cannot do all. And there is a bug risk that the resources can be grabbed by other projects.

Can you do scrum during these conditions? Well, perhaps you can, but why. This is perhaps a project manager’s worst nightmare. But still, I sleep tight at night.

So, what did I do? First, I explained the situation to the stakeholders. We are low priority. We will lose developers on the way, so we don’t know what we’ll get. Then I asked what they wanted most. And the answer was two features. These brings most value to the customers. And then I took those features and divided them into smaller chunks so I knew which parts of the features were the most important. You could use story writing seminars and the user story form for this, but I didn’t think this would bring more value to the actual description. But that is beside the point. The point is that I didn’t build a product backlog. Instead I just created a pile of requirements and could bring out the most important thing in the pile.

That story went up on the board first. I told the guys: we all work on this. So, they divided the task between them and started working. Within half a day, half of the crew were off on incident hunting in another project but the rest could move on. So, they kept on that item until it was completed. When that was completely done, we put up the next thing on the board. Half way through that task, the guys were stuck. They needed the guys stuck on other projects. So, we put that task on hold and moved on to a new task.

So, what have we gained? By not pushing a deadline or an estimate, a developer cannot hide incomplete work by “well, I did not have the time due to delivery”. We deliver when we’re done. Not a second before. So, I think we’ll get better quality. Also, we’re not stuck with many unfinished tasks but just the bare minimum. Incomplete work is waste. You cannot avoid it all the time, but here you focus on this. We’re not crippled by losses of resources. It effects how many tasks we can do and if they have different competences: which tasks. But we don’t miss the delivery. We also give the stakeholders to change priorities often. So what if they come running with new stuff: this only means that we change the queue. Since the guys are just working on one thing, we can change the very next task if they want to.

So, what do you miss out on? Well, fixed deliveries are great if you want to plan acceptance testing. But to what use is acceptance testing if what you test is crap? You also have the risk that the guys never stop working on one item, polishing it too much. But here it’s important to be present and describe what you want and what you don’t want. And this is no different than scrum.

So, what was the process for going kanban (up til now)?

  1. Why should I care?
  2. But this is just like scrum, so why bother?
  3. Now I get the difference. But where is my control???
  4. Blizz. I would have gone mad on this project if I hadn’t gone Kanban.

I’ll get back to you on further progress!

Categories: Agile, planning Tags: ,
  1. b4fstat
    2009/06/09 at 4:05 pm

    I’m curious: ” Instead I just created a pile of requirements and could bring out the most important thing in the pile.”

    How did you achive this? What’s most important is often depending on lots of people in a company, several VPs and directors will have their own opinion on what’s most important. And even if you try, they often have projects which are big but cannot be cut down (integration with 3rd party services comes to mind) – either they work or they don’t.

    I’m interested in all insights on who to manage more work than is possible to do, like in most startups.


    • Anna Forss
      2009/06/09 at 4:47 pm

      I was fortunate in this project that my manager brought me a semi prioritized list of items which he wanted to be included in the project. You could say that they are a number of change requests. To make the initial prioritization, I used the methodology of specifying a Commander’s intent. This enabled me to find out what was the first focus for the project. Then it was a lot of foot work to discuss with different stakeholders if they agreed. I was lucky in this case that everyone could agree upon the first objectives. I’ve previously used planning poker with business value but I would have a hard time gathering all stakeholders so I use informal meetings instead.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: