This article, like many things, started as a comment made on Hacker News: As the parent said:

I guess the “No True Agile” crowd is as alive and well as they were 10 years ago. When it’s a failure, they always come out of the woodwork to let you know you weren’t doing it according to the orthodoxy. When you point out that it isn’t faster in practice, they gaslight you and claim that was never the point in the first place.

In a way it reminds me of a cult. You do a series arcane rituals that have no scientific evidence behind them, none of the process is data-driven or statistically proven. Frankly, it can’t die soon enough but as we all know some new hype will simply take its place to give busybody managers a reason to exist.

I have toned down in my pure agile advocacy in recent years because of what I will call the agile conundrum: Agile, as the agile thought leaders prescribe, is not often followed. True Agile (TM) is rarely practiced, and most places that call themselves agile are often a group of practices that conflict with the thought leaders’ prescriptions. Yet I am often frustrated by the anti-agile arguments because they do not argue for anything. In the effort to help raise the discourse, I offer this, to help them pick an alternative to argue for.

What is Agile?

To get to an agile alternative, I think we need to define it, else we are likely to define something that someone, somewhere would call agile. Part of nailing down “True Agile” is that trying to define agile is difficult, but I think I can narrow it down into two camps and three definitions.

  • To most of the industry, agile is a methodology or set of methodologies. For this group, Scrum, Kanban, and SAFe are the primary known methodologies, though certainly not the only ones. This group stops at the methodology itself. If you are following the Scrum Guide, you are agile. (Heck, I’ve seen a fair number of places that even skip these pieces.)
  • To the practitioners, Agile is a mindset. As the Agile Alliance says, “Ultimately, Agile is a mindset informed by the Agile Manifesto’s values and principles.” For them, the methodology is set at the team level, defined independently. “Alistair Cockburn suggested that a methodology is the set of conventions that a team agrees to follow. That means that each team will have its own methodology, which will be different in either small or large ways from every other team’s methodology.”
  • Those who subscribe to this definition usually have fluency in a set of practices that were developed or commonly adopted by agile practitioners. Agile has large overlaps with Lean and DevOps, for example. The Agile Subway Map or Arlo Belshee’s Agile Engineering Fluency are a few collections of that set of practices. This group can be considered one of common agreement, though we could also look at practices without universal support such as No Estimates or mob/ensemble programming. I would suggest that this set of practices are common to both of the above definitions, even if it is not a definition itself.

As such, I am going to take the following argument: there are two sets of practices that are both called “agile.” For the purposes of this essay, I am going to classify them as “doing agile” and “being agile,” and do not use either disparagingly. To argue for an alternative to agile, then, I am arguing for an alternative to both of these practices, rather than trying to distinguish between the two. (Otherwise, the simple argument is if you are experienced with one form of agile, the alternative is to experience the other.) While a non-agile approach may also adopt practices that been adopted by the agile community, this common set of practices are insufficient to call it agile if the mindset is based in another origin.

So, what are these alternatives?

Waterfall (Whole Design First)

Waterfall is given as the only alternative to scrum and the boogeyman that Agile replaces. However, as is widely described, the original paper upon which “waterfall” was coined spoke of it as “risky and invites failure” if done without iterations.1 That said, and I have worked at one company that used gates to proceed to the next phase of development and though that project had integrated testers, there was a separate user acceptance testing phase that certainly looked like a typical testing phase for waterfall. As we have already established this as a strawman, I will speak to a few variations on the theme instead, but suggest that the simple waterfall method is not an alternative. That said, we have a fair number that are Whole Design first. The key acknowledgment from these systems, however, is that the initial plan is not set in stone; it is a living document and adjustments can and should happen as organizations learn. As most people arguing against agile are not suggesting we move back to 3 year projects with no iterative developments, I won’t dive too deep here.

Structured systems analysis and design method and PRINCE2

If we were to look for a system in practice that looked remarkably similar to the strawman, we can find it here. The SSDM, most commonly used in software projects for the United Kingdom government, is a thorough example of whole design first.

There’s no sense in recapping the method when you can go here to read a recap, but the short is that if a project is feasible, someone will do a thorough investigation of the current system, build a set of options on which the constraints of the new system are determined, build a set of detailed requirements “free from error, ambiguity and inconsistency.” At this point, the architects are now let into the room, where they discuss the technical system options and build an extensive logical design. After this logical design, the developers are let into the room. The developers turn the logical design into code in a stage called “physical design.”

As this was in practice in the UK government, we can look to see how the system works. This report from the UK National Audit Office suggests that even with these guards, objectives of the software are often not clear, schedules are overly optimistic, projects aren’t transparent, and senior leadership doesn’t know about the project being late until it is far too late.

So far, we do not have a ringing endorsement of waterfall.

We can similarly disregard PRINCE2, another UK Government effort. It might be worth getting a retrospective out of the Product Management Institute to say what was great about these, but in general these have multi-thousand dollar courses to be certified, and are complex enough to justify them. PRINCE2 is more iterative in that there are iterations (see below), but is so heavyweight in its documentation requirements that it is difficult to classify it in the iterative environments.

However, if your argument is that we deliver software too frequently and don’t write enough technical design documentation in a multi-month effort to have it reviewed by a gate of architects and middle management, I guess this is a good place to advocate. (And if you’re outsourcing your software to the cheapest bidder, perhaps you deserve this.)

V-Shaped

V-Shaped software development looks similar in the first progression, but instead of delaying deployment and testing, deployment is not specified and testing is baked into each layer. Mohamed Sani has written an article about it, and I have seen a fair bit written about it, but I have not personally seen any evidence of whether it works or not. It seems to be more common in German government processes, and underlines some later implementations of the PRINCE2 model. However, most people who speak about the issues in Agile don’t seem to want to go into multi-level extensive testing and documentation environments. If you believe that the problem with agile development is that we don’t design up front enough and we don’t write extensive tests at every level, I think this is a fair argument to a path forward. That said, I see more people talking about building testing into the earlier phases of agile than I see it as a common critique.

Iterative/Spiral Development

I think it is safe to state that nearly every new project today is an iterative process in some form. While it is possible to gather all requirements up front, people gather these requirements into multiple milestones. With software as a service and product engineering, there is often no end of any given project. With that, we are far past the thought of a maintenance phase of any given software in the web world. As such, perhaps we should look to classical iterative development processes?

As mentioned above, iterative systems often look like a pipeline. If you have ever built a product milestone by milestone, you have engaged in iterative development. (Milestones are considered “water-scrum-fall” by many in the “true agile” camp as it means that you have predefined the set of features and are dividing them up without releasing more frequently and learning.)

Rational Unified Process

If you understand RUP, please explain it to me. I’ve tried to understand it multiple times and bailed out. It’s built by the same people who built UML and the two share its complexity disguised as trying to simplify project methodologies. Many involved with RUP bailed to jump on the SAFe train. If you think the problem with development is that we need to build UML for all of our components and that we don’t reuse enough code because it isn’t written in a proper object orientation, you might want to argue for RUP. (No, really. Those are two of their six best practices.) 2

SAFe

I’m cheating, because SAFe considers itself agile. I would most charitably call it an iterative development methodology that uses some agile practices. Many complaints about agile from developers are exactly the issues that SAFe exacerbates with its standardization of practice, heavy meeting system, and coordination around a release train. If you are arguing that the problem with agile is that there isn’t enough process or meetings, SAFe is a defensible position.

Generalized Spiral Model

The Spiral model is another complex system that isn’t used much today, and is largely a predecessor to many of the agile practices. The idea is that a prototype is built based on the requirements and a preliminary design. The stakeholders are gathered again and everyone looks to see if the risks have been properly addressed. If they have, the system is built. If they have not, the project is terminated or a larger prototype is built to identify successive risks. It also suggests partitioning separate features and building them in their own spirals, which may be built successively or in parallel.

Conceptually, it is interesting as a place to start if the argument is that we need a better system for developing large software, but we should continue to think of them as products and should look for a root where we can grow to an alternative solution. I’d also look at this report that has some notes on spiral in the field if you are looking to start your argument here. If your argument is that we need to throw more software away, the spiral model is a good place to start. 3

Other approaches

As agile has sucked up the project process oxygen, we haven’t seen many new development methodologies that don’t start with agile as an assumption. That said, there are a few worth talking about.

the Project Management Body of Knowledge

The PMBOK today has a lot of nods to agile, but it does speak to predictive methodologies. The predictive methodologies look a lot like waterfall practices when I look at them. If you are looking to build your own replacement of agile, working on previous best practices, it may be valuable to start with the PMBOK to determine your points of agreement and disagreement. If you’re just looking to complain or are advocating for another model, this may be a waste of time.

Shape Up

37 Signals, the team behind Hey.com, Rails, and Basecamp, built their own product methodology. The basic idea is that there are bets every few weeks (basecamp uses six week cycles) and all planning goes back to the drawing board each cycle. A product can be discarded or re-invested in if there is a failure to release within those six weeks. There is a chance to pitch ideas every 6 weeks, so there are no backlogs. This is deadline-driven development but there are weeks of cooldown in between which is a great way to coax deadlines past sustainability yet still claim to be sustainable. However, you may find that you can argue this is better because developers are left alone for six weeks at a time, this may be a good place to argue from.

Programming Mother****er

On the other end of the spectrum, we have Zed Shaw’s rejection of all methodologies. This “methodology” suggests that the only thing that matters is programming itself. Product, design, and management doesn’t matter. Customers don’t matter. Any methodology that gets in the way of the programmer must be “destroyed,” as the manifesto states.

There is no importance in programming the right thing in this methology. A charitable argument would say that this is satire and not a proper methodology, but nothing about Zed Shaw’s history online shows any evidence that it is any less than earnest. If you think that the only thing stopping great software from being developed is that your users are too stupid to appreciate your great program, this may be a good place to start.

Ad-Hoc project management.

And we get back to the original comment.

The alternative is to just do what makes sense, without calling it anything. Junk shit like what scrum has become, for example not discussing technical stuff during standup (why the fuck not? that’s what our job is about), artificially splitting stories into 2 week boxes (why the fuck should I break down something that isn’t naturally breakable?), why create a card for every thing I’m working on (fucking control freak heaven), etc. It’s completely juvenile, gaslighting, cargo cult scientology.

Continuous integration => of course, for me, never worked at a place where it didn’t happen and that was before agile was even a thing. If I hopped on a project where it didn’t make sense though, I should be free to ditch it.

There is no one way to write software that works for every project and there is no one process that works for every project. Just let the experienced folks decide what to use instead of leaning on some bullshit fixed crap process.

This is an appeal to “common sense” that looks similar to Zed Shaw. Every project is its own snowflake and each company is beholden to its most senior members and their intuition. We make no effort to coalesce best practices and instead intuit from first principles and previous experience.

This is a good way to be steamrolled into death marches as a profession. Having a set of agreed best practices informed by collective experience that includes things like “sustainable pace” have a chance of building case studies and showing that great software can be developed under humane conditions.

That said, ad-hoc methodologies may be valuable in some cases where the system being built is entirely novel or when teams are very small and the project can be held in the head of all participants. Further, I do want to clarify that this does not mean that there is one best methodology or that every project needs to be standardized on the same methodology, agile or otherwise. However, in most spaces where agile is criticized, it in in systems that are not free from these constraints.

But when I see people complaining about agile, this is the most common alternative suggested. I can accept the argument that we need a post-agile methodology, and I can accept that neither agiles are as good as some other methodology out there, but now I can at least give you, dear reader, a list of alternatives to argue from when I ask, “if not agile, then what?”

Thank you to James Carr, Mark Bastian, Curtis Warren, Hans Gerwitz, Eitan Adler, and Jim Hardison for initial eyes and comments.

  1. This is a vast simplification. As Eitan Adler pointed out to me after the first version was released, Bell and Thayer 1976 referenced the Royce paper, and they were the ones who mentioned Waterfall. However, Bell and Thayer attribute waterfall to him though it wasn’t mentioned in the first paper, and they only briefly touch on iteration through the development cycle. Further, according to Wikipedia, Barry Boehm mentions two previous papers by Benington and Hosier that had “good approximations to the waterfall model.” Nevertheless, the key players all pointed to the necessity of iteration in software development which was the original point. As Adler points out, “Royce was an employee of TRW, a government contracting agency working on aerospace amongst other things. At the time this was written Royce was simultaneously discussing what was actually being done and also suggesting better ways to run projects.” Thanks again to Eitan Adler for this discussion! ↩

  2. As an interesting aside, Dr. Winston Royce, of the 1970 paper referenced above, had a son named Walker Royce. Walker Royce was employed by IBM’s Rational division and was employed by TRW at one point. IBM’s page called him “a principal contributor to the management philosophy inherent in the IBM Rational Unified Process.” ↩

  3. As another interesting aside to the aside; Winston Royce, Bell, Thayer, and Boehm were employed at TRW sometime in the 70s. It’s also possible that waterfall as a term came out of informal conversations. But Bell and Thayer cited a Boehm study, and Boehm himself is responsible for the Sprial Model paper. I would posit these three papers were checkpoints along the way of TRW building their internal processes. Software process geeks and agile alternativists would do well to study this evolutionary line. ↩