LinkedIn: What Programmers Say About Agile

Yesterday there was a post in Slashdot that began,

After 20 Years, Have We Achieved the Vision of the Agile Manifesto?

I always read posts about Agile in slashdot, because slashdot is mostly a programmer’s forum, and so I get to hear what programmers think of Agile, rather than hearing only what the Agile community is saying.

The fact that the Agile community has come to consist of mostly non-programmers is tragic, according to Martin Fowler. (That’s him in the photo above, at the talk where he says this.) As such, it has also become an echo chamber. It is therefore imperative to go outside that echo chamber and see what others think, such as programmers.

Slashdot has a process whereby posts are upvoted, and those that have been the most popular are automatically expanded when you open a story. I went through the first ten top posts, and these are how they each began:

1. Well, they have succeeded in eliminating documentation, such as it were.
2. And don't forget, also eliminating QA. After all, to be truly Agile one must have the unwashed masses be your first line of testers, rather than wasting money on anyone in-house. (W10 much?).
3. Please add ‘architecture’ to the list of things agile successfully eliminated.
4. “A good programming language *should* be its own documentation though.” - Absolutely not. No. Never. It is impossible for the code to convey all the permutations of what it's doing, no matter how good someone thinks they've coded the software. Documentation exists (or should exist) for a reason: it describes in finer detail what is going on.
5. One thing that code will never ever be able to document is why
6. Seems like, yeah [eliminated QA]. (Most) professional practice involves adopting processes to maintain quality and consistency. Modern software projects seem more like an episode of reality TV.
7. Agile is less of a buzzword and more of a force that attracts buzzwords to it, like gravity but for buzzwords.
8. "People over processes." The article is talking entirely about processes, as if the people they interviewed (mostly consultants) haven't figured out how to value individuals.
9. A bunch of dudes who were used to really shitty ways of working assumed that all they had to do was throw some nice sounding principles on a wall and that would somehow change things. But they didn't actually provide solutions to the problems. All they did was state some general things about how they like to work. They didn't explain how it was possible to achieve those things.
10. The Agile Manifesto is a work in progress.

Hmmm. All pretty negative.

If one wades through, and expands some of the less popular posts, one can find a positive one here and there; but the consensus is pretty broad and deep: Agile has failed - at least from a programmer’s perspective.

Now What?

I am an agilist, yet I feel like I understand and relate to these comments. I feel like I understand the root causes of what these programmers are experiencing. Agilists will often say that the cause is “bad Agile”. But if such a large percent of the main constituency experiences mostly the “bad” version of something, one has to question the something: maybe it is just too hard to do it right, so that it can be “good” instead of “bad”. And if so, that is a fault of the something.

There are a lot of people and organizations that use Agile ideas well. It is not the majority, from what I have seen (spanning more than ten Agile and DevOps transformations), but Agile definitely has helped: today it is common for organizations to have a shorter time to market than before. Quality seems to have suffered though.

What does “good” Agile look like? Part of the problem is that the core narratives of Agile are not quite right, and are also very incomplete. The core narratives espouse things like:

• Self organizing teams.
• Servant leadership.
• Test-first development.
• Face-to-face communication.
• The less formal structure the better.

I am not talking just about the Agile Manifesto: the above list is drawn from ideas that are often expressed by Agilists within the community. They are all good ideas. The problem is, these ideas are sophisticated, and if one applies one of these ideas in a simpleminded or absolute way, one will get terrible results.

The set of ideas among common Agile narratives is also very incomplete. What about data? What about product design? What about leadership?

Why Agile 2

The Agile 2 initiative is an attempt to add to the Agile narrative, to fill the gaps, and to adjust things that have commonly been expressed in an extreme way. Agile 2 does not replace the Manifesto. It is not a manifesto. It is not a framework. It is not dogma.

Agile 2 collects ideas that are often expressed by people who do Agile well. As such, none of it is new.

We find that when we give talks about Agile 2, people say “I’ve been thinking that but was afraid to say it”. Agile 2 therefore gives cover to truths.

For example, one of the Agile Manifesto’s principles is that face-to-face communication is “the best” form of communication. Partly as a result of that, the community eschews written communication. Written communication is seen as a necessary evil, that is used only when face-to-face cannot be used. Not everyone thinks that of course, but it is a prevalent view.

It is not true though. Communication about complex issues usually requires multiple modes of communication. These are:

• Writing
• Reading
• Speaking
• Listening
• Thinking

Further, for complex issues, effective communication is a series of events over time - not a one-time event.

So the ethos that face-to-face is always best has damaged collaboration within organizations. A more nuanced understanding of what effective communication entails is needed. Face-to-face is important, but other modes are important too, in the right balance for the situation.

Agile 2 has principles regarding communication, and by providing those principles, people can now push back on the “Agile dogma” that face-to-face is always best; and if someone says “that’s not Agile”, one can now point to Agile 2 as a reference.

The Agile Manifesto is a very valuable document. It is not perfect though, and it is missing big things. We need to view it as only a set of ideas. Agile 2 provides additional ideas, and tries to add nuance to some of the Manifesto’s ideas.

Agile 2 is not dogmatic. It is not a replacement for the Manifesto. It is Agile. And it is needed because current Agile narratives are failing: programmers will tell you that.