Software development is a complex process, especially at scale. Different needs drive a desire to govern the process:
Internally the organisation wants to verify that what is being built will meet its needs and deliver a reliable service
Externally the organisation needs to satisfy regulatory requirements and protect itself from bad actors
All of this can be considered ensuring the safety of the software delivery process. The areas of the organisation responsible for ensuring this safety are security, architecture, risk management, etc. In many organisations these teams sit outside of the delivery process, operate in silos, and struggle to adapt to the accelerating speed of software development.
One effective way to help solve this problem is to create alignment between those silos and the value streams associated with the software under development.
Where to begin
Start small, and build incrementally.
Begin by identifying a couple of teams that are focused on accelerating their software development practices. Once identified, consider which safety area you want to focus on first, this will form your safety team of one, your Minimum Viable Safety Team (MVST).
For example, you identify a team in your digital space building a new web portal. They have adopted a number of DevOps practices and tools. When talking with their product owner, architecture review is a pain point. Regular cadence is required but what is needed is unclear. On the safety side, you approach enterprise architecture to find an architect that can be aligned to this initial team.
Next we need a mechanism for the delivery team and the MVST to interact. Creating a catalogue of risk stories that can be fed into the team’s backlog provides clarity and a tracking mechanism to satisfy those external stakeholders.
For example, the MVST architect creates a story for the team with requirements for updating their architecture documentation on the team’s wiki.
The MVST meets with the team on a regular basis to determine when it is best to insert a new risk story into the pipeline.
For example, there is an upcoming release of the portal that will change several service interfaces to the backend. The MVST consults with the product owner and determines now would be a good time to insert a story to update the architecture documentation.
At any time:
Either the MVST can decide to notify the team if they feel they haven’t spoken recently enough and have concerns.
The team can call on the MVST as they have a concern with upcoming changes and want some guidance.
Tracking this interaction and ensuring the relationship is beneficial to both parties is critical to maintaining a healthy safety culture.
Conclusion
From here, grow the MVST to include other safety areas and expand to other value streams. Watch carefully in this early period to ensure practices are growing smoothly. If you want to find out more, chapter 6 of Sooner Safer Happier goes into the concepts discussed above in more detail, talking about Safety Teams as a core component of Lean Control.
by Peter Maddison, 11/10/22