The benefits of the Agile methodology – not least of which is faster-time-to-market – are well-documented, but transitioning to Agile can be a challenge for embedded software teams in compliance-driven markets, such as automotive, aerospace and medical devices. Traceability and documentation are needed to demonstrate compliance, but this can feel contradictory to the spirit of Agile, which still suffers from inaccurate myths that have grown up alongside the methodology. In fact, Agile and compliance can comfortably co-exist, without too much compromise, as long as the right approaches and tooling strategies are adopted. Of fundamental importance is traceability, which in this context, means linking requirements to tests run and issues resolved. With solid traceability, you can not only provide the evidence needed to satisfy audit requirements, but also support better transparency and tracking across teams, which also helps collaboration.

A good starting point is defining what we mean by Agile development, because the term, while well-known, is often misunderstood. On the simplest level, Agile is a loose methodology based on a focus on customer needs, cross-functional team collaboration and responding to change (as opposed to rigidly following a documented plan and timeline). A number of development methodologies, including some more recent hybrids, sit under the Agile umbrella, including: Scrum, Kanban, Scrumban, Kanplan and the Scaled Agile Framework (SAFe).

Agile Myths

Regardless of which flavour of Agile, there are some common misconceptions, for instance, that Agile lacks structure or control, or that there needs to be a trade-off on quality. Neither of these two myths are true: structure, control and quality assurance can all be built into Agile processes.

Another false perception is that Agile does not work in regulated industries. Yet Perforce’s own 2018 survey of the medical device development market – surely one of the most regulated markets of all –found that over a third of the respondents had moved to Agile by that point. Anecdotally, we hear increasingly from companies in heavily regulated environments that they have – or are about to – embrace Agile.

So what’s working for these companies? It’s a matter of how teams execute on Agile frameworks and regardless of what kind of Agile approach they use, traceability is the key. With solid traceability, organizations can deliver using nearly any process they wish.

Traceability

Traceability helps answer the question, “If something changes, what else will be affected?” Importantly, traceability can be defined in terms of backward and forward traceability. Backward traceability is checking that what was designed or built is justified by an upstream requirement. Forwards traceability is checking that what is needed is addressed in later lifecycle stages.

Here’s an example. In Agile development, particularly Scrum, work items are broken down into smaller pieces and completed during a fixed timeframe, called a sprint or iteration. This means that managers must ensure that each work item (and its smaller pieces) has the appropriate test coverage. This kind of traceability requires a clearly defined structure from the project’s outset between ‘parent’ and ‘child’ items – in other words, the relationship and impact of different elements. The end result of such work — completed diligently and at all stages of development — is a trace matrix that allows organizations to understand what requirements, tests and issues are connected. Such a trace matrix provides a simple way to conduct both forwards and backwards impact analysis and, ultimately, provides ready accountability. With this structure and data, decision-makers can understand the impact of changes before they happen and manage and mitigate risks—regardless of the delivery method(s) or processes used.  While once upon a time traceability matrices were created manually – for instance, in Excel spreadsheets – these manual methods are not a good fit for today’s complex software environments. As a result, more organizations are automating the process using their ALM tools.

People Need Tools

Agile is fundamentally about people but, given that tools play an important supporting role, it is essential to make sure that traceability is not hindered by tooling complexity. For example, if requirements are stored in Word documents, issues are tracked in Atlassian’s Jira, and code is stored in Git or other systems such as SVN or Microsoft TFS, tracking and tracing are fragmented and therefore risks increase. Similarly, if these teams are implementing different project management methods, each with different standards, processes, or controls, such traceability can be difficult to achieve.

Proper tooling can remove or at least reduce the barriers to entry for embedded developers wanting to achieve some degree of agility without increasing risk. For instance, application lifecycle management (ALM) tools can integrate with Atlassian’s JIRA to provide end-to-end traceability, test and requirements management, while also providing the data needed for compliance reports and audits.

Transitioning to Agile – Best Practices

First up is the need for executive buy-in. Like any other major organizational initiative, Agile will not make it through the inevitable pushback and hurdles without full support at the C-level.

Second, Agile is best begun at the team level. By localizing mis-steps, organizations can both lower risk and make success more attainable. Lessons learned at the team level can be scaled to the department level and then, if applicable, be applied organization-wide.

Third, teams that are part of the transition must have a clear process and shared nomenclature. For example, are requirements written as user stories or will a mix of both be used? Are estimates to be measured in days, hours, or story points? Will roles need to be redefined, for example, do business analysts need to be trained as Scrum Masters? These questions (and many more) should be addressed and resolved early on, so that executives, managers, and teams are speaking the same language and therefore able to adequately communicate during what can be a time of disorientation.

There are, of course, infinite other considerations to be made, many of which cannot be planned, so can only be addressed as they arise. While it has become something of a cliché, there must be an understanding that the only constant is change.

All this has to happen in the context of regulation and compliance which, in many industries, continues to evolve. What the future brings for these organizations is hard to predict, but compliance is an increasing part of daily business life, whether ensuring the safety of cars on the road, the equipment assisting with patient care, or making the IoT a more reliable and secure environment in which to operate. Simultaneously, the speed and flexibility that methodologies such as Agile – whether it is formally labelled that or not — are being proactively used by organizations of all kinds to create a competitive edge. In a world where agility needs to co-exist with compliance, it is good to know that it is most definitely possible, as long as it is addressed with the right culture, tools and processes, all underpinned by traceability.