Scrummerfall: World's Worst Software Development Methodology
- Why Agile Is Controversial: Agilists vs. Hubricists
- How to Make Agile 'Methodology Non Grata'
- The Insipid Results of Scrummerfall
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Let's say that you work for a company that's very, very skeptical toward Agile development. Then let's go further: In this organization that isn't ready to let go of the faux certainty of big cost projection up front, you—an agent of change—want to start moving toward Agile, a little at a time.
Do you try to move the whole organization to Agile at once? Or do you start bringing in small practices that aren't very controversial, something that almost no traditionalist will turn down, such as morning meetings in which everyone reports status in turn? Rather than answering that question directly, I want to reference a definition from a blog post written by Brad Wilson:
Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.
Wilson's post makes the point very eloquently that combining these methodologies leads to a style of development that just makes things worse, by souring Agile for the entire organization in the process.
Why Agile Is Controversial: Agilists vs. Hubricists
An Agilist is someone who is an enthusiast of Agile techniques for management of software projects. Let me introduce the evil twin of the Agilist, a persona whom I'll call the Hubricist.
To the persona of the Hubricist, an Agilist is someone who thrives from having a sense of certainty and control. For the Hubricist, Agile is a very scary way to go about things because it forces you to admit that you don't know everything. Doing a project with a Hubricist is like driving with the guy who doesn't really know where the destination is, but refuses to ask someone else for directions, because doing so wouldn't be part of the plan that was drawn out before the drive started. Hubricists are dangerous because they treat The Plan as if it were written on a stone tablet.
When a Hubricist heads an organization, entire corporate cultures can get caught up in the trap of putting The Plan before The Reality. Put another way, humility—individually or in the aggregate—is simply unacceptable in many corporate cultures that run on hubris. Humility appeals to the higher-order brain that can reason. But the fact that business changes—and therefore long-term software projects need to change—works against a Hubricists' more competitive instincts, in these organizations where the ability to provide the appearance of control is a fast track to upper management. In organizations where hubris is a cultural norm, "Don't worry, I have it covered" is a powerful thing for a program manager to say in the face of uncertainty.
Agile development techniques demand a level of transparency that makes the Hubricist deeply uncomfortable. Consider the concept of "onsite customer." Agile practice requires ensuring that a stakeholder who will be a user of the software is involved in the day-to-day process of creating that software. This possibility alarms the Hubricist because the onsite customer may see the totality of interim little "failures," such as designs thrown out, requirements reprioritized, and even code refactored.
To the Hubricist, seeing failures hurts his cause, making it harder to say his favorite phrase, "Everything is okay," on the day that the team revisited a number of decisions.
Other Agile practices—a continuously updated story-card wall, test-driven development, pair programming, and the like—are equally anathema to the Hubricist. The notion that an individual working alone can "get wrapped around the axle" (get stuck on a coding problem, wasting an entire day of progress) and might need to work in an open, collaborative way to reduce this risk works against the idea that progress always moves forward, hour by hour, in an orderly pace. It makes the Hubricist confront the reality that software development isn't assembly-line work that's easily controlled. Agile shakes down the entire notion that you can manage the software development process using Taylorian management techniques. When confronted with the realities of Agile, the Hubricist is deeply suspicious. I'm not saying that every Hubricist wants Agile to fail, but many are skeptical enough that they'll take any bit of evidence of failure, however thin, and declare that Agile Is Dead.