The Evolution of Governance: SDLC

I recently had the pleasure of speaking with Derek Kannenberg, Head of Technical Strategy and Execution at London Stock Exchange Group.

We covered a lot of ground, and found ourselves lingering on topic of Governance. We left the conversation at the point of exploring the evolution of Governance at both the PMO or Program level, and --at the work product or SDLC level. That afternoon, I thought back through what I'd seen over twenty-five years in holding various governance positions across industries from Steel Manufacturing to Aerospace and Defense, from Luxury Retail to Hedge Fund Management.

First. I’ve seen some things. I'm an alumni of software development-led program management offices in organizations with proximity to The White House who host foreign delegations in secure offices miles below the ground. I've led governance in organizations where code controls $26B in assets under management, and performed Sprint planning for organizations where the app being developed processes 50% of the world’s economic transactions. 

I’ve worked with some of the brightest engineering minds in the world, and it’s from them that I learned today's Software Development Life Cycle (SDLC) doesn't begin and end with simply delivering usable software. The continuously evolving development landscape now also has to consider things like: DevOps, Agile at Scale (SAFe), Containerization, Virtual Environments, Cybersecurity and top-down global corporate shifts, mergers and digital transformations.

A mature SDLC governance process, rooted in a community of best practice, not only improves the quality of software being delivered ---but shortens the "time to market", lowers development costs and eliminates avoidable re-work due to stale technical debt or common critical errors. These improvements all become incredibly valuable metrics for development cycles designed to be built for continuously releasing new code. 

One thing that has kept some organizations from implementing real governance practices, is effectively managing the level of change it requires. Organizations have to invest time--aggressively--into continuously tracking and assessing the entire ecosystem for where there may be long running technical debt, obvious integration issues, low quality user experience and upstream process improvements. It requires, that once these teams identify the issues--they actually execute and solve them. Fully. Completely.

Lastly, the strongest practitioners of good SDLC governance document their processes. All of them.

Best-practice-driven software delivery governance can result in a large amount of due diligence work. This is work that some organizations actively avoid until after their data has already been breached or their roster of once shiny development talent is decidedly disengaged and half-heartedly delivering at 40% ---best effort.

I would offer, that strong practitioners also view governance as coming from within the SDLC. Governance as an integrated continuous assessment and correction process that can live inside of the existing governance framework.

Neither do strong practitioners view governance as a rigid or formal exercise or a complicated, arduous and artificial set of tasks. Governance leaders have learned that real best practices, are meant to be treated the same as "business as usual" and integrated into everyday activities. These micro-practices are cumulative, and do directly impact the end product quality and the ease of its delivery. This type of integrated governance can also make long-term and widespread best-practice adoption more likely. Simplicity is catnip to engineers.

I've gone back through my notes, excerpted WhatsApp "off the record" chats with former colleagues and consulted my favorite developer, Albert Pryka, to see what we all thought were some good examples of strong SDLC governance practices:

Requirements Planning

• Risk Assessments: Starting with a risk matrix, score each risk and build the product for control of those risks first. Work outwards to "nice to have's" from there. Measure and control. Repeat.
• Business Analysis: Map requirements directly to a business objective, with a budget. This will help to control "scope creep" and "budget creep" later. This will also come in handy when you need senior stakeholder sponsorship, in the case of budget reallocation to changes in requirements.
• Functional Documentation: Make it clear, make it current, make it creative. People need to want to reference this, in order for it to be most useful. It is best served in "root cause" diagnostics for critical situations or to understand integration needs when designing new features.

Software Design

• Design Review: Before design sign-off and before development begins, all design elements must be reviewed and approved. User Acceptance Testing should be robust, a full Sprint ideally dedicated exclusively to testing and documentation.
• Clearly Defined Roles / RACI: Knowing which level of support your development team will offer, and what they are capable of delivering with the resources they are given must be clearly defined before any work begins. This will help to avoid any future contention about Level I, II or III support definitions.
• Continuous Integration: Ensure changes are being tested as they are promoted into production code.
• Code Reviews: Focus not only on functionality of the code, but also reviews for code performance, comment details, supporting documentation and ease of refactoring.
• Daily Build Process: Encourages developers to write code that enables system stability.

There is certainly far more in the way of software development governance---code annotation practices and error log reviews. Log file standardization, consolidation and trend analysis. Strongly negotiated vendor support contracts. Strict version control, lower environment controls and standards. Strong code promotion practices. No testing in production or changing code "on the fly". Complete, and up-to-date integration documentation libraries, architectural references diagrams for how environments are built. ---there's so much more.

A good SDLC governance model empowers teams to decide which best practices to use within the guidelines for each type of deliverable. The best governance empowers teams--by encouraging process stability within the development environment. Within a stable environment, run on principles of predictability --developers can be free to focus all of their efforts on what they do best. Developing good code.

What SDLC governance themes would you add, or remove?

What has worked well for your teams, and technical governance or software development?