How to be Agile and Safe

Product development organizations throw around the word agile the way the Crimson Tide dismiss the majority of their college football opponents.  Sometimes, product organizations have purpose and definition regarding their agile approach, but more often than not, they are simply guessing and throwing out a term they hope makes them appear relevant. In the world of most apps and websites the most damage this seems to inflict is bad business execution and a poor product that may not deliver its desired value to the end user. This is not a desirable situation, but outside of distraught investors or founders inflicting damage upon themselves, it’s unlikely the poorly developed App killed anyone. For a long time it has been understood there is more at risk in developing electronic and software products for moving vehicles. However, the spotlight is on all the West Coast corporation darlings, so the model for successful business is not coming from sources that have grown up managing this type of product risk, or dealing with its consequences as regularly as the automotive industry. Unfortunately, the feeling is that the folks in Detroit should become more agile like the Silicon Valley App and Web companies. However, what that really means, and if it is a sufficient model, is only beginning to be resolved effectively.

The first challenge with becoming agile is to understand that there is a significant lack of focused definition of the term relative to its most popular usage today.  The only real definition, and appropriately recognized definition, comes from the nearly 20 year old Agile Manifesto. If you are professing agile methods and have not read this, well, you probably should take the 15 minutes it requires, and do it standing up. (and if you don’t get either of those references… you are more part of the problem than the solution).  If you’ve read it, you know there is not much prescriptive advice given from the manifesto, but there are some appropriate directions for setting priorities. These guidelines were utilized to help rate methods, approaches and tools as being more agile than traditional. If we look at aspects of one of the more popular agile methods, Scrum, we can see how its basic elements have been parlayed into many unofficial, and often ineffective, agile approaches and how some of the critical aspects of performing Scrum can provide a means to apply reliability and safety when required for automotive, and other, applications.

Scrum fundamentally provides a framework for executing a project by creating incremental product additions through relatively short developmental bursts. The bursts are referred to as Sprints, where the goal of the sprint is intended to add functionality to a product in such a way that the resulting product provides added value to the customer.  If that value add is to be safe, and reliable, there needs to be a focus upon that from the team performing the Sprint. There also needs to be measures related to these characteristics in order to gauge the success. Within Scrum there are some elements that can provide teams attempting to comply with Automotive SPICE and ISO 26262 the help needed to drive reliability and safety in a positive direction.

Definition of Ready (DoR): This is most effectively utilized by agile teams as a means to determine when the requirement (WHAT the customer wants) is sufficiently understood by the team to begin developing solutions to provide this new value to the user. This is certainly the place quality guidelines for reliability and safety can be addressed and analyzed with respect to this new requirement and feature.  Most critically it is important to understand if this new requirement is related to a safety goal and what we should understand about its potential failure modes and safe state(s). Furthermore, the means of determining if the system has correctly achieved a requirement should be clear, in ASPICE information that helps determine if a requirement has been met successfully is referred to as verification criteria. ASPICE verification criteria are analytical pieces of detail attached or associated to a requirement that enable a test to effectively validate that the system achieves the requirement. Adding these practical dimensions to a Definition of Ready highlights critical aspects that the development team needs to consider and resolve in order to successfully provide this new requirement.

Definition of Done (DoD): These are the agreed-upon conditions a successful implementation of the requirements must meet. Some effective agile teams determine this at the same time they are refining and analyzing the requirement(s), in fact, the existence of a properly formed DoD may be a piece needed to achieve the DoR. It is in the DoD where specific qualities of the implementation’s design can be enumerated. If the requirement is critical in achieving a safety goal, the DoD should clarify what demonstrable characteristics of the software design must be met to achieve done. How shall it fail safely and how can it detect failure and alert the occurrence of failure should be noted. The DoD can clarify the burden of proof placed upon the development team to insure the interfaces are implemented correctly, that the source has achieved necessary static rule compliance, or that unit test coverage is sufficient for the level of safety compliance required.  The DoD is a place where these considerations can enter your agile development naturally. However specifying the DoD is only part of the problem. It must also be suitably checked and enforced in a proper work product reviews. However, this is also more easily said than done.

The complex and often ignored realm of software design and analysis is an area largely outside the scope of most agile methods. Popular opinion has fallen so far to the side of valuing working software over comprehensive documentation that useful and effective software design techniques have become a skill and approach lost on most active developers. Developers who are too often hiding behind this point in the Agile Manifesto, their credo “the design is in the code” or “we design while we code” has caused reliability and safety to suffer from lack of legitimate consideration and review. Let it be noted that I have used the term developer in this description and not software engineer, frankly an educated software engineer should better understand the value of various forms of software representation and appreciate the challenge in limiting those views to strictly source code. After all, if it was easy to understand would it really be called code?

Trying to insure large embedded software systems are safe and reliable can’t be accomplished solely by analysis of tens of millions of lines of code. There needs to be effective and efficient guidance into the goal and purpose of the software and its subdivide pieces. This comes in many forms but none of them are the code itself, there needs to be structural descriptions and algorithmic purposes that guide the reviewers in understanding the intent of the code in order to judge the codes ability to meet it. In cases where large blocks of open source (OSS) are not understood by the team using it, the team must somehow safe guard the rest of the software from the OSS to insure the OSS cannot interfere with achieving safety goals of other pieces of the system.  Trying to build that confidence strictly from the code itself is burdensome, expensive and slow. Those are certainly terms that most agile evangelists would NOT use.

There are many descriptive tools that may be employed to help describe and understand these increasingly complex automotive computing systems. The goal of these tools is to help a team prove to themselves, and others, that the system is reliable and safe. Various UML-based modelling tools, or mathematical modelling and simulation tools.  Proof checkers and verifiers that are employed on semiconductor design can also be applied to software state-machine.  However, you would be hard pressed to find these tools described in an article or book about Agile methods. There are many Agile frameworks which provide effective project management, however there are necessary additions for creating safe and reliable products and software. See Kugler Maag’s Agile in Automotive site for more guidance.