Comments

7 responses to “The Kanban Story: First Issues”

1. 

   November 4, 2009

   Meade

   My Question(s):
   What has Kanban provided that you think XP, Crystal or any other approach would not have OR would have? I'm not 100% sold Kanban is a fully thought out PM/SDLC approach.
2. 

   November 5, 2009

   Pawel Brodzinski

   Meade,

   I don't know Crystal so I can't say. XP IS NOT a project management methodology. XP tells a lot about software development but almost nothing about project management. Scrum does. However I rejected Scrum for being too strict for our situation.

   We are too small and know each other too well to set up specific practices which enable communication or cooperation. That just happens. If I worked with people I didn't know I would probably choose something more formalized. But in this specific situation all methods I used in the past were too formalized to what I needed (Scrum included).

   There's basically one thing which Kanban provides which isn't so easily achievable with other standard methods. It is huge freedom when it comes to set up priorities on "what's next" while forcing you to finish what you have started. To give you more details – we start development of new feature every 3-4 days. This means I can effectively change priorities almost twice a week and it happened so a couple of times I was throwing away virtually everything from todo short list and putting there completely different tasks.

   This doesn't happen in other methods I know. Even in Scrum you have at least 2-week frozen in iteration before you can start new features.

   Of course you can craft methodology just for you which incorporates this and that's exactly what we have started with. The problem was we weren't forced to finish tasks which we had started.

   Having said all of that I don't really care whether Kanban can be considered as a fully though PM methodology (it definitely isn't SDLC approach) as far as it works for me.

   And thanks for these questions. A food for thought.
3. 

   November 5, 2009

   Meade

   Your comment 'We are too small and know each other too well to set up specific practices which enable communication or cooperation.' – do you think that there is a risk in being to familiar and that the lack of known practices could be an issue when the pressure is turned on and 'stuff' happens? I'm thinking (and seen) where familiarity is good in the good times, but when 'stuff' happens you have no real practice/process to fall back on and help sort things out.
4. 

   November 5, 2009

   Pawel Brodzinski

   Meade,

   First, you can't say we have no real process here. Actually a range of options isn't limited just to named methodologies. We had process even before we have started thinking about Kanban. It was very light-weight too since for this specific team even Scrum is too heavy (this is my personal opinion).

   Another thing is what will happen when problems come. We can discuss what typically teams do when problems happen and it's rarely following the process, but this is subject for separate thread. When we talk about my current team I know how we will act when stuff happens. Actually I've seen these people in action when stuff happened. This is one of main reasons why I chose them.
5. 

   January 3, 2011

   Simonas

   In Scrum you are frozen for sprint length. Despite of that you can always have “abnormal sprint termination”. Or make sprints shorter :) My goal is not to promote scrum here, but add some corrections :)
6. 

   January 3, 2011

   Pawel Brodzinski

   Simonas,

   True, but you tend to have fixed-length iterations since you use the data from them to measure velocity etc.

   Of course you can make sprints shorter – 1-day-long or even shorter. The question is whether it is better to make iterations shorter and shorter or to resign from them at all.

   I think Kanban teams rarely do have iterations is not without a reason. There are just some kinds of work, maintenance being the most common example, which aren’t easily time-boxed.
7. 

   January 4, 2011

   Simonas

   That’s the reason why we don’t use Scrum for maintenance or other tasks which cannot be estimated (with few exceptions).

   We could discuss about cons and pros of iterations, but I guess, its just the matter of applying right process in time. Currently I find it beneficial for my team as it encourage communication and self improvement (retrospective) and , well other Scrum things :) I guess its all about team maturity. I am looking forward my team tries Kanban for full project.