How to avoid micromanagement
My team has been doing Scrum for several months, or at least they think they have. Some of the things we're doing are, according to Jeff Sutherland, anti-Scrum. But I seem to be the only one who's not a fan of the "Scrum" we're practicing.
I've always had a hard time with the planning aspects. For example, we had a story that required us to run some server-side logic when a hyperlink was clicked. I didn't know how to do that, but I had to tell them how many hours it was going to take.
My instinct was to break it down into two tasks: research it (3 hrs), and do it (3 hrs). We're encouraged to shoot for 3 hour tasks, but someone thought 6 hours wasn't enough for this story, so I had to add more tasks to bump up the hours.
So then I broke it down like this: research possible solutions (3 hrs), implement the first solution (3 hrs), test the first solution (3 hrs), implement the second solution [because the first solution might not work] (3 hrs), test the second solution (3 hrs), write unit tests (3 hrs), refactor (3 hrs).
I thought I was going to work on this story, but someone else got to it first. He did it by replacing the links with buttons that were styled to look like links. This didn't take very long, and our estimates were way off. So what was the point of wasting time with useless estimations, instead of just doing it?
Anyway, what really bugs me is that they're ramping up the micromanagement. Senior management -- not my manager, or my director, but top-level execs -- wants to see a TFS report showing how many tasks each person has done. Hours are not shown, only the number of tasks by person.
I didn't have many tasks in the system because I focus on doing what needs to be done, and I only deal with TFS when people complain. But since we're going to be judged by the number of tasks we do, I've been dumping a bunch of tasks into the system (associated with an irrelevant story, because we don't have a relevant one). I'm getting less done but getting much more credit for my work, so this kind of gaming the system seemed tolerable.
Now they're complaining that I'm only entering tasks after they're done. I said that until I've done something, I don't know exactly what I'm going to do. They said what I'm going to do should have been determined at the sprint planning meeting. I said these were new things that came up (we're picking up new technologies as we go). They said that I should still put them in "to do" before I do them, give them an hourly estimate, and subtract those hours from a placeholder task because the total number of hours for the sprint can't change.
That people are rewarded for counting beans instead of doing their actual job is driving me crazy. I'm thinking about resigning from a job that was fantastic before we started implementing "Scrum." My question is whether there's any way to convince them that micromanagement is a bad idea, and to make them realize the costs of killing their employees' motivation.
I told my manager and director that asking developers to fill out time sheets reduces team productivity by 10-50% (http://www.scruminc.com/time-tracking-is-anti-scrum-what-do-you/), but they didn't believe it and said it's not a big deal. Why then don't they enter their hours and let me micromanage them, I wonder?
The SM also has a duty to the organization
The Scrum Master serves the organization in several ways, including:
*Leading and coaching the organization in its Scrum adoption;
* Planning Scrum implementations within the organization;
* Helping employees and stakeholders understand and enact Scrum and empirical product development;
By virtue that the Organization is behaving like this means that that service isn't effective enough.
They don't understand what it is that you are trying to implement.
Oddly i don't hear any mention of the PO, they should be adding value.
"For the Product Owner to succeed, the entire organization must respect his or her decisions"
If you are the SM then you need to educate on self organizing teams and what scrum is.
PO should also be providing input after all they are the value optimizer from the scrum team.
They should easily be able to show value in what it is your doing, if they are a good PO.
Results often speak for themselves.
For this to work as it is "undiluted" means that education is key, even at exec level.
If you don't get buy in, this will not work, every sprint it will be eroded towards failure.
Michael
I don't really have any words of wisdom here, as I'm also new to Scrum, and sufferring from similar issues. I just wanted to compliment you on a well-written exposé of your problem.
What do the Scrum Master and the Product Owner have to say about this unwarranted interference in their team's ability to deliver increments?
Posted By Ian Mitchell on 16 Aug 2014 09:19 AM
What do the Scrum Master and the Product Owner have to say about this unwarranted interference in their team's ability to deliver increments?
When I said something about it in our retrospective, the SM actually agreed with me somewhat. He said the process was cumbersome, and that some might see it as micromanagement. But he has superiors who want things done a certain way, so he backed down pretty quickly.
The PO is not a developer and therefore not a victim of the process, so I'm not sure if she really believes that it's interfering with our ability to deliver increments. However, she wouldn't care anyway. She's a helpless pawn, just saying that we have to do it this way because it's what senior management wants.
OK, so as you have surmised, the situation you describe does not reflect the correct application of Scrum. If you are looking for an affirmation of that then I for one am happy to provide it.
As for a way forward, it is possible to achieve tactical improvements *if* the Scrum Team, including the Scrum Master and Product Owner, take it upon themselves to manage their own process and the delivery of value, and to resist unwarranted interference. That does take a joint commitment on the part of all members.
A strategic improvement will only be possible once management accept that there is a significant organizational deficit in agile capability, and determine to improve the situation incrementally and empirically.