Developers Should Abandon Agile

Types of Agile

1. Extreme Programming
2. SCRUM
3. DSDM
4. Adaptive Software Development
5. Crystal
6. Feature-Driven Development
7. Pragmatic Programming
8. Lean Development

Big Business
“Agile” has become big business. Led, no doubt, by the Scrum Alliance’s successful Certified ScrumMaster offering, we now see hundreds, perhaps thousands of so-called “Agile” coaches and trainers, and many competing frameworks and methods. We see “Agile” leadership training, “Agile” project management offerings, and on and on.

Good for the enterprise
Now, many, perhaps most of these offerings are not bad things, at least for the enterprise. Organizations that try to improve usually do improve, and so even if “Agile” ideas are applied poorly, trying will almost always provide some benefits to the organization. The organization should at least get increased visibility into what’s going on, and that will often lead even the least enlightened management to make better decisions. That’s good, and I’m all for it.

Not so good for developers
The picture is not so attractive for developers, all the people engaged in actually building the products that the “Agile” enterprises are undertaking. When “Agile” ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to “go faster”. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing “Agile” poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing “Agile”.

Safe, not SAFe
My thinking is taken from something Kent Beck said over a decade ago. I would like the world to be safe for developers. At my core, I am a developer, despite years of management, consulting, and writing. I worked with code earlier today, and do so every week if not daily. So it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers’ lives worse, instead of better. It also saddens me that the enterprise isn’t getting what it could out of the deal, but my main concern is for the people doing the work.

Over a period of years, I’ve heard from many developers who say that “Agile” sucks. (Usually they say that “Scrum” sucks, because most people in organizations trying to do “Agile” are in organizations trying to do Scrum.) I’ve tried to help those people understand that their organization is doing “Agile” wrong: they’re not doing what the Manifesto authors recommended, what Scrum recommends, what the many Agile Software Development experts recommend. My hope was that people within the sound of my voice would help themselves, and their organizations, move closer to the real ideas behind Manifesto Agile and away from the many forms of Faux Agile or Dark Agile that we see around us.

That’s not really working out. Efforts like “Advanced” Scrum training and certifications, and leadership-focused efforts are good, and may bear fruit over time, but they will proceed at best slowly and may never really filter down to the poor developers in the “Code Mines of Ohio”.

It’s time to try something new, and here it is:

Developers should abandon “Agile”

Mind you, developers will continue to find themselves working under Scrum conditions, or in organizations using SAFe. Some may even encounter more obscure “Agile” approaches like “DAD”, or, if they’re fortunate, more enlightened approaches like “Modern Agile”, or “Heart of Agile”. Some may even be lucky enough to find themselves doing Extreme Programming, also known as “The Scrum That Actually Works”.

Detach from named methods
Be that as it may, I believe that developers should detach their thinking from any particular named “Agile” method. Instead, they should turn their attention and learning to ways of doing software development that will work within any of those “Agile” methods. Those development approaches, to me, involve use of practices such as, but not limited to, those of Extreme Programming. More generally, developers’ work should adhere to the foundational principles that support Agile Software Development, as we had in mind when we wrote the Manifesto. Today, I’d summarize the ideas this way:

No matter what framework or method your management thinks they are applying, learn to work this way:

Produce running, tested, working, integrated software every two weeks, every week. Build your skills until you can create a new fully operational version every day, twice a day, multiple times a day.
Keep the design of that software clean. As it grows, the design will tend to become complex and crufty. Resist and reverse this tendency consciously, refactoring in tiny continuous steps, all the time, so that your rate of progress is as steady and consistent as possible.
Use the current increment of software as the foundation for all your conversations with your product leadership and management. Speak in terms of what’s ready to go, and in terms of what they’d like you to do next.
This is the development team’s best hope for a reasonable life. By keeping the software always ready to go, we can hit any deadline with the best possible result. “Is today the deadline? Here’s what we’ve got, it’s ready to ship.”

As we lead up to the deadline, and as we negotiate what to do next, the running software in our hands lets us keep the conversation focused on the next, most important thing to do, rather than the near-infinite list of things they think they want. It’s not easy to change the focus from “do all this” to “do this next”, but it’s our best chance for a decent life, and it’s often quite possible to get the focus to change, as we work to collaborate with our leaders rather than just work under them.

Under an imposed approach
Too commonly, the “Agile” approach a team uses has been imposed. Larger-scale “Agile” methods appear actually to recommend imposition of process. I include here the so-called “SAFe” method, Scaled Scrum, and LeSS among others. These are pitched to the enterprise, and the enterprise is expected to “install” them, or “roll them out”.

As a developer, you can be sure that this roll-out will not go smoothly nor in a truly Agile fashion. You’ll not likely be trained, much less educated, much less given the real help you need to do your job. Your leadership will perhaps have been trained, perhaps for as much as an entire week(!), to prepare them to bring about this sweeping change in the organization’s approach to product and software development. The road is likely to be a bit bumpy.

Real software is your only hope
– Leia (private communication)
But if you can reliably select work to do over the course of a “Sprint” or “boxcar” or whatever your release train conductor starts calling the time period, and accomplish that work, packaging it up in a running, tested, integrated, ready-to-go new version of the system, you’ll be equipped to do the best it’s possible to do.

Slow down to deliver
If you can’t quite manage that, I’d advise you to take on less work in each time period, until you’ve taken on a small enough batch that you can actually get it done. This will be difficult! People will push you to “go faster”. Do your best! Under pressure to sign up for more than you can do, I’d suggest that you work on one or two of the items, complete those entirely — fully packaged, tested, and working — and then do another, so that at the end of the boxcar you have something that you can absolutely call completed. Take the inevitable abuse for not completing everything, and try to drive planning and expectations from reality, not the fantasy of what was demanded, that you never had a chance to do.

It won’t be perfect, and for a while at least, it probably won’t be fun. It’s just the best chance I know to survive down in that code mine. Having a completed running product slice is the best way I know to possibly turn the situation around. In a bad situation, all we can do is our best, and try to help things to get better.

Clearly, in a more enlightened organization, or one with ongoing learning, things will become more and more open to real Manifesto Agile ideas. Life can improve, and I hope it will.

I’ve been in those situations, and other than leaving, the best I know is to do good work, keep it visible, running, tested, and integrated, and help people to see reality.

Choosing an approach
The Manifesto calls for “self-organizing” teams, and in the best case, that comes down to the team choosing its own process. If I were starting a company, I’d let the teams choose any process they wish.

I’d ask for results, not a specific process
However, there would be constraints, not on how they choose to work, but what I need to see. I’d make it clear that every two weeks at most, I would like to review their running tested product slice. They’d show me what they had planned to build, and what they built. It would have to actually work, and to contain visible capabilities that I could understand. We’d talk about what they should do over the next interval. And I’d make it clear that one week would be better than two, and that one day would be better than one week.

I’d provide help
I’d provide them with help. I’d provide someone with a solid connection to the business needs to be met by the product, who would help them decide what slice of work to do next. I’d provide access to training and support doing the work they need to do. I’d make sure they were equipped to do what I was asking them to do.

Of course, I’d do that because I know how to do this stuff. You might be lucky enough to be in a situation somewhat similar to that, at least to the point where you can choose your own process.

Shhh. Maybe XP!
If you do get a chance to choose, I’d recommend that you start with something like Extreme Programming. It contains all the planning and feedback loops you need, and it includes the basic technical practices you need to do what we’ve been talking about here, and to do what I’d be asking for.

And I’d recommend that you stay alert at all times for signs of all the other things you need. “ATDD, TDD, and Refactoring” are things that, in my opinion, you need until you know something better. But there are tens, hundreds, thousands of other things you need as well. Stay alert for those, and when you identify them, get them.

Excellence in making software is a lifetime activity. Even Extreme Programming, the best officially named approach that I know of, just scratches the surface. Moving toward excellence is up to your team and its members.

Summing up
Other than perhaps a self-chosen orientation to the ideas of Extreme Programming — as an idea space rather than a method — I really am coming to think that software developers of all stripes should have no adherence to any “Agile” method of any kind. As those methods manifest on the ground, they are far too commonly the enemy of good software development rather than its friend.

However, the values and principles of the Manifesto for Agile Software Development still offer the best way I know to build software, and based on my long and varied experience, I’d follow those values and principles no matter what method the larger organization used.

I offer that opinion as advice. Do with it as you see fit.

Here and in other writings, I use the quoted word “Agile” to refer to the many instances, approaches, and processes that use the word “agile” to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to “Faux Agile” for emphasis, or to “Dark Agile”, which I use to describe so-called “Agile” approaches that have really gone bad. I might refer to “Manifesto Agile” to mean the core ideas from the Manifesto, in which I still believe.