Agile software development has been talked about, and argued about for at least twenty years. While I spent most of my professional career managing software projects in a highly imbedded and mission critical applications, I experienced significant resistance from my teams to the agile philosophies and tactics from a variety of perspectives. Here were a few;
- Agile is not a single practice but a series of best practices that ultimately we assumed could be approached ala carte when in fact we allowed agile to change our processes as long as we could minimize the impact of change. Some of these practices (such as pairs programming) would require a significant change in the culture of the company. Hence, when taking the ala carte approach, some might say we “cheated” and never fully immersed ourselves in the agile culture. When our change program never fully succeeded, in part it was because we never really allowed it to succeed.
- However agile we became in software/product development, the net effect became irrelevant if the downstream organizations such as System test, field test, regulatory compliance and field implementation not to mention the customers themselves were not equally agile. A conspiracy of the entire value chain was needed to insure success of agile deployments.
- There is no such thing as a minimally viable product when you are shipping a mission critical application that is deployed in a public safety context, or when a regulator is expecting 99.999% reliability and accuracy or when lives are depending on the product to perform as specified.
- What value is agile development when the definition of the solution is already pre-defined and there is virtually no discovery of new features or capabilities to be pursued?
In any case, these are probably still the debates, among others, that organizations continue to have. In the end, there is value in some situations to work in a highly accountable, fast turnaround continuous “build” environment. The advantages are, first and foremost, that large massive “big bang” type builds hardly every work. How do you build a brick wall? One brick at a time. When you build incrementally you are containing risk and validating as you go. In that sense, if what you built today fails, you can always revert to yesterday’s build. Smaller and incremental approaches tend to be more methodical, predictable and more likely to succeed.
A useful article written for the IEEE discusses this topic at more length, exploring the cultural, and values based perspective. NU students can access this article at no cost if you are logged in to the NU system or are on campus: