When a developer leaves aside his task for a while (maybe a whole day or even two) to help another developer with analysis or coding of a task of that other developer… how should they specify the ‘actual effort’ of the story/task? Should they sum up the hours for both developers and charge the hours of the two and not of one developer since actually the two of them were working together?

If the fact that developer A helped developer B with a task leaving his tasks aside for a while, with the risk of the tasks developer A committed to for the sprint being jeopardized, is maybe an issue to rise during the retrospective meeting and clarified there.

But my question is more from a project management perspective: assign the hours they worked together, times 2 (because the two of them were working)? Just charge the hours of the developer that owns the task? Is it irrelevant?

It *is* micromanagement of the worst kind; it’s attendance keeping for 4 year olds that can’t use email to update their team with status.

It’s a false sense of security that information is being transferred just based on answering 3 inane questions.

And it’s micromanagement of the worst kind, when not only are you being micromanaged by 1 manager, you are micromanaged by a whole “team” of micromanagers, most of whom are amateurs, most couldn’t manage a donut shop, and any one or more could have an axe to grind.

Great methodology for the id10t crowd.

Software Maestro

If the company flourishes, I will probably keep my job. I may even get a raise.
If the company fails I will most definitely lose my job.
Stop feeding people horned herbivore dung like that the interests of the company and those of the workers were identical.

I’d like to allegorise your post and (part of) the reactions to it:

A shepherd dog steers the herd exactly the shepherd wishes it. Therefore, you say with a wink and a nudge, the shepherd is actually micromanaging the dog. But… ssh!
“Nay!” others retort; for the shepherd is never seen to actually give any order to the dog. Clearly, the dog is “micromanaging itself”.

And they are right. The shepherd dog isn’t micromanaged. It barks and bites out of its own volition. It has _internalised_ the shepherd’s interests.

And this is what those methodologies are all about: intensifying the process by which workers identify with the company’s interests, so as to be more easily milked. I very strongly suspect that most gains in productivity reported from the use of agile methods stem from this.

Agile/flexible: adj. Possessing a state of mind or a stance of the body that allows for deeper anal penetration.

The shepherd dog gets the occasional bone to gnaw on. Don’t expect much more once the hype has died down and the standards have uniformally reached a new low. The occasional bone is better than what’s in for the sheep, you might say. Still, rather than agile, I’d rather be wild.

My first Agile project, flawed in many more ways than this, my second, had 6 scrum teams consisting of about 5 developers, a tester, a scrum master (unfortunately no product owner made it to scrums) and that was it. I didn’t not mind reporting my status at all to basically just my peers.

But then…

I move on to my second Agile project and in the daily scrums it started out with all the *management* chain i mentioned above plus the 2 developers and 1 tester and a couple floaters and a product owner proxy. It did narrow down, after some complaints by my and other scrum teams, to now have the core team plus the contractor deputy PM and the gov’t deputy PM in every scrum along with the release notes writer who is also the branch chiefs best friend, literally.

I stated in our last retrospective that it seems like micromanagement. The two deputy PMs never seem to solve any problems we bring up. When they do speak I don’t ever feel it is the right time (like to help solve a problem.) I was told that everyone is invited to the scrums and, of course, there are the chickens and the pigs. That the status is for the team not for management. I said fine, I don’t mind telling my fellow developers and the testers that it took me an extra 16 hours to complete a task than estimated because i was working in an area of code where my fellow developer knows is frankly crap but who knows what my deputy PMs are writing in their little notebooks and what the chief’s friend is writing as well.

My feeling is that the PMs (the two deputy and two full) can at anytime look at our burn down chart that is updated daily and the scrum board. I personally, after this experience don’t believe that scrums are productive when they are so open to attendance.

I have never worked on a project in 17 years where i report to one much less multiple PMs daily. Actually, to further my point, there is one or more PMs in every TEM (which we do too much but that is another story all together.) So, I should not take this as micromanagement?

We do a webcast on testing called “This week in testing” and this week, we talk about this post of yours (I really like the perspective of daily scrum as micro-management).

You’re welcome to watch and comment (http://learn.typemock.com/this-week-in-test/2009/11/18/episode-4-animals-that-talk-back.html) and if you like what you see, please tell the whole world.

Thanks,

Gil Zilberfeld
Typemock