is a popular
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
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
it provides inaccurate abstractions that management
over in hopes of gaining control over a thing they fundamentally don’t understand. When presented with any
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
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
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
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:
- 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.
- 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
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.
- 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.
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
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
that solves for a fundamentally non-predictive, creative, and discovery oriented endeavor being immune
to top down
theory x management. As long as organizations value control and predictability over innovation and empirical
product metrics, long live scrum!