If Haste Makes Waste, Does Agility Lead to Fragility?
Last updated: May 07, 2024 Read in fullscreen view
Recommended for you
- 01 Oct 2020
Fail fast, learn faster with Agile methodology - 14 Oct 2021 Advantages and Disadvantages of Time and Material Contract (T&M)
- 08 Oct 2022 KPI - The New Leadership
- 06 Mar 2021 4 things you need to do before getting an accurate quote for your software development
- 19 Oct 2021 Is gold plating good or bad in project management?
I've been struggling lately with the seemingly ever-increasing demand for things in shorter and shorter timeframes. It reminds me of the old proverb "Haste Makes Waste", which makes me wonder about the push within organisations to adopt faster and faster ways of getting their technology solutions into production.
The most prolific of these new approaches is Agile Development, which I have to admit, looks really good on the surface. It just makes sense in the way it attempts to address the legacy of project failures and overruns from the past, where teams, or even whole organisations, might get stuck in "Analysis Paralysis", only to find that when they finally deliver something, it isn't what the business wanted, or their needs (and the world) have moved on.
Development Study - Haste Makes Waste: A recent research project by Quantitative Software Management (QSM) found that spending more money on software development projects doesn't significantly improve speed or quality. The study, which analyzed over 7,200 projects over 30 years, found that adding resources to compress delivery schedules only took about 12 days earlier. This was due to the fact that large teams produced more defects than small ones, which took more time to discover, fix, and retest. Adding 11.6 times as many resources resulted in an increase of six times as many defects, a ratio of 2:1. This suggests that adding resources isn't as much faster, the software produced isn't good, and the project isn't cheap. The study suggests that the nonlinear economics of resource scalability may be due to the complexity of the latest software technology, rather than hardware.
I understand that desire, and I support the need to find new ways of avoiding those problems. Unfortunately, I see Agile being used in ways that aren't particularly well aligned to its original intent, and worse still, I see it being put forward as a "one-size-fits-all" panacea for IT teams and project delivery. This looks to be just as dangerous as any other attempt to describe a single approach that is expected to work in ALL circumstances.
To highlight some of the concerns, here are some observations I've made:
- MVP discussions have a tendency to create either technical or functional debt (or both).
- Funding cycles and a constantly changing focus due to shifting market demands can make it difficult to address the above-mentioned accumulation of debt, which can result in increased cost or delivery time on future projects.
- Agile approaches can be problematic when developing highly integrated solutions in complex, established environments.
- The implementation of Agile practices is often done as a bottom-up approach, typically involving a single project, which ignores the important process, people and cultural impacts of the change, not to mention the necessary support from the business at both an executive and operational level.
Now, it might be easy to respond by saying that these are just poor examples of an Agile implementation, but I suppose that's part of the point I'm making. There's a belief that adopting an Agile approach will "fix the problems of the past", but that seems to be ignoring the idea that it might come with its own problems.
It also erodes the value proposition of some established practices such as Architecture. Within complex environments, a great deal of information may be required before an Architect can establish an appropriate direction for a solution (or component of a solution). Within Agile teams, this tends to gives rise to the term "emergent design", which would appear to be contradiction in itself. The supposition that the overall design of the solution will emerge from the process of building it is fraught with danger, and its need for refactoring is often overlooked as part of the ongoing delivery of functionality (resulting in some of the above-mentioned technical debt).
Of course, I'm not saying "Don't do Agile!". I believe using Agile practices have significant advantages in a subset of development situations, particularly when development is primarily focused on a single application, and where the potential market is in a rapid state of change. An example of this might be the development of a new (primarily) stand-alone Mobile application.
What I am saying, is that proverbs have survived the test of time, due to their ability to succinctly describe aspects of human behaviour. Another one that might apply in this circumstance is "Slow down to go faster" or perhaps "Look before you leap". These highlight the tendency for humans to try and be better, faster and stronger than those they compete against, but also note that there are perils in doing so. I'm sure this is only exacerbated by the media hype reporting the "increasing pace of change", but does that really apply at the micro (or project) level?
What are your thoughts and experiences? Are we rushing into things? Is that as a result of a real threat, or is it just perception based on hype? Should we slow down and consider things more in order to go faster in the long term, or is the "new legacy" of waste, debt and half-realised solutions an acceptable sacrifice in order to keep pace?
Darryl Carr
Experienced Architect and Builder of Professional Communities
Explore more on these topics
Guest Blogging: The Definitive Guide
