Happy Birthday to Agile Development! You’re 10 years old now; that’s an important age. A lot of things start happening at age 10. The pre-teen years start and things will seem to get awkward. Most important, a lot more will be expected of you.
This is probably why Mike Beedle, the author of the first book on Scrum, recently wrote as part of the Agile 10th Anniversary Manifesto series published on InfoQ, “We need to worry about how diluted the meaning of agile is becoming, and focus on real quality.”
Sounds like a call for “better behavior” – a typical expectation for any 10-year-old. It makes sense when you consider Beedle’s assessment of how Agile is used in businesses, noting that most businesses don’t fully understand it and pay it “lip service.”
So Beedle does his best to spell out just what agile needs to do to “grow up” now that it has turned 10:
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.
In regards to quality, at the 10-year Agile Manifesto Workshop (see this link) we came out with four statements that we thought were possible to implement:
- demand technical excellence,
- promote culture change,
- maximize business value,
- organize knowledge.
These four statements convey a powerful, relevant and accurate mission as to what Agile as defined 10 years ago needs to do to survive with a clean name. Otherwise it runs the real risk of getting diluted, badmouthed, and thus enlarge the backlash it already has with every Agile implementation gone bad.
What Agile as defined 10 years ago needs is an action plan to put these four statements to work in [organizations] today.
I’m not a fan of “action plans” myself – they’re usually far more plan than action. Nevertheless, there does need to be a plan put in place to improve the quality of Agile development. Like with many adolescents, the first actions in that plan need to be acceptance of its own shortcomings and learning how to deal with them.
Software developed through Agile, or in any Scrum-based process, relies upon pieces of application software to be developed by disparate teams that could have very different ways of doing things. This is not the ideal situation for a top-quality result on the first pass of software. As I noted in a previous blog, bits and pieces of functionality that will eventually become interdependent are created and tested separately in different scrums. New functionality is often added on top of old, which further muddies the architectural waters, threatens reliability and performance, and increases the cost to modify and maintain the software. Moreover, as the number of lines of code grows, architectural complexity grows exponentially.
At this point, performance bottlenecks and structural quality lapses become very hard to detect. This makes it very difficult to see and measure the structural quality – a measure of how the architecture and the implementation hang together to ensure reliable, dependable, mission-critical performance – of the application as a whole. Being able to find and fix critical architectural bottlenecks in a rapidly evolving code base reliably is the key to developing high-quality applications using Agile techniques.
Unfortunately, even the most qualified software engineer does not have the requisite insight into the thousands of classes, modules, batch programs, and database objects that need to work flawlessly together in the production environment. Most issues of robustness and performance are not hidden behind one specific artifact of code but exist in the interaction between multiple components created in separate scrums.
Like so many human adolescents, Agile needs a mentor; a software platform that keeps its efforts on the straight and narrow while it is undertaking its daily routines, rather than waiting until after major flaws are discovered.
For Agile, this can be accomplished by introducing a system of automated analysis and measurement, which provides comprehensive visibility over component interconnections and assesses the structural quality of the application software as a whole, rather than each part individually. This is important because even if each Scrum develops a perfect portion of the project, the entire project is doomed if these modules do not interconnect properly. Together, visibility and quantification give software engineers the information they need to ensure high performance and reliability, no matter how rapidly the code base evolves.
Moreover, automated analysis and measurement does what the human eye cannot do. It can read, analyze, and semantically understand most kinds of source code, including scripting and interface languages, 3GLs, 4GLs, Web, and mainframe technologies, across all layers of an application. This static analysis measures quality and adherence to architectural and coding standards, while providing real-time system blueprints.
By providing such insightful guidance, automated analysis and measurement could certainly help Agile through its awkward adolescent years and help ensure that it grows up to be a quality process.