To be more competitive, efficient and fast-to-market, organisations have been introducing Agile into software development processes within the past decade. At the same time, organisations under pressure to meet legislations and industry standards have struggled with introducing agile processes. I often meet people that believe that it is not feasible to introduce Agile into environments that are compliance-driven. That perception is changing rapidly — even among more traditional, risk-averse enterprises — particularly with the evolution of Agile with more mature ‘hybrid agile’ methods.
Today, organisations have far more choice when it comes to packaged frameworks, so they can get started with the agile option that best fits their needs. For instance, the Scaled Agile Framework (SaFe), Disciplined Agile Delivery, Large-Scale Scrum (LeSS), and large-scale Kanban can help address some of the particular challenges of large-scale, complex development projects.
In compliance-centric markets, adaptations are often done to readymade frameworks to create a hybrid. In fact, a framework such as SAFe is very much a hybrid method, which is one of the reasons it has received so much criticism from the Agile community. But these frameworks and hybridisations help balance the fast flexibility at the core of the original ‘Agile Manifesto’ while offering the control and structure they require to be able to offer their product on the market in the first place; agile processes are being adapted to its context.
Gartner’s top 10 infrastructure and operations trends for 2020
Here is an example: A manufacturer of a product with both hardware and software is building a new generation of one of their products. One part of the value in this product is that it complies to certain standards and regulations as demanded by their customers. These are standards the manufacturer has always complied with, and it is a well-known process to comply with them. Creating a plan for this contains few unknowns, and they can, with a high degree of certainty, build, for example, a Gantt schedule to plan for resource needs and the timeline (a practice most often associated with “waterfall” ways of planning).
On the other hand, the next generation of this product also introduces new technologies with many unknowns and knowledge gaps. An agile approach iterating and quickly validating a hypothesis of what will be the value added is a much more suitable way of planning. Also, there are parts of the R&D cycle (for example, a verification or integration team) that have very variable inputs from the rest of the organisation – and they will benefit from a flow-based way of planning, such as Kanban. In that scenario, the manufacturer gets the best of two worlds: the formal structure and control of a traditional methodology such as Waterfall, together with the ability to respond to unknown factors, thanks to Agile.
Execution is everything
Choosing the flavour of Agile best suited to an enterprise is just the starting point: what is more important is execution. So what contributes towards successful Agile, and conversely, what can go wrong?
Unifying open standards and open source with agile technology
Agile is very much tied to culture, and this is why roadblocks and change resistance occur in more or less every agile transformation. A typical scenario is initial success at team-level with Agile, followed by difficulties experienced in deploying it further, because not everyone in other teams or functions understands or embraces the Agile mindset. Furthermore, management may dismiss Agile the first time a problem is encountered.
Sustainable Agile success involves dedication and hard work and an understanding that it will evolve, requiring continuous retrospection and improvement. It makes sense to start with areas where success can be most easily achieved, to demonstrate its value and encourage participants’ support.
In a hybrid Agile environment, test-driven development is a good candidate for this, with testing taking place automatically during development, and re-tested rapidly as required. Taking a ‘Shift Left’ approach to testing introduces Agile without disrupting traditional higher-level planning, and it can act as statement and proof of value these practices can bring. The sum of all these improvements will help reduce the friction from change resistance and roadblocks.
Traceability
Compliance and standards-driven environments are typically document-heavy, whether for internal or external purposes. While it is true that agile processes encourage less documentation where other forms of communication are more efficient, Agile is also very much about transparency and visualisations. It is about planning and tracking based on real progress and data, and this is where traceability becomes so important in agile organisations.
It starts with a solid traceability strategy, and just like Agile has borrowed much from lean production methods for productivity, the same is true for traceability. Often, very basic improvements, such as proper version control and reviews in a single source of truth, reduces the waste in the compliance part of the development significantly. Being able to trace and visualise impact of changes both up- and downstream in a process will make any organisation more agile. Creating a traceability matrix to visualise this is one great tool, which connects user stories, tests and issues, making it simpler to analyse impact.
Overcoming the data visualisation barrier and addressing the decline in AI
Another undervalued tool is to use a product backlog to drive traceability on the higher-level selling points of a product. By properly structuring a product backlog around the goals of the product and across both hardware and software, fixed versus variable needs, etc., business priorities and product management is significantly easier to manage. The product backlog becomes the aligner; the driving and living artefact that ensures that no matter how each delivery is planned and tracked depending on what suits best, there is still something holding it all together.
These are some of the techniques we have seen work in practice, but no two situations are going to be the same. While it makes sense to learn from peers, it is better to adopt the elements of Agile best suited to each project or organisation, rather than rigidly follow an agile prescription. Applied correctly, Agile brings multiple benefits, even in some of the most regulated or traditional markets.
