Several months ago I wrote an article lamenting the fetishization of Agile in place of the practice of actually being agile (aka process minimalism focused on production). It got a lot of traction (nearly 100K people bothered to take a look), a lot of misunderstanding, and even raised the ire of luminaries such as Uncle Bob. People come from different backgrounds and different cultures. As a result, not all literary devices translate equally. This is my response to all the responses I received.

Response: You Don’t Understand Agile; Agile isn’t Waterfall

Of course Agile isn’t Waterfall. They’re very different processes that look almost nothing alike. Agile is waterfall in the way that it’s been incorrectly embraced as the hammer for every problem, without ever really thinking it through. People embracing it in this manner use Agile and often Scrum as a cargo cult engineering process. They embrace the ceremonies (and they actually call them ceremonies) of Agile for the purpose of conducting the ceremonies. They assume that if they conduct the ceremonies, the gods of good software will reward them with good software. There’s no substitute for actually doing the work. Ceremonies for the sake of having ceremonies because “that’s what it means to be Agile” actively hinder getting work done.

Response: You’re Picking on Consultants

Guilty. I am picking on Agile consultancies. Why? Because they generally don’t work. Do some actually try to make your process better? Sure, I’d go as far as to say most act from a place of honesty. The problem is that they often introduce rules and process without understanding what actually needs to be done in your specific case. They want to be Agile. They want to hit the right words.

While they understand how to run an “Agile shop” they often assume that making software is all the same. It’s not. A company that builds dating sites isn’t the same as a company that builds software for insulin pumps. That difference is huge in what it means to be agile. In order to accurately determine what the right process should be you need a good understanding of the problem space. This is something an Agile consultancy will never have. You’re far better off hiring a team lead that understands lean processes as well as your specific problem space.

Response: Engineers Shouldn’t Be In Charge of Business Decisions

True (for the most part). That’s not what “engineer driven development” means. By engineer driven development I mean engineers decide how long things will take and what resources need to be allocated to make an engineering project successful. They’re the only ones qualified to do so.

Imagine you want to build a bridge across a river. You don’t say “we have 3 bags of concrete and 2 hours” then get a civil engineer to do the design. You get the civil engineer to do analyze the issue, and that informs how much time and how many materials you need. The engineer didn’t dictate where the bridge goes, how the city should grow or where businesses should be located relative to the bridge, but he did drive decisions related to the building of the bridge.

Of course we shouldn’t exclude the civil engineer from all decisions about where the bridge should go either. For example if we want to build a bridge across the Pacific, we might want to engage the engineer early so he can say “that’s not a reasonable request” before we spend lots of money and time to determine if the populace will love it.

In the same way, developers need to drive development decisions, but obviously these come with the constraints of how the business needs to grow. These constraints are defined by, or preferably, defined in conjunction with others.

Compare this to “business driven development” where your resources and time constraints are made based exclusively on what’s ideal for the business and you’re expected to “get it done” in those constraints. Would you cross a bridge built under those conditions? Then why would you build software that way?

Response: You Don’t Understand Story Points

Fair enough, but I would argue that no one “understands” story points because they have no fixed lexical meaning. They end up meaning whatever is convenient in the moment, and often changing their meaning later (though you’re stuck with the number). I was in a planning meeting for a client where the following statements were all made inside of 30 minutes (naturally there was an Agile consultant running the meeting):

1. Story points aren’t time, don’t try to estimate how long something will take.
2. If a story is over 13, we need to break it down because it means it’s going to take more than a [2 week] sprint.
3. Story points should be a single number that encompasses both effort and complexity.

What? How does any of that make any sense? Points 1 and 2 are contradictory (and by the way, often used in this manner) and 3 tries to take 2 completely unrelated things and mash them into a single unitless measure (to which we’ll silently add a unit in our heads, normally time).

If you insist on doing story points, use 2 numbers. One for complexity, and one for effort. Better yet, just guesstimate time in days. If you’re wrong, that’s OK, just roll with the punches.

Response: You’re Just Bitter Because You’ve Never Seen Agile Done Right

Capital A Agile can’t be done right because it’s more concerned with ceremony than advancement. There are shops doing minimal process right, if you work at one, great, Agile is the New Waterfall isn’t about you. The article was designed to give voice and perhaps offer some solutions to those suffering under flaccid scrum and other abuses of the buzzwords surrounding Agile.

Response: You Suck and You’re Dumb

Probably.

About Me

I’m Amir Yasin, a polyglot developer deeply interested in high performance, scalability, software architecture and generally solving hard problems. You can follow me on Medium where I blog about software engineering, follow me on Twitter where I occasionally say interesting things, or check out my contributions to the FOSS community on GitHub.