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
- Moving Cards Back
- Retrospectives
- Standard-Sized Features
- Skipping Part of Process
- Kanban Board Should Reflect the Reality
Subscribe RSS feed
Follow on Twitter
Subscribe by email
15 comments… 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.
Hi Pawel,
Thank you for this Kanban story.
It’s interesting about making tools working for you, in your environment, and not getting stuck with prerequisites/rules.
On Agileee’10 there was a lot of discussions about Sergey Andrzejevski speach “Management of offshore agile projects”, and his practice seems to be similar, in terms of altering tools to make them working in your environment.
I’ve noticed, that on the start of story there was only one project on your Kanban board, however then few new projects appear and you divided them by different sticky notes colors. I’m trying to imagine this in case of smaller teams (different technologies) working on different projects, but one product owner and one system/administrator QA. Do you imagine it as one board for each small team (2-3 developers on same technology), or as one board for all teams?
Thanks,
valerii
Valerii,
As a rule of thumb I’d go with one board whenever it is possible and does make sense. Splitting the work of a single team among a couple (or more) boards requires significant effort to synchronize all those boards. It’s much easier to reflect specifics of work being done on a single board.
If we discuss different projects you can go with different sticky notes colors. If we discuss projects which are separated technology-wise you can use swim-lanes (example can be found in Kanban Basics presentation).
But then if we discuss completely separated teams (with exceptions of product owner and sys admin) it likely falls into “single board doesn’t make sense anymore” category.
As long as production teams have no interchanging work I’d probably opt for separate board. I don’t consider shared product owner as a big issue, as long as they have enough time to support all teams. The bigger problem is probably shared sys admin. However it may be a wise trade-off to allow sys admin synchronize their task between a couple of boards than to put everything on a single board.
Everything depends on the context. Think which thing is more painful for you. Making all projects (and teams) affecting work of each other or adding one person some synchronization and prioritization work. If teams interact on a daily basis anyway you probably want to go with a single board, but if they don’t you may prefer multiple boards.
Pawel,
I think it’s reasonable to start with swim-lanes, to divide teams that don’t cooperate at all, but have shared product owner and shared sys admin, and then to experiment with multiple boards.
Thanks for reply,
Valerii
Hi, this is great! A superb series and I learned a lot from it, thx a million.
I have a question thow what you, or others think about the following.
You said in one of the chapters that you really understood Kanban when reading the Kanban vs Scrum (http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf) and I agree, it is a good document.
But what do you think about the comparision of RUP, XP, Scrum and Kanban they make in that document? Don’t you think they are wrong to compare all of those?
Wouldn’t it be better to compare Scrum to RUP, that I can fully understand, but leave out XP and Kanban?
I see XP and Kanban much more as ‘ways of working’ then the framework RUP and Scrum try to provide.
Or am I completely wrong?
Of course, the next title in the document is: Don’t limit yourself to one tool… but I wonder what your opinion on this is.
@Kenneth, I don’t really have problems with this comparison. I mean I don’t even treat is as a real comparison. The point there is about number of rules. Few in Kanban, a few more in Scrum/XP and insanely many in RUP. Point taken. I move on.
To some point you’re right. It is really hard to compare XP with RUP. It’s a bit easier in XP versus Scrum as a couple of concepts are similar, e.g. timeboxing, but they still mostly deal with different areas.
I don’t agree however with one point: Kanban is the least of “way of working” out of every mentioned methods. In fact Kanban doesn’t tell you how you should work at all. You can perfectly apply Kanban to pretty much any process, even the most chaotic one and it should work. To some point at least.
So the way I understand it is Kanban isn’t “the way of doing things.” It is more a set general practices which somehow make teams improve. As David Anderson points in the foreword:
“Many of results of Kanban are counterintuitive. What appears to be very mechanical approach – limit WIP and pull work – actually has profound effects on people and how they interact with one another.”