My current team works with Kanban for some time already. For all of us this is a kind of experiment on live organism. Ongoing experiment. That’s what led me to an idea of The Kanban Story – a set of posts which are a logbook of our cruise with Kanban.
The story has its beginning and several chapters since some things already happened since we started our friendship with Kanban. There’s no end however. I don’t know what we’re going to end up with but I’m going to share with you all ups and downs which we encounter along the road.
Hopefully this will become a kind of manual which helps with other Kanban implementations and generally with your work on projects and teams.
Technically it would work as pretty much every series on this blog – I will publish new chapter of The Kanban Story every week or so and you’d be able to find links all of them which are already published below since this post will be updated every time new post in series appears on Software Project Management.
- The Beginning
- Initial Methodology
- First Issues
- Discovery of Kanban
- Implementation of Kanban
- Kanban Board
- What We Do And What We Don’t Do
- Kanban Board Evolution
- Kanban Alone Is Not Enough
- I Don’t Know, Experiment
- Throwing Sticky Notes Out
- Pseudo Iterations
- Kanban Board Revisited
- Kanban Boosters
- Measuring Lead Time
- Coarse-Grained Estimation
- Swarming
- When and Why We Abuse Limits
- Small Tricks Do the Job
Subscribe RSS feed
Follow on Twitter
Subscribe by email
{ 10 comments… read them below or add one }
Can't wait to read your story–I was just reading about Kanban yesterday and thinking about how to implement it with my team!
Here is our development process based on Kanban
http://www.targetprocess.com/blog/2009/10/our-development-process.html
Michael,
Nice list. I think we're heading a bit different direction, although our situation is different too: we have smaller team and less mature product to work on.
One more difference about The Kanban Story – I want to share more a journey than show just a picture how it works at the moment. I believe it is important to show people why you've chosen to do one thing and rejected to do another and how your views have changed over the time.
Yeah, I agree that reasons behind the decisions are important. It is very good to show various trade-offs and final results.
Really nice article. Thanks Pawel.
I’m thinking of implementing Kanban in new project, but still don’t know which online tool to use. One which looks easy to use and lets concentrate on work is kanban tool (http://kanbantool.com). I need to give it a test run to see how it works for me.
Maybe you can write more about online kanban tools – some comparison?
David,
Comparison of different web tools supporting Kanban is a very good idea but I guess nothing would trump good old hardware whiteboard if you ask me.
If I could give only one advice to any Kanban team it would be: gather in one room and put big whiteboard in a place where everyone sees it.
Hi Pawel,
Maybe you are right, but in my case I can’t work with traditional whiteboard because I’m working in distributed team.
Yes, this makes using standard whiteboard way harder. I’ll try to add some tools focused on Kanban to my to-review list.
Hi. I just found your blog today and it’s fascinating. I’ve been looking for a “more agile than Agile” approach to managing our projects, and this may be it.
How do you handle dependencies among MMFs in your backlog? Or the face that some MMFs just naturally go together? Do you just group them together in space on the board?
thanks
Linda,
In our case this is pretty simple. Since the product is led/managed by a single person (me) it is his (my) responsibility to deal with all dependencies between features/tasks.
Technically I just keep relations between tasks in my head and push prerequisites earlier into the stream.
Actually Kanban does not allow you to skip the proper work breakdown structure. If your tasks/features are planned poorly you won’t get decent results this (or any other) way.