During my talk at AgileCE I mentioned three things as biggest Kanban boosters in our case:
One of comments I heard about this part was: “Pawel, these things aren’t Kanban-related – they would work in any environment.”
Well, I’ve never said they’re exclusive for Kanban. My point is: Kanban is pretty simple approach – it really tells you to do just a few simple things leaving most of other aspects open. This means you may (and should) use some help from other techniques/practices which set additional constraints or organize other areas of your process. And boosters I mentioned work exactly this way.
Co-location allows you to keep your Kanban process as simple as possible. You don’t need to use any software to visualize current state of the project – old-school, hardware whiteboard is enough. It also helps to exchange information between team members which is always important but with minimal formal information exchange in place it plays even more crucial role.
No-meeting culture brings us “do it now” attitude and saves a lot of time usually wasted on meetings. And we discuss different things more often than we would otherwise because launching a discussion is totally easy: you just start talking.
Best engineering practices help us to keep the code quality under control. That’s a thing which is basically omitted by Kanban itself so you need other tools to deal with it.
Now, you can perfectly take your Scrum (or whatever kind of) team and use the same techniques and it would most likely work. Oh, it would as long as your team isn’t too big (co-location and no-meeting culture don’t scale up very well) and you don’t have a list of engineering practices enforced by your approach anyway (like in XP).
So no, these concepts aren’t exclusive to Kanban. They just work in specific environments. Yours either fit or not. It doesn’t really matter if your process name starts with S or K or X or P or whichever letter sponsors your day.
After all when I think about Kanban I don’t isolate the method from the rest of our environment – that would be stupid. If Kanban works for us it is because the whole setup is good enough, not just its Kanban part. And these boosters are a part of the story.
Read the whole Kanban Story.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
4 comments… add one
I liked the idea of “no-meeting culture” and attitude towards resolving problems on the spot. In most cases, people which are driven by emotions (damn, yet another build failure) tend to indicate more determination to act. That’s fine and was adopted easily in my team. But what about meetings which are part of ‘agile culture’ such as scrum demo. In my case, I suppose some of my demo participants are hardly interested in the content, it’s rather treated as a nice variety in their job.
In the first place I’d ask you what kind of value you (as a team) get having these hardly interested folks on a demo meeting? But that’s a digress.
We don’t have problems with product demo since we don’t have product demos. On the other hand we sometimes do demonstrate how the application works and we do it like every other “meeting” – ad-hoc way. We just gather around one’s screen and just go through the thing which we’re going to discuss.
I consider all sorts of meetings which are part of Scrum, to take the most popular example, as artifacts which help to maintain a rhythm of work and build a work culture. Teams introduce stand-ups to have short feedback loop (of course I don’t think about teams doing this just because Scrum manual says so); formal retrospectives enforce discussion about improvement; product demo helps to gather information from a customer etc.
Now, if the team is able to achieve the goals in less formal and less structured way you can perfectly live without these artifacts. I don’t feel an urge to have stand-up – a glimpse at the Kanban board sometimes followed up with a couple of questions do the job. I don’t need a meeting for retro since we try to fix our problems using do-it-now routine. And we can live without product demos since we don’t sell products but services and our interface for our clients is just a bunch of web services. What we need instead is to teach guys meeting customers (which basically means to teach me) which services we already have, which we don’t have and what we need to have them.
I don’t need even to spend my time going thorough administration command-line interfaces of our product. It’s enough that I know scenarios we support and I trust the team when they tell me something just works well.
I always had plenty of doubts about the co-location practice, as the result often is increased noise, which simply disturbs people tracking to crack a difficult programming problem. I know the benefits though, so nowadays I simply oppose putting programmers anywhere next to “business side” people – salesmen, customer support etc. – as they’re often on the phone, talking, shouting or doing teleconferences on loud speaker.
I love the no-meeting culture though and live by it. As few organized meetings as possible, with plenty of impromptu discussions, then trial & error. And whatever meetings we have, we do most of them standing – no comfy chairs, no laying back, plenty of movement.
Yes, sitting shoulder to shoulder with a salesman or project manager can be painful. That’s why we tend to go out from the room to make a call or answer the phone. These interruptions we don’t need.
On the other hand I don’t deny there are many interruption we could have avoided if everyone had their own office. We would probably be able to tackle difficult programming problems more effectively. But we would suck at communication which wouldn’t serve as a good opinion about me as a leader (yes, my reasons are selfish too).
And one more thing – we don’t solve difficult programming challenges so often. Most of the time it’s just building some, pretty standard, code. I see more value in having product owner and/or a tester at hand than having environment more suitable to get the flow.