Scrum is a popular ever evolving practice composed of structured meetings, artifacts, and a time box. It is a non-technical framework for important communication that is much needed between the business (non-technical stakeholders) and the developers. As the originators claim, it’s easy to understand but difficult to master…And it needs to die in a fire.

One problem with scrum is that it doesn’t actually contain the mind numbing technical details of how to create software any more than this new process I invented for creating dishes for your restaurant.


Isn’t that ingenious how I captured the entire discipline of cooking with ‘Physically and/or chemically alter the ingredients’? Should I offer seminars and certifications for how to manage a kitchen or restaurant? Evidently the software community (or at least the project management community) thinks these over simplifications are useful, and they call them “Agile Frameworks”.

At best, scrum is way to facilitate communication using meetings and to give non technical stake holders more visibility into a technical field with a high barrier of entry using simplified artifacts. At worst it provides inaccurate abstractions that management thrashes over in hopes of gaining control over a thing they fundamentally don’t understand. When presented with any non trivial aspect of creating software, the ignorant apply more scrum as if another meeting or ‘scrum of scrums’ every day actually removes technical impediments instead of creating more impedance to getting real work done. Perhaps one of the worst aspects of scrum is that organizations prioritize time spent on perfecting scrum over refining their products and core values because they think that doing scrum equals doing software.

The reason that scrum is what you do when you don’t know what is being done is because software is difficult to create and organizations are desperate for the means to stay competitive in the cheapest and easiest way possible. It is not easy or cheap to master the creation of software. But there is this scrum thing that can qualify you to run a software team as scrum master in only days of training. Hallelujah! Even organizations that have been creating software for a long time are attracted to consultant power points promising more efficiency and control without any actual research.



Let’s pick apart some scrum components for their best and worst characteristics:

• Stories
• At best, stories are the elegant expression of a detailed scenario that gives developers plenty of information to formulate patterns, strategies, and implement a solution.
• At worst, stories are a bucket of words that mean all things to the business and meaningless self contradicting non deterministic instructions for the developers. Technical folks will still have to spend the time to fill in the gaps and can find it difficult to comprehend the big picture from an arbitrary description of a feature, or worse, they will just stop trying to penetrate the corporate veil of stupid ideas and code up an attempt of what was asked for.
• Tracking stories is just tracking another discipline known as ‘writing software requirements’ and many organizations are happy to keep scrumming along treating all stories as the good ones without ever trying to measure their actual value to the business.
• Story Points
• At best, story points are an accurate enough way to represent the effort, complexity, and risk of a story allowing stake holders to reason about, set expectations, and get a general idea of how much work is being handled.
• At worst, story points are a group guesstimate during a mob driven grooming meeting where everybody pontificates about how hard it is to do the part they understand. Individual skills and talents are averaged into this magical figure. If you think story points are meaningful google ‘ scrum poker’, it is a real thing that happens in serious places.
  
• Tracking story points is just tracking another discipline called estimation that doesn’t have any better success rate then software projects in general or scrum for that matter. If this group voting technique was so accurate why only apply it to story points? We should be making a fortune off of stock forecasts!
• Daily scrum aka Stand up
• At best, stand up is a team communication event to monitor progress, reveal impediments early, and assure that everybody is on point with their daily activities.
• At worst, it is the morning meeting where you find out who is late,  who is working at home, and the time when you make sure the burn-down chart looks good by ticking off a few hours on each story, which is justified because that story isn’t even what you ended up working on. Everybody shuffles out of this meeting mumbling ‘be sure to update the board’ like good scrum zombies.
• Sprint
• At best, a sprint is an iteration or time boxed cadence that allows for regular and consistent product demonstration, stake holder feedback, and even some self healing adjustments to the process itself.
• At worst, a sprint is just another arbitrary deadline with no clean start and a never done finish where the non-busy stake holders show up to the demos to comment on the colors of things, nobody bothers to read the project board and demand progress emails, and developers find themselves in more meetings then Nixon during Watergate.

Ah ha you say! You are not describing scrum because ‘no true scrum process does [blah blah blah]’, and I might even agree, but there is no true Scotsman , nobody is ‘ doing true scrum’ and that is part of the problem. It doesn’t help you understand how to measure reality, it helps you measure oversimplified inaccurate abstractions.

Scrum is difficult to master because it requires the same skills you need to create software and ‘some meetings, artifacts, and a time box’ is barely a fraction of what it takes. It is a thing that successful organizations transcend and failed organizations fall upon like a sword.

In all fairness, scrum has the best of intentions and isn't a terrible thing unto itself. It is simply being misapplied as the silver bullet that solves for a fundamentally non-predictive, creative, and discovery oriented endeavor being immune to top down scientific theory x management. As long as organizations value control and predictability over innovation and empirical product metrics, long live scrum!