Pretend you have a really great programming day. You only have to attend a few meetings, have only a few off-topic conversations, don't get distracted or interrupted much, don't have to do a bunch of status or time reporting, and you put in a good six hours of serious programming [note: this RARELY happens in an 8-10 hour day]. I want to review your work in the morning, so I print out a diff of your day's work before going home. Sadly, overnight the version control system crashes and they have to recover from the previous day's backup. You have lost an entire day's work. If I give you the diff, how long will it take you to type the changes back into the code base and recover your six-hours' work? Programming is 11/12ths Thinking I've been touting this figure for some time now, and people keep asking me where the study is that produced such an odd number. Well, it's not pulled out of thin air and it's not the result of a thoro...
My previous programming job (before my ill-advised but well intended stint as an Agile Coach) I had a guy on the team who simply would not unbind points from days. Every planning session he would press the issue. It drove me batty.
ReplyDelete(Well... it drove me off the team is what it eventually did.)
The problem usually exists when that question is asked before we actually know we do 16 of them during a week.
ReplyDeleteBut still we say "We used to do 16 points a week, so we will try to find out if we can repeat that this time..." and hope they get enlightened just then :-)
@MadWilliamFlint: what did he do when the points became 1/12th of the iteration, 1/18th, 1/20th, or 1/9th?
ReplyDeleteI think there are bad assumptions there, and I know you saw that. A three-point task for me might be a one-point task for you, yet together we somehow reliably produce 7 points a week. The averaging of teamwork is hardly magic, but I have seen people want to quantify tim/hours and joe/hours and catherine/hours for tasks. It's sad and wrong, but there it is.
Leaving a dysfunctional team is a choice. Having a team member "refactored away" is another. I certainly understand.
And now I know why you're batty. ;-)
@MarcinNiebudek the first iteration is indeed special. I would pick a task that was relatively simple and call it "2" or "3" and then we would estimate relative to that.
ReplyDeleteThen I'd have the team pick the largest story that they truly believed would be done before the week ended I'd take the story's points, and then build alternative plans for them. 8 points? Then 2 three-pointers and a two pointer? A five, two, and one? Eight singles?
If one of those formulations was likely not to finish, then we would drop the number down. If it seemed to the programmers that it was too light of a load, we could bump it up by a point. Quickly, we would decide how many points to offer. We wouldn't let managers speak at this time, because they would want to "encourage us" and set "stretch goals", both being counterproductive.
After that, we would still always come in short on the first iteration. After all, 80% of programmers think they are above average and tasks are usually harder than they seem.
After several tries, I decided that first-iteration calibration was a lot of work for nothing. Instead, I think it's best to pick the most important, small, concrete thing you can do and see if you can finish that with your team in a week. If so, take another. Kanban it for a while. After the first iteration you can use "Yesterday's Weather."
If you set a sprint goal for the first iteration, I suppose the important thing is that the Customer knows you are just guessing. If the Customer thinks it's a promise, disappointment will result.
He never would. His smartass retort was that this meant his minimum task size was 1 day.
ReplyDeleteHe insisted that Agile was essentially a training task for people who didn't know how to write software and he was all set.
Talking with other developers it always came down to "yes, you're right. But he's this way, so that's that."
(I was like this before, but it sure propelled me along a pre-determined vector.)
When arguing, it's useless to argue on your own terms. You have to argue on the other guy's terms if you want any hope of changing his mind. Otherwise you're just talking to make yourself feel assertive. He and I were at what seemed to me to be a perfect impasse, so I quit.
He's still there and happily flipping off management. I'm "right and unemployed."