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.)
