Just Say No to Agile
- D'Anne Harp
- Sep 12, 2019
- 4 min read
I've avoided speaking out on the evils of Agile in this blog, but after watching the erosion of human factors as a discipline within the dot-com domain since the introduction of Agile, around 2005, in the last three years, I've seen evidence in aviation, medical, and military job postings that the cancer of Agile has spread to areas where I held the process of evidence-driven and tested design to be a sacred value. I am deeply troubled by this. In high-consequence applications, people die if mistakes are made. There is no warm-fix update that is appropriate when you're in the sky or a patient is on the operating table. There is no "Whoops, sorry, we didn't want to get around to thinking about that use case" response that is acceptable for turning out slipshod work, ever. If you carefully read the details about the recent Ethiopian Airlines Flight 302 Boeing 737 crash, yes, pilot error and pilot training were problems, but why, were they problems to begin with? Because the software system that had been released did not adequately obey the pilot's input nor present accurate feedback to the pilot that it was overriding the pilot. The more the pilot tried to adjust, the more unexpected results the plane produced. It's not even fair to chalk this crash up to pilot error, because no amount of pilot training can overcome a system that lies to the end user. However, the Boeing team released this interaction out into the field, with the Band-Aid of iPad training to make up for their product team being bullheaded, lazy, or perhaps obtuse to the fact of what an enormous, gaping problem they'd foisted onto the pilots in the cockpit, and the lives they'd put in danger.
No matter what your role in developing a product, we have an ethical responsibility to do no harm. Per my experience in the last 15 years, it is my strong hunch that the Boeing team didn't have a properly trained human factors engineer on the project, or the development team ran over the HF engineer and/or QA, and the product manager folded. It doesn't have to be this way.
Agile is Designed Not to Work
“Continuous delivery is the practice of releasing work to customers frequently—even daily or hourly.”
"Be proud to fail."
- Sally Elatta, Agile Transformation Coach
Agile was born out of the belief that impatient stakeholders were so insecure/anxious/distrusting/pushy that they would rather seen broken things as often as possible, and mark that as confirmation of progress.
Back in my consulting days, if we wanted to keep a client, that is retain their confidence and win repeat engagements, we took great care to only show them polished things that worked.
Yet nowadays, this "fail faster" mantra is not only foisted upon stakeholders, but broken things are pushed out into the actual market, with the belief that users enjoy and prefer troubleshooting things they spent thousands of dollars to purchase, and that the development team will have the bandwidth and sympathy/patience to backtrack, fix, or raze what they released, "if enough users complain"--and here's the kicker--that the business will be interested in paying the developers to develop something twice. Plot spoiler: Going back almost never happens. Business is far more interested in forging ahead.
Agile is Sexy, but Unsustainable
While the idea of continuous delivery may excite a developer or business manager with the belief of “more equals more,” user experience can show convincingly, this is not the case. Also, in my experience, Agile is three to six times slower than the traditional, iterative waterfall method that I used at several gigs, prior to Agile.
Consumers and businesses want things that work, reliably, and as specified. They are buying the device, the software, the experience, not the job of doing your quality control, troubleshooting, and redesign.
While “Fail early, fail often” sounds courageous and inspiring to some, to that I say, “Really?” Would you want that to be the experience on a new car you just purchased? On a bridge you are crossing? On a house you purchased? Why should we put in less care and attention to software deliveries, especially when the software is intended to not only support—but is essential in enabling a user to do his or her job?
I am sincerely concerned about the state of technology development. Somehow, along the way, in the race to be “first to market”, the importance of quality and integrity was lost, and here we are, deliberately issuing experiences that we proudly want to see fail. As engineers, how is it that we are now committed to not solving problems? How is it that industry is gleefully ADDING to the list of problems that our users now face, leaving the original issue at hand to fester like a wound? We are regularly burning our relationships with users, forcing them to contort into elaborate workarounds. Users would rather suffer in silence than be forced to adapt to another incomplete, bug-ridden release.
Call to Action
The Boeing crash should worry everyone, and I believe human factors engineers, product managers, QA folks, and developers can all play a part in turning the tide. I take my ethical responsibility as a human factors engineer seriously. I strive for excellence, safety, and integrity in all that I do. Join me. Speak out, within your teams. Speak out within your professional organizations. Blog. Publish articles. It's time to turn the tide.
