We need to talk about Agile...

Photo by Trnava University on Unsplash

I know a lot of companies and teams do an excellent job of Agile development at Enterprise scale. I am sure that they do. I've just never met any of them. I do, however, work with a lot of Enterprises that while they may be seeing some gains, aren't getting what they expected out of Agile overall. That big audacious goal of compelling, high-velocity, high-quality software built by autonomous teams of happy, fulfilled developers does not seem to be where we are ending up in a large number of cases. At best we test and release more than we did when we worked exclusively in waterfall models, and at worst I see complete paralysis where almost nothing of value is releasing to production.

We talk a lot about why this is. In these discussions we talk developer skills; we talk about funding models; we set up better systems for requirements grooming; and we talk about the criticality of including NFRs in our backlogs. All of these things are important and critical to running a successful Agile development program but I think that these discussions miss the elephant in the room.

Agile is about experimentation. It's about trying things, failing fast, and pivoting. It depends on measurement, feedback, and clear goals. What I see Enterprises doing is implementing never-ending streams of static requirements in smaller release increments. These are two fundamentally different ways of looking at software development. You are not "Agile" if all you are doing is breaking down your existing list of requirements into smaller groups and implementing them with reduced rigor.

Not every program or project needs to be or should be Agile. You can test more and break up your releases in a modified waterfall model and build great software. If you know what you want to build, and you don't have any reason to gather mid-stream feedback modified waterfall is a great approach. To do this you need to understand your base requirements, figure out your architecture, your design patterns, what your overarching NFRs are, etc., up front and then you work to your plan. That plan can be broken into increments that let you get software releases out the door quickly and it can accept that in the future there will be more requirements, but you essentially know what it is your are going to build and how you are going to build it. Lots of software falls in this bucket.

Agile, on the other hand, allows you to develop a product hand in had with your customer through experimentation and feedback. To be Agile you have to measure the impact of the features you are releasing against meaningful metrics and then change based on what you learned -- Does this feature encourage people to donate more money? Does this feature sell more widgets or does it just sell the same widgets differently? Do fewer customers give up in the approval process if we change this widget? Do we use less resources using method A or method B to achieve the same outcome? Does this feature drive more revenue than it costs to maintain? You make your own questions that are relevant to your business but if you have no questions, or no way of measuring how your feature answered your questions, you aren't being Agile.

If you aren't Agile, don't be Agile because Agile comes at a cost. If you aren't going to change what you are implementing based on feedback that you are actively seeking, that cost likely isn't worth accruing. The price of Agile is refactoring. Agile fundamentally embraces that we don't have everything figured out when we start, and it gives us permission to change our minds, but this means that we have to go back and refactor once we have found the best way forward; once we learn what we didn't know before; when we see that we are drifting from our ultimate goal. If we don't refactor, if we don't go back and apply what we have learned, then essentially we are using the name "Agile" to giving ourselves permission to build software that we never really thought through.