Micromanagement in Scrum. Day to day control

I have just recently started a contract as a developer in a scrum environment. I have gone from previously working towards a big picture to now having my activities managed on a daily basis with no long term goals.

This environment is very frustrating to me. I cant see me lasting until the end of the contract...

I think I know where "Anonymous" is coming from. A lot of Agile adoptions look like this:

There is a group of people who have input into the business requirements. This is a collection of client representatives, user interface specialists, business/system analysts, a bean counter, and maybe an executive or executive's proxy. They filter down through one person, and may even have good chicken/pig distinctions. But, they all need to be in any discussion in priority setting, requirements mining, etc., etc.

In addition to that business team, you've got a team of somewhere between four and twelve developers, and usually a few sundry support staff (QA, infrastructure, etc.).

Meetings with a group of people of this size are totally unbearable, and building up/managing a story backlog takes a LOT of time, so a core of a couple developers and a few key other people get tapped as the "planning team". You'll be able to recognize this when you have "architects" or "team leads" who end up spending about a quarter of their time in meetings that the other developers don't go anywhere near.

This planning team then emerges from their planning with a set of very low-level stories: "implement this piece of functionality as designed by the system architects", "implement this design element as mocked by the information architects".

The coders then just pop a story off the stack, work on it, pop the next off the stack, work on that one, ad nauseum. Customer communication, tracer bullet implementations, and other kinds of flexibility still exist down at the lowest levels, but the creativity and problem solving involved in software development is just gone: the developers are really just code monkeys.

I've been a developer in that Agile model a few times, and every time, I've quit before the end of the contract. My key skill and joy is in solving problems, so this kind of assembly line Agile methodology really doesn't work for me unless I'm in that architecture team.

In my case the scrum master tends to be more than just a facilitator. He is a developer himself and is in charge of the framework of this project. The way he asks you to speak is like asking you to report to him, such as "John, how is your Address Dialog going?" with a military officer kind of tone. John is actually working on both the Address Dialog and something else, and he has to start with his work on the Address Dialog becuase it is the task being asked. He speaks about half of the scrum time and would make comments such as "Fred and John, I think you two should get together face-to-face to talk about this issue. Can you do this by the end of today?" He is very knowledgeable about scrum and has passion for scrum. But I don't believe he is doing the right way as a scrum master.

While on the surface Scrum can be a sensible and fluent way to keep communication open between management and development, it is also very much a numbers-oriented system that ultimately is used to rate the performance of the developer and restrict his or her thinking to something that is beyond their control or even their influence. By the time developers are brought into the picture, the "scrum master" and the "stakeholders" have already sorted out the goals and now development has to hustle to their 30-day sprint timeline, with every minute and every little thing now being meticulously watched. With all the attention only on the agreed tasks, and with management's continuous scrutiny on "burndown," developers feel a great deal of pressure at all times to confine their thinking and stick to the plan. Otherwise, they face the gnawing threat of having their issues run up the flagpole in 'retrospect' meetings, whose agenda are set by management only. This is the same management that will be writing their performance appraisals.

It seems that the great majority of advocates for Scrum are in middle-management or higher. While developers can understand the logic of the approach, I have rarely seen a developer who enjoys working in a Scrum environment. Often, "burndown" can quickly translate to "burnout".

- BCW

We had a developer introduce scrum to us and he became the scrum master. my department was 1 VP of IT, 1 lead developer(scrum master), 1 developer, 1 net support(me) Thats it!!! We somehow needed this micromanagement tool because we could not effectivly communicate between us even though we sit on the same row of cubes. Ok so we get scrum. now since I am playing Net support and IT help desk I have to be very flexible via remote trouble shooting and going to see whats wrong at the actual pc, printer etc... But with Scrum I now am being told how to do every aspect of my job and we now have a daily meeting where I cannot sit down until we each tell what we did the day before, will do today, and anything that will prevent us from doing as well. I felt like I was in a day care all of a sudden. My productivity went into the toilet due to dail meetings, breaking down documenting stories, inputing time, having more meetings about the next Sprint(two weeks), Having meetings about the last Sprint. Then couple that with a person that becomes the scrum master that 1. wants to be the little dictator and change your priorities every single day, yes every day no matter what I or the other developer worked on that was ranked the highest priority of the sprint. It changed. We did have 3 contract programmers cycle through 1 at a time as they left after having to deal with this Huge pile of mess. I also left as did the other developer. Scrum, It might be a great thing but it takes only 1 person to sink the entire ship and leaves way to much room for power hungry people to dictate your every move. Daily meetings 15 minutes each(lasted 30+) last sprint meeting lasted 2 hours (once every 2 weeks) planning sprint(we had no say even though we were supposed to laasted 4+ hours every 2 weeks) Time lost spent in meetings being told nothing but negative things 8.5 hours. Also dont try to pitch this as a non time management by saying cute things like "The stories are assigned points so there fore we are not tracking your time" Well Genius how are the points assigned? Never was answered although I read all the fluff material and its based on how long it will take you to do something HENCE TIME LOL. If Joe can do 25 points in a given sprint then lets flip over cards at the same time to vote on how long we think it will take joe to do said story. Well since im not a coder,developer I have a very vague idea how long it will take joe to do this but sure I'll vote on it. We all (contactors inc.) felt like monkies in a lab trying to solve the puzzle for our piece of fruit. Now if you like having others plan everything you do and take away any flexability you may have to be able to hold up your laminated card that reads go talk to the scrum master when a person is upset that they have had a request that will not get done becuse its not a part of this sprint and cannot plan short term(short term because 2 weeks is not a long term project and throwing a project 8 sprints down the road is not planning thats putting off and not preparing for anything big), then this if a great thing. But if you need to be adaptive to the changing roles that happen(break fix) Oh i guess nothing ever coded will break on you ever. I am watching at it being implamented at my wifes job now and laughing because they are having the same kinds of issues. If there are 5 people in the entire department why do you need this? I know how to have a weekly meeting and our email and calenders work just fine to let each other know and if anyone in charge could stick to a decission then it would get done. But With Scrum as well as anything thing else if the people doing the planning cannot stick to a plan and change their mind daily it will be a drain and cost said company good employees. Its bad enough to be micromanaged but being treated like your an idiot and like your a 5 year old. No thanks I'll pass Besides Rugby was never meant to be wussied up in such a manner, Be original get your own terms leave Rugby alone HA HA.

The status report or communication between the team is very necessary, they need to work closely to get the job done, when it is needed, it makes sense, it is not bad.