What follows is an excerpt from a longer work chronicling the crazy mishaps and happenings during a one year period at an unnamed, but unfortunately real, company.
ABC Corp. won’t be credited for being the inventor of the non-organizing self-organizing team but they at least deserved a spirit reward for the valiant effort in creating total chaos out of a zen like theory on running software projects.  You can’t say they didn’t try.Scrum, like some religions, is based on the ideas of one man whose work is subsequently ruined by charlatans, tent revival preachers and true believers. They refer to him as just Ken (Schwaber) and it made Daniel nauseated to watch the process over and over.

It’s based on accountability (which we’ll get into later) and other feel good, rah-rah traits, that an organization with poor management runs to while trying to figure out why their “teams” can’t get it “right”. It’s an easy sell to managers – the concept is that the teams should “self-organize”.  It’s like getting paid to manage but not being required to do anything except “assist” or “remove obstacle”.

The most painful part of Scrum at ABC Corp. was sprint planning.

A sprint is supposed to be a given period of time where the development team commits to getting certain pieces of work developed, tested and in shape to possibly ship. For instance, the team agrees to create a login screen.  In most organizations this is referred to as a “user story”, as it describes something a customer (user) wants to accomplish. The “story” is given enough detail on paper to get started and then it’s up to the developers, designers, business analyst etc. to complete the concept, development and testing of the feature. It turns it into a team effort.  Not so at ABC Corp., which we’ll bullet out for brevity.

1)    Everything is high priority.
2)    Bugs just “need to get fixed”.
3)    There is no plan – no initiatives to group bodies of work. Each item is an individual task.

What’s a task?  It could be this “login” story described, or it could be a fix to some spelling on a product page.  ABC Corp. management took it farther insisting on a decomposition of tasks down to the sub-atomic particle level – completely bypassing the whole concept of “a team moving a ball down a field” and insisting that everyone sit in a room together, all day, and identify all the tasks that would go into this login screen.  A more clever team member who unfortunately ended up in Nowhersville like Daniel coyly commented one day:

“Plan every single task for a two week period up front.  Decompose those into very small pieces.  Assign those pieces and demand they be completed.  Hmm, uh, that sounds kind of like a waterfall approach.”
The other ABC Corp. employees disagreed that it was waterfall, they insisted this the decomposition was necessary so that someone else could pick up those tasks if needed.

A change in management later on made this process even more fun by replacing the white board task decomposition all day activity with forcing each developer to decompose his tasks in their IDE, on their laptop, while sitting in a room full unproductive developers doing the same thing.

Now, Scrum is supposed to be in the Agile camp, hence, Agile methods. ABC Corp. management did not want the technical methods – what they heard was: “we get new features into production every two weeks. That’s what Scrum says.” And surely, they wielded this concept like a sword, slashing through any wary developer, technical manager or CIO without mercy.

Now, onto the accountability of Scrum (or any agile process): the developer was responsible, period.  Recall that management of the company believed they had moved to Scrum to get features out faster – if that is the case – why in the world would a feature ever be late or not completed at all.  Further, they knew from some random Scrum resources on the internet that developers are supposed to respond to Change.  That is a big “C” change – meaning, that it’s ok for a division manager to change his mind mid-sprint, ask for a large change and still have it delivered on time.  Again, this is what Scrum tells them.

(To be clear, Scrum is nothing like what is described above or how ABC Corp. did it.)