I have often found that when teams resist tracking it is because they don't feel involved in it. Using task boards to track the sprint often turns this around. The physical nature of this tool makes a huge difference. Team members have to go up to the board, take a card off, either write their name on it, or talk about their progress, and move it to a new physical location. The burndown chart becomes almost superfluous when task boards are used. The task board itself is the burndown. Actually a better term would be a "Blaze Across Chart". Cards should be flying from one end of the board to the other. For co-located teams, a daily snapshot of the board can be uploaded to the wiki.
I have seen teamwork improve on the introduction of taskboards. It is too easy to hide or check-out when a Scrum Master is fiddling around updating hours on
an excel spreadsheet on his/her laptop
Taskboards can be created on any spare wall surface with masking tape (or electricians tape) and postit notes or cards. The more public the location, the better. Using ribbon as horizontal separators between each backlog item is helpful too, as this can be moved in each sprint to accomodate the different sized items.
Maybe you are already using this method, but perhaps others are not at this point, so I thought it was worth a plug.
Tobias
mpkirby@... wrote:
... THe daily tracking thing has become an issue, in particular. I believe it is a sign of the lack of team comittment. WHen the team is comitted to delivery, then daily tracking
becomes important, because the effort spent (or estimates remaining, rather) and burndown are the means by which individuals on the team monitor and maintain that comittment.
But when each individual is "on his/ own", then what's the point of tracking? You know where you are. No one is going to do anything with the data anyway.
... One thing that wasn't immediately obvious to me until it was pointed out by Bob Martin was that use cases are typically not a direct substitute for...
Mike, I have often found that when teams resist tracking it is because they don't feel involved in it. Using task boards to track the sprint often turns this...
... That might be true to some amount. On the other hand I think it really comes down to team culture and what you are personally used to. When I joined my...
It seems to me that the participants of this thread have taken one side - "all or nothing" w/r/t pair-programming. It's either a silver bullet and should be...
... Greetings Stephen, If you're "observing" long enough to get bored, you're probably not playing the role well enough, and you're probably not switching...
I can definitely confirm this. We don't use pair programming in our team, but out of their own desire the team members form couples for some of the time (and...
Although at some organizations the quality of code being produced by paired programming is so high that they have set a policy that all production code must be...
Alas, I would feel compelled to review every line checked into StarTeam, regardless of how many cooks were in the kitchen. So, for me, code review is not...
... I wonder how much you'd stil feel compelled to review every line that is produced by pairs after you have done that for some months. My *guess* is that it...
... Yikes, you must have a very small shop. I personally, can't keep up anymore with the 20+ developers that I used to want to "review every line checked into ...
How many people am I supposed to have? :) I prefer to have a small team, about the size in Ken's book. Seems like we get a lot done when we're in the zone....
It seems to me that the participants of this thread have taken one side - "all or nothing" w/r/t pair-programming. It's either a silver bullet and should be...
... Would you share the detailed empirical figures on this with us, please? Did you track defect injection and subsequent fix time as part of your study? ... ...
... I wasn't aware there was an "observer" role. If you mean the person not at the keyboard, then any boredom they experience must come from an inability to...
... wrong. I understand that role completely. ... when I observe, my brain works way faster than the other person can type. I can make all kinds of "zoomed...
FWIW, there is also the issue of exploratory coding vs the rote data entry of a well-known pattern. Having people watch pattern entry is only useful for the...
See http://c2.com/cgi/wiki?PilotCoPilot For a good description of what you are talking about (not that what you are talking about isn't a good description :-) ...
I was going to post a lengthy description og PP, but the below article does a better job. If you think PP is just "shoulder-surfing" you quite simply haven't...
... There are times when coding doesn't benefit at all from pairing. In fact, pairing would be a waste of time, and less efficient. Examples: 1) You rename a...
... OK. An interesting technique in professional discourse. But I write for the people who may read and consider what I write, in the everlasting hope that...
... I find it unfortunate that some frameworks lead us into cookie cutter design. A lot of this kind of design suggests there might be a better way. There must...
... Yes. I would be inclined to find a way to make a reusable cookie rather than stamp out mindless code. I think that is generally possible. ... Hopefully ......
... Ron, my experience is that it's the /right/ eyes that matter when diagnosing difficult bugs. By right "eyes", I mean someone who's brain has sufficient...
... Certainly having the right eyes helps, as does, often, having /fresh/ eyes. I'm not sure what the increase is from one to two, but one simple model would...
... It's complicated. Less communication overhead would be one reason. Not only the quantity of communication, but the efficacy were factors. It required much...
... Greetings Steve, My experiences with a team working together in a room have invariably been good and gratifying. I did this a few times several years prior...
... Hi Jeff, I've had similar experiences. ... I wouldn't compare the two in that way. For situations where a /formal/ code review is really necessary, I don't...