Agile software development is a streamlined, transparent process with speed built into each step. It’s so focused on speed, in fact, that developers call what they can successfully accomplish in a two week sprint their ‘velocity.’ But while Agile development teams do incorporate unit tests and the testing of functional aspects of their code, there is often little analysis of the structural quality above the module level. This is something that makes most architects in enterprise software organizations nervous about Agile.
Agile developers dismiss structural quality checks because they assume it will cause unnecessary roadblocks causing them to miss crucial deadlines, and slow their lauded velocity rate.
But with careful planning, automation, and support of structural software measurement in pre-production, Agile teams can produce applications at the same speed they were -- if not faster -- and build them with a higher degree of structural resiliency. This ensures their velocity rate stays intact, but also improves the quality of the final product.
I ran into a customer who insisted that his teams didn’t need measurement. He said they just needed a pat on the back and a few free lunches to keep morale high. Well good luck with that, because morale is going to be scraping the floor when they’re doing an extra weekend of production support because the code broke.
Planning is crucial when an organization first starts to incorporate software measurement, because there’s no such thing as a one-size-fits-all approach. Each organization will need to assess exactly how it develops software and adopt proper measurement techniques accordingly. For instance, you wouldn’t want to do a structural quality assessment every time a developer finishes their day’s coding. That would require collecting all the code that had been updated that day and running it together -- a costly and time-consuming process. Rather, simple static code analysis checks can be automated daily to catch smaller bugs while the deeper dive -- the structural analysis -- can be done before it goes through the testing cycle.
There is also a fear among Agile teams that the real reason they’re being measured is because management wants to evaluate their performance. They think they’re inviting Big Brother into their team. But in actuality, they’re not.
Measurement isn’t there to get anyone in trouble. It’s to help teams improve and grow while still bringing transparency and visibility to the table. Don’t think of measurement as the stick, it’s the carrot. It’s here to compliment Agile, like adding fresh oil to a supercar’s engine every 3,000 miles. And it keeps the development team out of harm’s way, because if a new update takes down the e-commerce portion of your website for a few hours, the development team is going to be the one in the hot seat. Proactive measurement can prevent those kinds of errors from occurring.
Agile development teams need to realize that software measurement is the natural evolution of their sprint processes. Code checks aren’t roadblocks, but rather stepping stones that have been perfectly aligned to how Agile teams develop software. You’re not stopping and waiting around at a time when you shouldn’t be. You’re stopping at the appropriate time to fix the issue before accruing any more technical debt and, at the end of the day, creating more value for your organization.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.