As you may know from my bio here, I’m a big fan of Boston sports. So you can understand how thrilled I was a few weeks ago when “my” Boston Bruins won the Stanley Cup for the first time since I was my daughter’s age!
It wasn’t easy for them, though. Through the first round of the playoffs, they looked like they could be a “one-and-done” team and everybody – including some alleged diehard fans – were already calling for the dismissal of their head coach because of their anemic performance. Nevertheless, they made the necessary adjustments, got some stellar work out of key individuals, overcame a few adversities and in the end proved to be the best team in the National Hockey League this year.
What does this have to do with technology? Plenty!
Those who read this blog regularly may have taken note of me taking agile development to task on more than one occasion. Some might think this is because I have no use for it or because it is flawed beyond repair. I’m here to say nothing could be further from the truth and come here today to defend it against a recent attack against it.
I do believe that agile development, because of its Scrum-based project management, is an important and useful environment for customizing and creating application software either for internal use or for market.
So I was a bit surprised by a recent blog by Stephen Cohen on the Microsoft Developers Network, which suggested that the gild is off the lily for agile or, as Cohen asks, “Has Agile jumped the shark?” – a reference to the episode of the 1970’s sitcom, “Happy Days,” where one of its main characters, “The Fonz,” (played by Henry Winkler) attempted to jump a shark cage on water skis. (Stephen, I, too, remember that episode of “Happy Days”).
It has been said that the “shark” episode of “Happy Days” was the beginning of the show’s demise and the moniker “jumped the shark” has now been applied to television shows that stop being fresh or run out of new ideas.
But has agile development jumped the shark? I’d say far from it. There are few, if any methodologies out there today that are as equipped to handle the fast-paced demands of software development. Breaking a large project down into smaller parts has always been a good tenet of business, so it stands to reason it should work with agile as well.
Am I saying agile is perfect? Of course not. After all, agile development is carried out by humans, who by nature are imperfect. Anytime something is created and run by humans it may need “tweaking” before it can reach its full potential. Even the U.S. Constitution, one of the most important documents in world history for its establishment of rights and freedoms for individuals, had to be amended 10 times – the Bill of Rights – before the then-13 states would ratify it. And although it has been amended 17 times beyond the Bill of Rights, some would say it is still imperfect.
Agile may not be on par with the U.S. Constitution in world history, nor will those who undertake its practice ever play hockey as well as the Bruins, but in the software development space it is revolutionary, visionary and an important part of how many companies are now able to speed application software to market.
Like so much of humanity, agile is part beauty and part beast. The beautiful part is that after each iteration in an agile process the result is something that works, and in software development, that’s important. What can be beastly, or more accurately, what can be irksome about it is the structural quality.
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.
So as good as agile is, it can be even better if those using it would take the time and focus on structural quality through automated analysis. In doing so, the quality would improve, the time it takes to reach optimal quality application software decreases – through the elimination of maintenance and technical debt – and agile development never dons the water skis to jump the shark.
In fact, rather than jumping the shark, with the application of automated analysis and measurement, agile could be the shark!