When we build software in an Agile process correctly, we discover that it is actually more efficient and quicker to do high-quality work than in a traditional Waterfall process. This is because a traditional Waterfall process devotes very little time to actually building software, which is where the value is to the customer.
We spend a lot of time in a Waterfall process gathering requirements, writing specifications, building tests plans, assuring quality assurance, creating documentation, etc. We think these things are important to ensure quality software development but it leaves us with so little time that we end up doing a poor job of the one thing we were supposed to do in the first place—build software.
Some of these things are important but the proportion of time we spend in meetings and delivering non-functional requirements is often too much in a Waterfall process. Of course, many of these artifacts serve an important purpose and the idea of a process gives us checks and balances that allows us to make sure we are following a plan and making progress. We don’t want to forsake these things when we build software in an Agile methodology; it is just that we achieve these goals differently.
Developers love to develop so in Agile that’s what we spend most of our time doing. We write code and we write tests. Tests, the way we write them when doing test-first development, isn’t for quality assurance purposes but rather as a way of helping us do design. This makes our tests just as valuable as our production code. So, with Agile software development, developers do what developers love doing most—writing code.
When developers understand this and they are armed with the tools that allow them to effectively write quality software quickly, their productivity explodes. I regularly see teams produce two to ten times as many features then previously while dropping defect rates up to 80%. Honestly, if I didn’t witness this dozens of times with my own eyes I wouldn’t have believed it. All this happens by correctly applying Extreme Programming practices. The code they build is high quality and without a lot of technical debt.
Really, when you think about it, the traditional way that most teams build software is highly inefficient and prone to errors. It is easy to do better. I’ve tried most every methodology out there in the last four decades. Emerging designs with design patterns, test-first development, and refactoring is by far the safest and most efficient way of building complex software. You don’t need it for simple stuff but when building enterprise software these techniques mean the difference between having a truly Agile code base that can accommodate new features and an intractable mess that resists nearly all changes.
Agile was created as pushback to the long, drawn out processes and meetings of Waterfall. Scrum tried to cut down meetings to 20%. That’s still too much, IMO. When we pair and mob together, share metrics, and interact as a team then there can be far fewer meetings and much more collaboration.
Stay turned for a total new format on this blog, my newsletter (subscribe at the bottom of the homepage), and my YouTube channel (@ThePassionateProgrammer).
