Do the Agile Principles Hold Up?

The last post generated a lot of feedback. Most was positive. Some was negative. This led to some interesting exchanges online that raise an important question: What exactly is “Agile?” Apparently, it’s simple. I was told, more than once this past week, that Agile is just a set of principles, and anything that aligns with the principles is Agile.

So, stated another way: Anything not at odds with the Agile principles can be claimed as being Agile?

That doesn’t seem all that helpful. Take some new set of practices. If the Agile principles did not meaningfully uncover, point to, or prescribe these new practices, but merely “aligns” with them, how does that matter? (Is it like a candidate being endorsed by a politician? It smacks of marketing, or a turf war.) Why do we then keep referring back to Agile, giving it preference over so many other ideas? It’s a bizarre obsession. As digital orgs — of necessity — continue to evolve past a 19th-century factory mindset, dubbing it all “Agile” in retrospect is misleading. Truth be told, Agile may not have even helped with this evolution much. Agile in practice largely lost to Scrum, which kept the focus on local cost and optimization, enforcing an incrementalist, “feature factory” mindset.

(As argued last time, I do think many in the product community are moving past this obsession. Younger product teams don’t seem to self-identify as “doing Agile.” They’re just doing product work. It seems like it’s mostly older people trying to claim that everything is Agile. Maybe it’s no coincidence so many exchanges with Agilists end up reminding me of Horace Nebbercracker in the movie Monster House.)

That some (rather vehemently) insist that Agile is the box everything must fit in is just weird. Isn’t Agile just one of many things? Apparently not. I have been told this week that Lean itself is “Agile thinking” (even though it predates the Manifesto by half a century), and that DevOps is just Agile too.

Fine, I say, if everything must be tied back to “the Agile principles,” then these had better be some pretty damn good principles. I mean, after a while, Agilists start sounding like the followers of Sydney Banks — “It’s all about THE PRINCIPLES….” So, these principles must be really important, pretty all-encompassing. If we don’t take them seriously today, we invite failure, right? Doesn’t this at least assume the principles all hold up today? It would seem to, else why all the hullabaloo?

But do they really hold up today? Well let’s just see. It may have been a while since you’ve read through them.

The 12 Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Who is the “customer?” I’ve seen people claim it’s basically “everyone impacted by your work.” That’s revisionist history. As Melissa Perri has noted, the Manifesto coauthors were talking about business stakeholders, which is likely why the Manifesto is still focusing on “requirements.” Now take the word “valuable.” Valuable to whom? As Mark Schwartz points out, the hidden assumption is that the business knows what will be of value (quite a BS assumption). One more question: How do you typically satisfy business stakeholders? Answer: By asking them what they want…and that’s why most features are seldom or never used and 60–90% of what we build is waste.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Requirements are not a good way to communicate, period. This spotlights that Agile is still focused on output, not outcomes. An “outcome” is the concrete behavior change you’re trying to achieve to create business value. It’s the users’ behavior you’re typically expecting to change, not the business stakeholders’. (Who then should you be spending most of your time learning about?) Focusing on outcomes makes you realize that your output is just a tool for testing your assumptions. As Jeff Patton puts it, you shouldn’t be trying to maximize output at all — you should be trying to maximize outcomes per minimal output. That’s how you increase “value.”

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Sure, shrink your damn batch sizes already. But realize what you’re really doing is vetting assumptions about what output will achieve outcomes, and what outcomes will deliver business impact. Whether you’re having the right kinds of conversations with users, having them show you their current workflow, sketching an idea, doing some quick participatory prototyping, or just always coding software, all of it is just levels of continuous vetting. And why the focus on software? It’s ironic when Agile teams say they don’t need to learn about discovery work because they’re already “inspecting and adapting.” As Alan Cooper points out, most Agile teams keep most of their code, which means they aren’t really inspecting and adapting anything. They’re just chunking their work into time boxes, and that’s not the same thing.

4. Business people and developers must work together daily throughout the project.

Nope. Business people must be kept in the loop. Developers and end-users must work together daily. I’ve seen people point to XP and say, “That’s what Agile meant.” Maybe, but that’s not what the principles say! XP had a lot of real goodness to it (ignoring that many people actually hate pair programming). It in fact introduced many concepts that are now a part of the DevOps movement. With that said, stressing pragmatism and progress over idealism, it might be time to admit that Agile lost to Scrum. As Patton argues, Scrum has a middleman, the “PO,” stand in as the “customer,” enshrining the client-vendor antipattern and typically further removing developers from their actual users.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

No. Building projects reinforces the practice of continually breaking up teams and moving people around unnecessarily. Kudos though for calling out the need to trust teams to get the job done. A lot of unnecessary calories burned around deadlines and time estimates and “scaling” boils down to not really trusting your teams.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I’ve seen data (from Larry Maccherone) showing that distributed teams (in the same geo) get more work done than collocated teams. That certainly gels with my experience. Further, when team members are collocated with each other but not with the actual users, that’s a bigger issue. Notice too that daily F2F collaboration also requires that everyone come into the office every day. This raises the question of more recent research showing that people who work from home have both greater job satisfaction and get more actual work done. As Jason Fried asks, what do you do when you really need to get something done? Most people do not go into the office, where it can be hard to concentrate and you’re apt to get constantly interrupted.

7. Working software is the primary measure of progress.

If that’s what you think then, borrowing John Cutler’s term, you’re a “feature factory.” Achieving outcomes is the primary measure of progress. If you build something and your target outcome measure doesn’t move in the right direction, you are not “done.” Who cares that you delivered working software? Notice too this principle assumes you’re always achieving outcomes by building software. That’s also false. Sometimes you need to redesign the underlying workflow. Sometimes you need to change a policy. Sometimes you need to convince stakeholders that some of their assumptions are false.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This principle promotes sustainable dev, which I’d agree with 100%. It’s worth noting, however, that Agile in practice tends to keep the focus on output and team efficiency. Agile was partially killed by the concept of “velocity,” which, I know, technically isn’t even a part of Scrum. Still, it happened. Instead of flow of value through the system, Agile unfairly kept the focus on the flow of work through dev teams. Output is not only the wrong thing to focus on, but doing so likely does not “promote sustainable development.”

9. Continuous attention to technical excellence and good design enhances agility.

What is “good design?” Do they mean “clean code?” Because, ya know, most Agile teams are loath to work with designers. (They hold their index fingers in the shape of a cross and start mumbling about “BDUF” as they write code no one is ever going to use.) This is what Gabrielle Benefield meant when she said Agile largely became an exercise in “building the wrong things righter.”

10. Simplicity — the art of maximizing the amount of work not done — is essential.

Of the 12 Agile principles this is probably the only one I would keep as is. Every time you say “Yes” to something, whether a request from a business stakeholder, customer rep, or user group, you’re saying “No” to lots of other options. The real question is how do you get better at discovering the right things to build? It’s not about making more bets faster but making smarter bets, and the best answers to how to do this are not embodied in the Manifesto or principles.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

The best requirements? Oy vey. The best architectures? Do Agile teams tend to determine the architecture? Not in my experience. The best designs? Those emerge by continuous discovery with users, not something the principles stress (or even mention). Further, a team meaningfully self-organizing sort of assumes it already has all the cross-functional, full-stack skills it needs in order to self-organize in the first place. The problem with this assumption is that Agile only focused on delivery. Thus, an Agile self-organized team ≠ a good full-stack product team.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Good, but why at regular intervals? Why not continuously? Keep going.


So…do the Agile principles hold up?

Well, what do you think? Be honest.