The new world of DevOps is transforming how software is developed, not just in terms of the technologies and tools used, but more importantly in terms of how teams are organised and managed.
Fundamentally the goal of this transformation is to speed digital innovation - to accelerate the development and deployment of new software features that create value for users. For large organisations, a number of factors can impede and slow this cycle.
The 2i AssureRMF service helps organisations understand the 'value chain' of the software production process, identifying and addressing these constraints so that faster deployment patterns are achieved, and business value delivered quicker.
Shifting Left and Right
The key dynamic is the leap from thinking about testing as a sequence step in a process, typically the last step before deployment, to it being a discipline embedded throughout the full life-cycle of software development and indeed even once in production.
Traditional approaches place testing at the end of the 'production line'; an isolated team whose only function is testing, who receive the code from developers once complete. They perform their task and if successful then pass it over to the infrastructure team for deployment, if not they return it and generate defect reports. The essence of Agile development is that instead testing is baked into the development itself, it's a skill rather than a process step. It's performed during the development and by developers.
This is referred to as the trend of "shifting left", ie. conducting testing much earlier in the software life-cycle, and now in the Cloud Native era also complemented by "shifting right", extending test practices across production environments as well. For example, Netflix operates a massive global Cloud infrastructure, and continually tests its viability, such as shutting down entire regions to ensure it can recover autonomously.
In his DevOps.com article, Shamim Ahmed describes this as 'TestOps', explaining the practices used by Netflix such as release validation, chaos, canary and CX testing, and production monitoring. He makes the key points that goals such as CX (Customer Experience) testing are hard and slow to meaningfully achieve early in the cycle and so are best performed in live environments. By shifting them right organisations are able to deploy at faster rates.
Building a Digital Software Factory
As we consider the dynamics of also shifting left, we can consider the principle is slightly misleading. The more accurate ideal is one of taking a whole systems perspective, seeing and optimising the entire 'idea to deployment' life-cycle, given the core goal is one of reducing time to market for new digital services.
2i unites expertise from multiple domains to support this re-engineering, such as SAFe (Scaled Agile Framework), Lean and the Theory of Constraints.
The concept of a 'software factory' is a very powerful metaphor because much of the insights are drawn literally from the world of manufacturing, where over many decades they have perfected the science of optimising the efficiency of a production line. The core insight is one of realising that the overall throughput capacity of the whole line is defined by the capacity of the narrowest point. If the front and end stations can produce 100 units per hour, but the middle only 5 units, then the capacity of the whole line will only be 5 units per hour.
All business processes including software development are progressed through their equivalent production lines, with work handed off from one department to another, such as from development to testing, managed by decision points such as approval stage gates. Each of these represents an assembly line station and the whole process the factory, and it can experience similar capacity bottleneck points and thus the same science can be applied to achieve the same performance improvements.
For example, a key challenge that these practices identified is one of 'local optimisations', focusing on improving the efficiency of individual stations not the whole chain. Software teams might adopt the latest DevOps and Cloud services, reducing the time to spin up new test environments from weeks to days, but still find it takes months to finally deploy new releases. Somewhere else in the life-cycle is a constraint causing months of delay.
Large enterprises have to deal with multiple layers of complexity that can hide these constraints. They may have multiple different development teams, with multiple different development tools in use. They might have variables such as outsourcing testing to a third party supplier, a relationship that has strict rules for how the work is passed across and critically, how contract performance is measured, therefore dictating behaviours that can be the cause of bottlenecks.
Testing = Quality
Embedding testing earlier in the development cycle can be seen as applying the factory line principles of Total Quality Management, such that these individual components can be evaluated and enhanced within a context of whole system improvement.
For example, for one 2i client we found that the testing team operated in a standalone silo, and the hand off to them was a major bottleneck and source of quality errors. This wasn't because of capacity limitations, but rather being entirely remote from the development process meant they were having to understand the code being passed to them from scratch and without context, and were actually generating defect reports as a means of seeking this understanding. It was a workflow step of poor quality.
By involving them and embedding testing much earlier in the development process they were able to improve the quality of the hand over, greatly reducing the number of defect reports generated, smoothing and increasing the overall throughput rate of new releases. They shifted left to improve quality earlier and consequently increased capacity.
As Wolfgang Platz writes on DevOps.com research identified that organisations that embrace this shifting left and total quality approach to DevOps, and embed and automate Continuous Testing practices across their software life-cycle outperform their peers to the extent it defines the difference between DevOps laggards and leaders.
The primary differentiator was that understanding of business risk is the most important determining factor of DevOps maturity.
IT leaders reported that testing was still by far the biggest cause of delays in the development process, but much of it is still performed manually and adds little value to the software life-cycle. Instead experts focus primarily on contextual metrics (e.g. requirements coverage) while others focus on “counting” metrics (e.g. number of tests), and are more likely to measure the user experience across an end-to-end transaction while others rely on application-specific or team-specific metrics.
AssureRMF
The 2i AssureRMF service is an engagement specifically intended to address this requirement to identify business risk and optimise the software development process around principles of better quality management, enabling our clients to emulate the practices adopted by DevOps leaders.
We conduct an assessment to identify exactly where your quality challenges are and identify where your real delivery risk sits, develop a plan for implementing improvement initiatives across your delivery model, focusing on key milestones, success factors, people & skills, governance, controls and procedures, and automate inefficient and repetitive processes and implement test practices that best deliver to your quality objectives and risk appetite.
We ensure that continuous learning and improvement culture is embedded across all teams, including formalised training plans. We also equip your employees with the skills and capability to implement automation solutions across your enterprise.
