Some Day Kanban Will Fail 75% of the Time
noop.nl
noop.nl
It is safe to say that everyone on the project from testers to developers to higher management that is not actively involved has a good sense of the entire state of the project.
Scrum is too micro-management - daily updates - what I did today, what I'm doing tomorrow - you'll laugh but one of my co-workers - he told his wife, a teacher, about scrum and the burn downs. And she laughed and brought over a sample of the 'What I'll do today/What I did yesterday' template that her school uses with 3rd graders to track their progress.
Kanban is not a silver bullet. It really helps to have a large physical board - a virtual board - be it a shared Excel spreadsheet that is version controlled - is not very graspable - even if it is the defacto authoritative source.
Kanban works because people here want it to work. Because they're tired of scrum. Of being micro-managed. Of having to sit through endless scrum burndown calls where everyone has to talk about what they did. Especially when the team is overseas and they are dialing in late. Kanban cuts that down to what is needed to be known. If you need to have longer discussions, you break off from the main talk. Kanban calls are JIT updates, not updates just for updates.
I don't make a big distinction in scrum, Kanban, Agile, agile, Crystal, etc.
If the burndowns were buggin' you, stop the burndowns. If the daily standups seemed pedantic, stop them (or better yet, fix them). If your team is too large, Kanban might give you a better sense of control but development's big obstacle is communication, not control.
I think Kanban boards are great. If it tickles your fancy, go for it.
But it's no more a silver bullet than scrum was. At the end of the day, teams that regularly adapt beat teams that jump from one big thing to another, apply it rigidly, then wait too long to jump to the next big thing. The idea is continuously tweaking what you're doing, not latching on to a marketing term.
Hope that didn't tick you off :)
Disclaimer: We use this stuff. We are taught this stuff.
Avoid large teams! The daily stand-up should be 5, maybe 10 minutes, and should move along very quickly. A 30-person team, especially if the PM is playing scrum master and doing Q&A during the stand-ups, can be the worst kind of death march.
I've watched/participated in about 60 teams, and consulted with other coaches on probably 300 or so. Yes, there are 30-person teams that do well, but it's very rare, and usually there are other things that made them do well.
Organizations consistently over-staff teams, especially those in trouble. It's depressing to watch, because it just makes matters a thousand times worse for everybody involved.
Here's a corny tip that I found actually makes standups a little more bearable: Forget the speaking stick. Use a nerf ball, and forbid hand-offs. Everybody stands and nobody knows who's getting the ball next until the guy throws it. Also you have about 30 seconds to do your standup and then you're done, one way or the other. Standups should always add energy to the team and help with the day's agenda. If it's "Lord of the Flies" you guys are really out-of-whack somewhere.
I observed this practice for a couple weeks and came to an average of 2.8 seconds per ball movement. Times that by 29 (amount of passes) and you get 81.2 seconds per day we spend tossing that ball around. At an average salary of about $65K amongst the group, the company spends $42.29 per day on passing a ball around; that's just under a $11,000 a year!
But I digress...
Communication kills teams. That's why the 30-person team sucks -- communication difficulties expand at an exponential rate. Stand-ups, pair-programming, co-location,and all the rest of that are just feeble attempts to address this problem. If you don't like one of these things, stop it. But that doesn't make the underlying problem go away. Whatever you do, you have to constantly be figuring out ways to solve this problem, not just thinking you've got it nailed because you're doing X.
Agile is very simple. But if you try hard enough, and most teams do, you can screw it up.
Largest feasible scrum team size is around 12 people. Daily stand-up should take less than 15 minutes. If you can't consistently get it down to that, split into 2 or three smaller scrum teams. Do all 30 people work on exactly the same deliverables? I doubt it, so there should be a natural seam along which to split.
There is no substitute for a quality team. No amount of structure can make up for idiots.
This is all the more interesting since I've just taken a position as the financial operations manager for a web/finance startup in Atlanta. Good to know that some of the cool lean principles and tools can translate into my new environment! Definitely something to look into...