Agile Didn't Do It

2019-08-03 Business and Agile
Banner image for the article

The other day David Dombkins responded to a comment by Rajesh Mathur stating the following:

Fully agree Agile is not a [silver] bullet and it is not suited to over 96% of organisations. Agile has killed thousands of people through its [lack] of standards, compliance, [weak] T&E and minimally sufficient products.

He then went on to state:

The reports on Boeing clearly blame agile. In Australia the government services delivery agency with its [Robodebt] recovery process is accused [of over] 2000 deaths. The agile process delivers [minimal] sufficient outputs that are not bound by standards and have unreliable T&E. [It’s] about time the risks of agile are made public. Agile is in the end a cost cutting / profit maximisation methodology that is gift wrapping in fake innovation and kale empowerment.

I strongly disagree with this and stated that agile is being used as a “convenient scapegoat” in these situations. This is my side of the argument. I fully encourage anyone who disagrees with me to post a short response in the comments, or write an article stating your views. I am more than happy for you to quote any of my arguments as part of your response to this.

To begin with, let’s review the Agile Manifesto. The Agile Manifesto states 4 values:

  • Individuals and interactions over processes and tools;
  • Working software over comprehensive documentation;
  • Customer collaboration over contract negotiation;
  • Responding to change over following a plan.

I have also seen mention of an Agile Manifesto 2.1; although I don’t think there is much traction for version 2, let alone a version 2.1, for those who believe in this movement, the revised values are:

  • Teamwork & responsibility over individuals and interaction;
  • Business value over working software;
  • Partnership elaboration over customer collaboration;
  • Prepare for change over respond to change.

Notice that in these comments there is nothing about minimal outputs, in fact the second item in each version states the exact opposite, demanding working software or business value. Nowhere does it state that standards should be reduced or removed; nor does it say that compliance should be ignored. Plenty of organisations have successfully adopted agile practices in highly regulated, standards driven environments.

It doesn’t matter what system an organisation uses, if the organisation is cutting costs something has to give; in the case of Boeing quality was reduced; in the case of Robodebt poor data matching practices have been implemented.

David stated that agile is essentially a “cost cutting / profit maximisation methodology”. I don’t believe the Agile Manifesto was written with cost cutting in mind, some cost savings may occur as a side effect of implementing the values of agile, but it was never meant to be a primary driver. My reading of the Agile Manifesto leads me to the view that the manifesto is about the wellbeing and empowerment of individuals, reducing time wasted on tasks that are ultimately redundant, and improving customer experience.

# Robodebt

If we look at the example of Robodebt, this system could have been implemented through a waterfall or agile process. Agile didn’t enable this system to exist. Bureaucrats made a decision to implement some loose data matching and send out debt recovery letters; the framework of the welfare system allows the Department of Human Services to push the onus of proof on to the welfare recipient.

Robodebt may have used agile during the implementation process, but even then, two of the four agile values have not been honoured.

Customer collaboration was not undertaken, or if it was it was ignored. If customers were involved in the creation of the Robodebt system there would have been cases where it was found the data matching techniques were insufficient; customers would have highlighted the stresses caused by the false accusations of a debt; the system’s data matching techniques would have been improved.

The value of “responding to change” has also been ignored. Since the implementation of the Robodebt system it has become clearly apparent that the department responsible for this system has not been willing to respond to the calls for change, instead they have defended their position and ignored both community outrage and the side effects of their system. If the Robodebt system was being agile, we would have seen improvements in the data matching processes; it might not bet perfect, but it would be better than it is.

Although it is possible that the Robodebt system was developed by some teams that implemented some agile values, I will categorically state that:

Robodebt was not enabled or created from agile; it has not adhered to the 4 values in the Agile Manifesto; and if it is linked with agile concepts and values it is doing damage to agile.

# Boeing

Looking at the Boeing 737Max example, agile is simply a scapegoat for a company choosing to use cheap development practices, having inadequate quality control, and failing to use best practices in software development.

Every agile development framework I’ve seen (Scrum, SAFe, et. al.) is about the product lifecycle and the empowerment and enablement of teams developing these products. Many of the frameworks are iteration based, others are not, this has no impact on the requirement that a task is not complete until it is production ready.

Production ready can have different meanings for different organisations. In some organisations with a full CI/CD process, production ready may mean that task completion requires deployment to production; in others (such as Boeing), it may be that the task is successfully running on a simulator.

In the case of Boeing, running the software on a simulator, and having appropriate tests, the bugs that caused the Lion Air Flight 610 and Ethiopian Airlines Flight 302 crashes could have been discovered, a defect raised, and the software fixed prior to launch.

To me, one of the biggest issues with the Boeing situation is how long it has taken to rectify the issue. My understanding is that Boeing knew how to replicate the fault, yet it has taken months for a fix to be implemented; this highlights that poor software development practices have occurred.

Back to agile though. I do not know enough about the Boeing software development process, so I will trust that the software developers were in agile teams. If this software was developed in a waterfall process, I believe the poor coding practices would have been worse as developers would have been under time pressure to deliver to a schedule; all testing would have been left until the end of development, and it is far more likely that the testing would not have covered as many use cases. If agile is used without a waterfall wrapper, competent staff are used, and appropriate continuous testing is undertaken, then the final product should be of a higher quality.

# Summary

  • If your organisation is blaming agile for project failures, you’re using agile as a scapegoat.
  • If you prioritise cost saving over quality, agile is not the cause of your problems.
  • If you fail to test your product, agile is not responsible for your poor practices.
  • If one (or some) of your teams are using agile but they are bound by a timeline, your organisation is not agile.
  • If one (or some) of your teams are using agile but the project has been planned using traditional waterfall processes, you are setting that team up to fail.

Agile may not save you money, it may not increase your product quality, it may not increase your employees’ job satisfaction; but it will do at least one of these, and if done properly will likely do all three.

Getting back to David’s posts:

  • Agile is not a cost-saving measure, that may be a side effect of properly implementing the agile values, but is not guaranteed;
  • Agile is not responsible for the deaths of people due to organisation cost saving, diminishing quality or poor data matching;
  • Agile is not about reducing features, it is about delivering features in small increments so feedback can be gathered, and adjustments made to increase the value for the customer.

This article was originally published on LinkedIn The original article can be found on my LinkedIn Profile.

The article has also been reposted by Maurice “Mo” Hagar where a significant comment thread also exists.