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.
(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.
But 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?
I 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.
@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.
Then 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.
He 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."
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."