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 933 - 18 Oct 2020 How to use the "Knowns" and "Unknowns" technique to manage assumptions 918
- 14 Oct 2021 Advantages and Disadvantages of Time and Material Contract (T&M) 757
- 19 Oct 2021 Is gold plating good or bad in project management? 720
- 06 Mar 2021 4 things you need to do before getting an accurate quote for your software development 595
- 08 Oct 2022 KPI - The New Leadership 550
- 01 Sep 2022 Facts Chart: Why Do Software Projects Fail? 524
- 19 Apr 2021 7 Most Common Time-Wasters For Software Development 518
- 11 Jan 2024 What are the Benefits and Limitations of Augmented Intelligence? 414
- 28 Dec 2021 8 types of pricing models in software development outsourcing 411
- 10 Dec 2023 Pain points of User Acceptance Testing (UAT) 399
- 23 Sep 2021 INFOGRAPHIC: Top 9 Software Outsourcing Mistakes 398
- 31 Oct 2021 Tips to Fail Fast With Outsourcing 369
- 16 Apr 2021 Insightful Business Technology Consulting at TIGO 367
- 07 Jul 2021 The 5 Levels of IT Help Desk Support 366
- 06 Feb 2021 Why fail fast and learn fast? 347
- 01 May 2023 CTO Interview Questions 288
- 13 Dec 2020 Move fast, fail fast, fail-safe 286
- 17 Feb 2022 Prioritizing Software Requirements with Kano Analysis 273
- 01 Mar 2024 (AI) Artificial Intelligence Terms Every Beginner Should Know 269
- 03 Nov 2022 Top questions and answers you must know before ask for software outsourcing 259
- 08 Jan 2024 Ask Experts: Explicitation/Implicitation and Elicitation; two commonly used but barely unraveled concepts 256
- 10 Apr 2021 RFP vs POC: Why the proof of concept is replacing the request for proposal 251
- 07 Aug 2022 Things to Consider When Choosing a Technology Partner 248
- 08 Nov 2022 4 tips for meeting tough deadlines when outsourcing projects to software vendor 238
- 18 Aug 2022 What are the consequences of poor requirements with software development projects? 234
- 20 Nov 2022 Software Requirements Are A Communication Problem 232
- 06 Nov 2019 How to Access Software Project Size? 229
- 10 Nov 2022 Poor Code Indicators and How to Improve Your Code? 202
- 07 Oct 2022 Digital Transformation: Become a Technology Powerhouse 195
- 26 Dec 2023 Improving Meeting Effectiveness Through the Six Thinking Hats 188
- 01 Mar 2023 Bug Prioritization - What are the 5 levels of priority? 186
- 09 Feb 2023 The Challenge of Fixed-Bid Software Projects 186
- 09 Mar 2022 Consultant Implementation Pricing 171
- 05 Jan 2024 Easy ASANA tips & tricks for you and your team 169
- 09 Jan 2022 How to Bridge the Gap Between Business and IT? 160
- 16 Feb 2021 Choose Outsourcing for Your Non Disclosure Agreement (NDA) 145
- 01 Mar 2023 How do you deal with disputes and conflicts that may arise during a software consulting project? 145
- 12 Mar 2024 How do you create FOMO in software prospects? 115
- 14 Mar 2024 Why should you opt for software localization from a professional agency? 112
- 10 Jul 2025 Building AI-Driven Knowledge Graphs from Unstructured Data 101
- 17 Mar 2025 IT Consultants in Digital Transformation 52
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
Top Trending Topics
Share This
Link copied!
Recently Updated News