Might work if you have a factory in place, and factory staff that have more cognitive ability than an assembly line automaton, but isn’t too good at entrepreneurial factory creation.

Theoretically, Scrum is supposed to be this lightweight management process that frees up developers to get work done. Well, reporting status every day, estimating the next two weeks in 2-4 hour increments, and planning out what the next couple of months will cover for backlog items is FAR more managment heavy than anything I’ve ever done before.

I’ve heard that if you are doing standup as a status meeting, you are doing it wrong. But telling people what you have done, what you are doing, and whether you are held up is exactly what I would do in status meeting. Or to put it another way, what would be different about a status meeting? If the answer is that status meetings involve management, then I’d say you don’t understand status meetings.

The thing that really bugs me about the daily standup is that it’s redundant, because I DO talk to people as necessary. If I make a change that I think will impact the team, I mail everyone. Muttering about it at standup is rarely productive.

And, for all the people who say “if Scrum doesn’t work, you aren’t doing it right”, that’s got to be the most circular argument in existence.

Just “fooling around” (ie. doing stuff that doesn’t _seem_ to have much to relate with the work at hand) until my subconsciousness works the problems out is also my modus operandi. Alas, it can be quite incompatible with the management types. In this particular job (the one with the Scrums) the managers actually wanted to sack me after about six months, until they mentioned this to my team leader, who informed them, that I was in fact their “best” developer (not necessarily the most productive, but the one with the most compact code (important in coding mobile software in early 2000s) with the least bugs). The managers were apparently quite astonished by this :P

Left the place after a year. The managers were so obsessed with nitpicking and unnecessary details, that for coders it wasn’t a particularly nice job (in fact, about half of the coding team left within half a year). The company folded a couple years later.

One of the best parts of XP to me was that our planning and scheduling was a process which adapted to us as much as we adapted to it. By roughly measuring and learning from the discrepancies between our estimations (ideal hours) and actual time spent on tasks (actual hours) we not only got better at estimating (i.e. guessing), even with quite exploratory code, but perhaps more importantly our weekly Big Visible Charts were a realistic description of how much we were managing to get done.
We didn’t allow them to be turned against us (to demand or bully us into promising more output or work) – instead, we used last week’s chart and ideal hours count (which did get closer to our 40-hour week as time went by) to plan the next week, cutting back on tasks as need be so we’re only taking on the same expected workload as we accomplished last week. Also, some of our other graphs were able to make it apparent when our schedule slipped due to late requirements changes from client/boss.

So, really it’s about planning through honesty and openness. If we got shag all work done this week, then it’d be unrealistic to expect double the output next week. Sure, if we’re really falling behind it might be brought up at the daily stand-up meetings, but that was never an issue. Pair programming helped keep a decent level of output too – if one guy is tired or needs to space out, his partner takes the keys for a while and vice versa.
Also, at those meetings I had no trouble saying things like “we didn’t get much done yesterday because I got confused by some mystery slowdowns so we played around with the code to see how Hibernate deals with sets that have been serialised and reconstructed. That took a couple of hours because, it emerged, Hibernate can be a bitch”.

But we were a very small team (maybe 8 coders) and openly experimenting with XP, rather than taking anything as gospel. Maybe it can get silly in bigger groups.

Also, if you truly don’t care what other people on the project are doing, then you should probably find another project to work on.

My algorithm for truly boring, useless meetings is to ignore them. If they are really, really bad, I’ll just quietly walk out. Another possibility: Find someone else to go in your stead (that’s what Program Managers are for at Microsoft — they go to meetings for me. Seriously. If they need really technical backing I’ll go).

Seriously, Scrum is a process that involves humans. Of course it can fail. That’s not the question. The question is: does it fail less frequently, or earlier, or more visibly than other processes? It sounds as if you’ve already learned that the leaders of your current project value following the plan over adapting to change. That’s valuable information.

I’m not sure why a developer would feel embarrassed about reporting that their estimate of the work has changed. Would you feel embarrassed if you discovered that a task originally estimated as a week was only going to take 1 day? Then why be when the opposite occurs? The improved estimate comes from increased knowledge about the problem AND THAT’S A GOOD THING. If your Scrum Master can’t deal with that, that’s his problem but, be sure, Scrum isn’t telling him to do that.