A quality team is necessary but not sufficient. Practices like waterfall development can hobble them. Or worse, the people who could become a "quality team" don't, and don't even know what they are missing out on.
How about creating a system that works with normal people, rather than robots? My feeling is that if it is so difficult to implement the system that almost nobody gets it right, it might be the mistake of the system. It should come more naturally, not forced.
We have been using Kanban for about a month now. It is very successful. Scrum focuses on people. Kanban focuses on the tasks.
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.
I should probably point out that I'm also a code monkey on an active startup and have written several programs over the years, some of which are in production serving millions of folks. So I use the stuff too. (The reason for the disclaimer is that saying I teach it should probably set off your alarm bells!)
Do you consult companies in implementing these practices? What was the largest team using Scrum that you felt was still effective? At my job, there's 30 people at the daily stand-up and it just seems out of control, especially as we pass a speaking stick across the group. What is this, Lord of the Flies?
Yes. I'm a startup junkie and coder who ended up consulting companies in implementing these practices because once your development group starts growing, performance usually tanks. Big companies are looking at the stats and seeing that in some cases they are spending 10 times the cost and taking 4 times as long to develop similar software to what a small company can put out. So there's a big pain out there.
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.
Well, I was being figurative there, we actually do use a nerfball but I'm pretty sure it's universally despised. What usually happens is someone is done speaking, holds the ball up and looks around for a taker. No one ever really says, "Me next!" so it's thrown to a random person. At least one or two people will drop it per stand-up and someone else will always go, "Nice one, butterfingers!" and there's the awkward, uncomfortable laugh.
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!
Got a better one for you. Start doing the math on how much money you waste thinking you're smart and understand everything and then blow it later on because you missed a key conversation. I'll stack that up against nerf-ball-tossing any day of the week. Or how about useless status reports? (stand-ups are not status reports). Or meetings with required attendance that accomplish nothing?
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.
What was the largest team using Scrum that you felt was still effective? At my job, there's 30 people at the daily stand-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.
Wow. The word "kanban" in the title caught my attention so I thought I'd take a look. I currently work (for another week anyway) on the finance team for an aerospace manufacturing firm so we are very familiar with kanban and other lean principles. Little did I know lean principles (even Kanban?) are working their way into the software development world!
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...
Management at my gig decided to just use both, a ScrumBan if you will. I think the general manager just wanted a board to stop and look at every time he had to go to the bathroom.
14 comments
[ 6.4 ms ] story [ 47.2 ms ] threadThere is no substitute for a quality team. No amount of structure can make up for idiots.
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.
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...