In my last article, we explained why some companies who may not have fully invested in the DevOps part of their Agile journey struggle to realize the benefits of Agile. Today, we will see how Software Intelligence can help.
Agile usually sells better business outcomes to a group of stakeholders who desire that and can understand it. Software developers, business people and customers. DevOps, on the other hand, promises to support the same, but involves layers of complexity that non-technical stakeholders find difficult to comprehend. A discussion on non-branching code management, continuous integration, automated open source library scanning, software-defined networking through storage and compute environments as code…it all seems a long way from a better mobile app for customers, but it’s all needed if you want your software value chain to work.
There is also often resistance from the production side of technology teams, who were created to protect production quality. The very separateness of development and production teams, and many ITIL processes, were created as controls. We have lived with these practices for decades, and they are still widely used today. Production instrumentation and its feedback loop into software teams is now critical as we combine services to create customer experiences in loosely coupled architectures that are the opposite of the single vertical applications many companies are built upon and those separate teams and ITIL practices were designed for. Getting production teams to see not only faster software delivery to production but safer delivery and operation of production is the key to success here.
Many code scanning and dev support tools take a purely developer centric approach and allow a high degree of customization from team to team. Their flexibility is their attraction. But with one production environment facing multiple software teams, how can we have confidence that these tools have helped create software that will work when its all operating together? Further, if these tools are not addressing complex software security rules or tech debt measures, will this not just make future change much more risky and costly? Beyond production operation, these are enterprise-level questions that software quality and governance groups exist to manage.
Software Intelligence offers a solution to this trust deficit. Intrinsic to Software Intelligence is the use of standard measures across teams. These can measure technical debt in code design, software security flaws, use of approved libraries and standard input-transform-output function points among many other aspects of the code being built. Integrating this intelligence into the Agile/DevOps chain is critical. While some software development purists can see this is unnecessarily strict, I believe it’s a necessary friction in the system to meet all stakeholders needs.
For the CFO, Agile teams can now definitively show greater function points delivered from the same investment over time. Rather than compare teams by scores, which is not very helpful, teams can set a threshold of a minimum metrics score in each category of measurement, as well as a combined score. Production and governance bodies can monitor the relationships between metrics and production incidents, look at trends in teams if there is staff turnover, set improvement targets over time, and demonstrate security scores to a board of directors that show the company is getting safer and lowering their software risk exposure. These are the sorts of measures and metrics - boring though it sounds - that can bring people along on the Agile plus DevOps investment journey because they can see tangible metrics that show improvement not just in speed, but in function delivery, quality and security.
If your Agile practice is struggling to gain support from parts of IT, the corporate center or businesses, it’s worth taking a serious look at how Software Intelligence can give your practices a solid metrics footing to deal with these real-world challenges.