Agile is a failure
09 June 2024For a while I worked in a company that took Agile very seriously but eventually developed a scepticism if it, especially when compared to the time-honoured Mythical Man Month. Admittedly I quite often use Agile and Scrum interchangeably so may well misallocate praise and criticism but it amuses me that El Reg highlighted a study that basically said adopting Agile causes a massively increased probability of project failure — a 268% increase to be exact. I am not surprised. In the next sections I go over what I think of the methodology, and then I will remark on what is highlighted as the core of the study: Documentation.
The good
Practical development of software is an iterative process and one thing it has really got right is the concept of a product owner who is responsible for answering any queries the development team(s) may throw up, and acts as the bridge who turns customers' desires into practical specifications. Fundamentally the root cause of why I changed jobs back in 2019 was the pre-emptive realisation that I was on a career-death project that no-one of appropriate seniority wanted on their plate, and I was better off spending my effort looking for a new company than super-human fire-fighting. At a different company I always thought the boundaries between planning and grooming sessions were a bit blurred but it at least kept software developers in the loop when scheduling features. As a rule-of-thumb the good bits of Agile are mentioned in Mythical Man Month albeit steeped in the archaic language of the 1970s.I am generally supportive of stand-ups because it provides regular opportunities to highlight issues, especially minor ones that don't warrant organising a specific meeting but might become major down the line. However having stand-ups daily is another matter and it has in the past been criticised as permanent crisis-mode, since much of the time there is little new to report but it keeps people on edge. The ideal number is two but scheduling limitations and not wanting them too far apart in practice pushes this up to three. Meetings are good but having more than one most days is potentially very disruptive to the creation of business logic.
The bad
A big assumption with Agile is that any given feature can be split into a large number of mostly-independent tasks, which is simply not the case for a lot of the type of work I have done for most of my career. What makes it worse is the time-boxing into self-contained sprints where time and time again two weeks — especially once a couple or so days were subtracted for testing — was grossly inadequate for the features to be added. Rather than just doing a double-sprint features were de-scoped to the bone, so the first sprint would have this half-done Frankestein's monster of an implementation, and the trouble letting that loose into releases takes another sprint or two of fixing up.Assuming some sort of task breakdown is made the next problem is estimating the effort, and while I understand that the numbers from planning poker are supposed to be abstract and not represent time, in practice this breaks down. The whole idea of a spike story — named as it supposedly makes a point — is a cop-out because it essentially means estimating effort having already done the task, and doing them regularly turns Agile's entire approach to planning into a charade. A lot of the stuff I have done during my career involves having to dig through documentation suck as data-sheets, usually having to make some sort of prototype in the process, so trying to shoe-horn this into Agile's structure ends up people wasting effort gaming the system.
..and the utterly awful
Significant parts of the Agile Manifesto are fundamentally written by marketing consultants with the aim of giving upper management an intellectual justification for bad practice, and ultimately this dogma is what ultimately undermines the entire methodology. I remember one scrum master talking about ‘scrum-but’ which causes problems due to scrum not being done properly, upon hearing a Polish college remark about the same thing being said about Communism. For example consider one thing that is a recipe for failure:Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.This is the second principle of the Agile Manifesto and straight up it says managerial indecisiveness and leaving things to the last minute is fine, but in reality it dumps the costs of inadequate planning on people who actually have to do the work. Mythical Man Month pretty much says the direct opposite of a rising bar to feature requests, because without a feature freeze of some sort QA goes completely out the window. And the trouble does not stop there, moving onto the tenth principle:
Simplicity — the art of maximizing the amount of work not done — is essential.Better known as kicking the can down the road. While over- generalising a solution can be a problem this implies always doing things in the most expedient way possible, and the inevitable result is an accumulation of technical debt. Back in 2014 my then-company put out a directive about getting test-case coverage up, which was done by stripping out a load of hard-to-hit checks aimed at corner cases . Needless to say this caused trouble down the line. This may sound like laziness but it is nevertheless entirely keeping with the principle of “work not done”.