Recently I had the opportunity to lead an assessment of Business Excellence at one of the Navaratna units.
This unit [and also others in the same organization] had started adoption of the DuPont model for safety.
As I interacted with different participants in this initiative, was struck by many similarities or principles applicable to successful Agile teams and organizations.
First, a little background on the DuPont model:
Safety has been a focus for DuPont from the beginning. In the words of E.I. DuPont:
Safety is a line management responsibility.
If we can’t do it safely, we won’t do it at all.
E.I. DuPont
This emphasis on safety evolved over time to become the defacto model for many organizations – in the manufacturing segment – across the world.
The Process Safety Management model is represented as below.
Picture copyright and credit – DuPont / https://www.researchgate.net/figure/Personal-and-Process-Safety-Pyramid_fig3_338175133
The model emphasizes the comfort feel for an individual to work confidently under safe conditions as a pre-requisite, in addition to independent inspections and assertion of the safety conditions. The emphasis is both on planning upfront and identifying potentially unsafe conditions of the workplace as well as the individual worker’s perception of safety.
Working at a height, for example, may not be comfortable for certain individuals, who may have a fear of heights. Similarly, working in confined spaces, in very hot areas etc also require additional assessment, planning and care.
Adequate, just in time training, use of personal protective equipment and team protocols for interventions, in case something does not go as planned are also defined by the teams.
How can we apply these in the context of software delivery?
Whether it is a new development or implementing an enhancement or defect resolution, the success of the activity would be influenced by the skill, experience, and confidence of the person who would work on that portion as well as the inherent stability [safety] of that portion of the code.
In order to do this, the practice of ‘Job Safety Analysis’ can be considered in our context.
The first step is to be clear about what needs to be done:
The ‘Definition of DONE’ is a good place to start. The DoD will be the activities that need to be completed to ensure that all aspects needed are addressed. This could include not only adherence to coding standards etc but also the associated documentation updates, unit tests to be passed and so on.
I have come across a situation when a team member, who wanted a job rotation was given an opportunity to be a developer for a release, having spent some time with the team as a QA person. While there was enthusiasm, this person had a lot of hesitation in touching any code, for fear that it might end up breaking the code. Having seen some such instances as a QA person, these fears overpowered the desire to code!
In this case, the option was to pair the individual with a senior person who could be the mentor. That, in effect, is like the safety harness for a person working at a height, for example.
In addition to addressing the confidence of the individual, the team should also consider some safety nets – for failsafe execution of code. Routines and architectural patterns to prevent mistakes or catch error conditions and gracefully recover from failures would help.
Analyzing the structural code quality [static code analysis tools] and tagging portions are potentially unstable could result in adding some additional points in the Definition of Ready before work on those portions are taken up.
This may include a review of the proposed solution by a tech lead or architect, before implementation.
While these are not new to successful agile teams, the inhibitors for adopting such practices are more cultural.
Let us look at the cultural aspects in the adoption of the DuPont safety model.
There are 11 aspects that are related to operational excellence. Of these all, except for the PSRM resources are also characteristics of high performing Agile teams.
Agile teams demonstrate intense involvement and ownership by the team members. Teams do not take any shortcuts to achieving their goals. Certain aspects that are non-negotiable are found in team norms as well as definitions or ready or done, as mentioned earlier.
A few other aspects may need some interpretation in the software development. While the treatment of each of these aspects is beyond the scope of this post, here is a quick summary of a few:
- Organizational pride: Pride of ownership on the outcomes by the team
- Excellent Housekeeping: maintaining sufficient traces in terms of metrics that are used by the teams for continual improvements
- Shared values: a common goal for the team, with each for all and all for each!
- Active communications: within the team as well as with all stakeholders
Since these are typical strong characteristics shown by Agile teams, it is only a matter of the application of proactive safety practices to ensure good code in production.
If you have found any other approaches or models that have helped your teams to delivery bullet-proof code, do share for the benefit of the community.
