In a previous post I promised to write an article about the shortcomings of Agile. I recently had an exchange with a former colleague that convinced me the time has come to have an honest discussion about what Agile does not do well. Through the years, Agile seems to have acquired a cult status, where people seem to think that it can, not only, do everything, but do it superlatively well. Anyone who has actually used Agile methodologies knows that neither of those points are true, yet Agile continues to be presented as the solution to everything. Even in the cases where Agile has clearly failed, people think that it would have succeeded, if only the organization was “more Agile”, whatever that means. Although strictly speaking a meta-point, I would like to make that the first shortcoming: Agile is really bad at talking about what it's not good at!

Agile is applied to scenarios where it is entirely unsuitable

Perhaps as a direct outcome of the fact that Agile is really bad at discussing what it is not good at, it ends up being applied in situations where it is entirely unsuitable. It seems to have escaped the notice of most people that Agile was meant to be used in the context of software applications where the main value is the interaction of a user with the application itself, such as most common Web apps or mobile apps. But those two sectors do not, by any count, represent even the majority of software out there. There's countless lines of code in embedded systems, firmware for peripherals, software for industrial process control, software for autonomous processes, and many others, where the assumptions of Agile break down fairly quickly: what would a user story look like, for example, for the portion of the ECU (Engine Control Unit) software in your car, which adjusts ignition timing? In the software field alone, I can think of the following examples where the Agile concepts would not fit:

1. Embedded systems, where there is no user (such as the ECU example above, or industrial process controllers).
2. Software in any device that requires certification, including medical devices, devices that have CE certification, etc. Such devices must be re-certified when the software changes, so the idea of shipping in small increments is simply impractical.
3. Any device where field updates of the software are not possible (practically most of the devices out there right now). Shipping an increment is simply nonsensical in that scenario - you cannot alter the software once the device leaves the factory floor.
4. Any software which implements a published, standard, specification (the networking stack in any computer, for example). The fundamental raison d’être for Agile, the ability to change your mind about what to build, no longer makes sense in that scenario.
5. Related but worth a special mention: slow-changing APIs that need to remain backwards compatible. The reason why it is worth a special mention: this covers quite a few of the back-end microservices that power web apps and mobile apps!

Rather than add more and more, I will summarize with the one misapplication that I find as scary, as it is incomprehensible:

Given that an aircraft has to go through a very long and very costly certification procedure, I am not even sure what shipping in small increments would mean in such a scenario. I can only hope that someone misunderstood what Agile means, and that they are not really invalidating the results of decades of NTSB accident investigations on a 2-week cycle.

Easy to follow the rules, but still be doing it wrong

My guess is that practically everyone who has first-hand experience with Scrum, has experienced this. If you are one of the lucky few that haven't, just search for Zombie Scrum.

As far as I can tell, there are two reasons behind this:

• When people are trained in Agile, they tend to spend a lot more time with the rules, rather than with the objective. And I have only once seen an Agile training course that provided a direct link between the rules, and the objectives that they satisfy. As a result, people walk away with a good understanding of the rules, and little understanding of what these rules are trying to achieve. Think about how often in dailies, people talk about their three points but still miss the fact that for the task they are about to do next, they have a dependency that is not satisfied.
• The rules enable the objectives, but do not ensure them. In mathematics you would typically call this an under-constrained system. In logic, it would be expressed as “The rules are necessary, but not sufficient”. It is one of the common fallacies to confuse necessity with sufficiency.

My advice would be:

1. Give formal training to everyone on the team - don't rely on them picking Agile up anecdotally from previous jobs or slide-shows on the Internet.
2. In that training make sure that you dedicate at least twice as much time to the objectives, as you do to the rules. The objectives should be the primary learning that people are left with.

It confuses Business Value with User Satisfaction

While I would describe Agile as going as far as being dogmatic about Business Value, I feel it does a very poor job of following through on this dogma. Yes, user stories should be prioritized according to business value. Yet, when you received your training you probably covered to great length the process of estimating story points, but how much time did you spend on estimating value? You know which factors go into the cost estimate (effort, complexity, risk) but do you know which factors go into business value?

And while the reduced (albeit highly opinionated) focus on business value is bad enough, I believe Agile contains a fundamental conflict between Business Value and User Satisfaction, stemming from the naive assumption that all business value comes from user satisfaction¹. The bulk of the Scrum rituals, for example, are focused on user satisfaction, rather than business value. The entire process of writing user stories (shouldn't they really be business stories?), as well as the demos, are directly focused on increasing user satisfaction. While that is certainly not a bad thing, it does mean that any functionality that has business value but does not map nicely to user satisfaction, appears not to fit in the framework, and thus becomes a second class citizen. Practically the entire class of operational concerns would fall in this category. Imagine the issue of adding observability, or monitoring capabilities to the application, for example. While clearly of significant value to the business, I am fairly certain there would be a certain lack of enthusiasm from both the PO as well as the users when these come up in planning, or are being demonstrated at the end of the Sprint. Realistically, they are thought of as necessary evils, taking away development capacity for the “real” user stories.

Business Value in essence ignores Business Cost

In theory, work that reduces the cost of either developing the software, or (even more importantly) operating it, should be reflected in Business Value. But in practice, the concepts and language used by Agile create a strong counter-current that makes it really hard to think in such terms. We speak, for example, of “extracting business value”. When it comes to adding user stories that give the user a new capability, that mental model has an elegant fit: one's mind almost automatically wanders to the mental picture of a miner with a pickax chipping away at a rich vein. But try to make the mental leap to the concept of “extracting a reduction in business cost” and you will invariably end up with the mental equivalent of a face-plant. Also, how does one write a “user” story about adjusting the application to be able to use a cheaper form of disc storage?

In a lot of respects this is just an analog of the same point as the previous one. However, I feel it deserves special mention because of one particular type of cost: technical debt. The most common complaint of developers (and one of the most common interview questions for managers) is: “How do you convince your PO to prioritize technical debt?” My answer is usually some variant of: “You have to find a way to express the business value to her”, but while that may be technically correct, it hides the fact that in reality that is extremely hard. The result is a strong bias to extract business value by adding functionality, and against removing costs, even though in theory the two should be equivalent.

Agile makes overly simplistic and unrealistic assumptions

The most troublesome example is the idea that any team member can do any task. Agile needs this to be true in order to maintain the ability to schedule any user story at any time, irrespective of whether “the people that know how to do it” are on vacation, or in training, etc. If everyone knows how to do everything, then there is no problem - if a team member is on vacation you simply reduce the capacity of the team, and someone else will take care of the task. To me, however, this feels a bit like a bad physics joke: Assume a spherical cow in vacuum… While this may have been a plausible stretch of the imagination back in the days where everything was done through server-side rendering using ASP or JSP, and one needed to know 3 technologies at most, nowadays the proposition sounds ludicrous. On the front end alone, one needs expertise in one or more frameworks (Angular, React, etc.), HTML5, Javscript, CSS and Sass, Typescript, and probably some front-end testing frame-work (e.g. Protractor). Speaking of testing, one should really know Selenium, and of course, the Page Object Model, plus probably some basic automation to keep everything running smoothly. On the back end (and assuming only a Java stack), one should know about microservices and REST, API design, documentation and test tools, either TestNG or Junit, probably Spring and the associated 20+ modules for doing anything from data persistence to authorization, most likely Spring boot and the various starters, Maven, probably an observability framework, SQL, database migration tools (e.g. Flyway), a large number of design patterns, plus CI/CD, containerization, and orchestration. The expectation that every person on the entire team will know all of this is simply unrealistic. Teams try to make do with T-shaped skills but in reality this is already too much to even develop a superficial understanding of all the technologies. In reality, most teams simply deal with the fact that if some people are not present, some tasks cannot be performed, and the assumed spherical cow explodes in the vacuum, in a dramatic fashion.

Note that that is by no means the only simplistic or unrealistic assumption that Agile makes:

• Bugs are supposed to be solved in the sprint in which they are found, but this assumes a predictable arrival rate.
• The rules assume that nothing intervenes in the running sprint, but we all know that critical bugs are not imaginary, and that you can't really predict how many you will have, so the idea that the average velocity will account for them is simplistic.
• The INVEST criteria for user stories aren't always well-defined.
• The assumption that all user stories can be sliced into thin vertical slices is shaky at best.
• The idea that you can ship small increments without building infrastructure is simplistic (imagine shipping anything before you build your authentication and authorization infrastructure).

Agile scales very poorly

Agile at its core effectively ignores the scenario where building something takes more than one team. Needless to say, this proved very quickly to be a roadblock, and people tried to bolt on frameworks such as SAFe and Scrum-of-Scrums to at least contain the symptoms. However, as much as we like to pretend otherwise, these frameworks are neither agile, nor do they deal with the core problem of dependencies between teams. In reality, they assume that dependencies will be scheduled in a fashion such that they are satisfied; somehow. Well, guess what: that's exactly how Waterfall does it, and it is much more efficient at it! Just have a look at a good, old-fashioned Gantt chart.

Either way, even the most ardent proponents of SAFe would admit that the system would collapse completely above a dozen teams or so. Yet there are many organizations and products that require many more people than that. Agile simply has no answer to the question of building software that needs thousands of people. Yet such software is not as uncommon as you would think (see my previous post on Software Scaling).

Agile is too dependent on the quality of the Product Owner

In my experience, the success or the failure of an Agile team is almost completely dictated by how good the Product Owner is at her job. A good PO will manage to make even a mediocre team, with a mediocre Scrum-master, effective. A mediocre PO will have poor results even with a stellar team and a stellar Scrum-master. On deeper thought this is not surprising: almost all the critical activities have the PO as, by far, the main contributor. In particular:

• Determining the epics and road-map is exclusively the job of the PO.
• The estimation of business value (and, by extension, prioritization) is almost exclusively the domain of the PO.
• Writing the user stories (in a way that they meet the INVEST criteria) is primarily performed by the PO (with feedback from the team)
• Inbound interruptions (critical fixes, that one user story that is not that important but your biggest customer absolutely must have this sprint, etc.) land on the POs desk.
• The very function of Agility - changing what is built, or the priorities, to match changes in the market - is the function of the PO.
• Even the issue of technical debt eventually becomes a trade-off that the PO will get called to decide on.

In the end, all of the decisions that have a large impact on success or failure are left to the PO, whereas the rest of the cast gets to operate in a relatively sanitized and organized environment.

The problem with this dependence on a PO is, that such POs are hard to find and in great competition. In reality, POs become the weak link in the job of building a great engineering team. You may be able to attract great engineers and a great Scrum master at your new location, but if you can't match them with a solid PO, the investment will not pay off.

Summing up

All in all, Agile has its place in Software Engineering, and it is a place well earned. That being said, it does have significant shortcomings as well, and if these are not managed, they can destroy the ability of a team to deliver great results. Acknowledging, understanding, and systematically tackling these shortcomings can make sure a team can deliver on the promise of Agile.