My reasoning then was that 10 is an age where we begin to expect more out of people and things – a greater maturity. I also sided with the author of the original book on Scrum, Mike Beedle, who said, “We need to raise the quality of Agile implementations and we also need to document the state of the art as it is today, to make it easier for practitioners to envision the future.”
Nevertheless, some who read my blog back in May came to Agile’s defense, questioning how I could equate Agile process with poor quality software. They seemed to think I’d been too hard on the adolescent technology and that I should be more supportive of what it offers to the IT departments of businesses today.
But this is where they were wrong. I do support the tenet of what Agile tries to accomplish, but that doesn’t mean I cannot also expect more out of it.
Why shouldn’t I expect more out of Agile? Although some may say Agile is only 10, I have to agree with Laurent Bossavit, who recently questioned in an article on InfoQ whether it was time for Agile to take stock of itself, noting, “The field of computing is still young enough that ten years are a significant time for anything to have been kicking around.”
Agile should be the perfect way to build and customize software because it is the embodiment of the first rule of management in any form of business – delegate according to the strengths of your people. As is the case with any delegation of duties, though, if you do not provide your people with the proper environment to accomplish a task satisfactorily, the project will most certainly get done unsatisfactorily.
This is the problem with too many Agile efforts. A project is split into scrums with the intent of software being built or customized through a “best of breed” approach. Scrum-developed pieces are then brought together and a single, cohesive product is supposed to result.
It should be just that easy, but too often those overseeing or funding the project push so hard for speed first that they foist a “just get it done” mentality upon the scrums…and as a result, speed kills--with quality being the first victim.
Given the time and the tools, scrums would more than likely perform adequate application assessment, rendering their pieces of the project structurally sound. However, because structural quality is at the root of visible behavior, it can be difficult to detect and monitor in the rush and tumble of development or rapid enhancement.
Even when structural quality drifts downward in small steps, it can quickly accumulate and drive down an application’s reliability. It’s not that scrum members lack the knowledge, but rather the demands placed upon them deny them the time to ferret out this information.
Business applications contain thousands of classes, modules, batch programs and database objects that need to work flawlessly together in the production environment. Automated structural quality measurement is the only feasible way to get a handle on this structural quality drift.
Lest anyone think that applying automated structural quality management to the process would slow things down, I submit just the opposite. Agile development without reliable structural quality measurements is like flying in a fog without your instruments. You can do it, but why risk ruining your hard work?
Measuring structural quality at the end of each iteration makes you more agile by preventing the accumulation of technical debt. After all, there is speed in diligence because doing something once is always faster than doing it twice.
So as good as Agile is, it can be even better if those in charge would allow those using it to perform automated application assessment to ensure structural quality…and then all a 10-and-a-half year Agile would have to worry about is dreaded teenage acne.