by John Brooks, Vice President of Engineering
There is no doubt that in the software development world, Agile Development is a hot topic. Just about every company engaged in software development describes itself as an “Agile house” and I haven’t seen a software-related resume without Agile listed in a very long time. Amazon Books has more than 2,000 books related to the topic.
This often leads to an automatic assumption in our industry that by practicing Agile methodology, the resulting software will be higher quality than it would be if another development methodology were used. Ubiquitous references to this exist almost everywhere Agile is discussed, and it’s easy to understand why. I believe there are very high value aspects to Agile practice that can benefit almost every project. But what we as an industry sometimes miss when we see one development practice as a miracle method is a focus on the real end goal of software development—quality—instead of how we develop it. We should be focused on delivering quality software that truly works as it should.
Too many companies and Agile practitioners take it for granted that high software quality is an automatic side effect of Agile; but just like any other methodology, Agile’s practices must be properly executed, or quality will suffer. Agile is great, but Agile alone does not a perfect project make. There are some ways to bolster your Agile practices for a tighter, more quality-focused development process overall.
Software veterans can tell you the Waterfall model with its “iron triangle” was almost universal back in the 1970’s and 80’s, and is still in practice in many companies today.[i] That iron triangle, consisting of requirements, cost, and schedule, created an unintended negative effect: the critical dimension of quality was not even included! With requirements, schedule, and cost all fixed, the only variable was quality. And we all know how well that worked out.
Steve McConnell, author of Code Complete and recognized authority on software development, recently addressed this during a speech in Austin that I attended. He has found, as I have, that what does work for most enterprise projects is a hybrid approach, and he’s done the research to prove it. Business leaders must be able to plan, budget, and determine business value at the beginning of a project. A pure Agile practice can make that difficult because the planning elements (of the iron triangle) are too vaguely defined at that point. By adding a bit of Waterfall up front, with Agile for the rest of the project, the business gets what it needs when it needs it, and development can utilize the more efficient Agile methodology. A Waterfall-Agile hybrid.
There still needs to be a focus on quality during all phases of the software development life cycle. The tendency to skimp on QA during a Waterfall project has transferred right over to the practice of Agile on many projects. Bad habits like code-and-throw, a lack of unit testing, long release to QA cycles, and not having testers involved early enough are symptoms of this.
The “extra room” created by the flexibility and speed of Agile should be used to more tightly integrate testing into the practice. Otherwise, the real world pressures of the iron triangle will still surface.
As an industry, we need to include predictability and quality as equals to the classic iron triangle elements of requirements, cost, and schedule. None of these elements should be considered immutably fixed. We can do this without throwing out the best of either Waterfall or Agile. At Bridge360, we specialize in the practice of delivering quality software first, no matter what methodology our clients are using. We help our clients implement lightweight, lean methods of delivering the best quality software possible.
[i] Leffingwell, Dean (2010-12-27). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise