One of the things I have noticed in my conversation with customers on deploying updates to Windows (whether quality or feature updates) is that the systems designed for change management are designed to prevent agility at ever step. Now, in some ways, this can be good – you do want to make sure that you are measuring and managing risk effectively – but we need to acknowledge that there is also risk in standing still. And that is my challenge for everyone: to understand the extent to which we are properly managing risk.
You see, I was working with one customer, and they enumerated the list of gates before they would deploy a feature update to Windows 10. It included:
- Sign-off from IT
- Sign-off from Security
- Sign-off from end-user support
- Sign-off from each of more than 500 application owners
- Sign-off on a custom image from image engineering
- Sign-off from ConfigMgr team
In total, close to 600 people had to say “yes” before a single seat would be deployed.
That seemed like a lot to me.
That got me looking for an extreme to try and set a cap – what is the single most devastating, impactful thing you could possibly do, and how would you mange that risk? Being a child of the 80’s, and recalling the movie War Games, I thought about what it would take to initiate a global thermonuclear war. (Spoiler alert: you can’t actually do it using an acoustic coupler.) It appears as if it takes 6 people: the President, the senior officer in the Pentagon war room, and two launch crews of two people each.
I may not be an expert in risk management, but I do find it hard to believe that deploying a feature update to Windows is 100 times more risky than initiating a global thermonuclear war!
What we are finding is that more successful customers are designing their systems to provide a mechanism which defaults to agility, rather than a mechanism which requires continual effort in order to move forward. And that correlates strongly with the challenge I’m hearing from many customers: that it requires too much effort to stay current. Which makes sense, if you have a process that requires hundreds of people to all manually “turn a crank” to move the deployment forward, it naturally takes more effort!
So, what does an agile process look like?
Perform Initial Validation
Before releasing initial deployments, validate a handful of key scenarios to ensure they are not impacted. These are the Always Test and Canary Test apps, where you quickly iterate through these scenarios. As an example, within Microsoft IT, we have a team dedicated to this, who complete these scenarios in just a few days. A deployment deferral is generally sufficient to account for this time – rather than waiting for official sign-off, account for the time with a reasonable deferral. If you run into an issue, then hit the snooze button.
Execute Ringed Deployments
After the validation is complete, then begin rolling using staged rings. Again, these rings have a deferral date, and can be snoozed, but generally continue rolling unless there is an intervention.
This is really key to the strategy of how we’re building our products and services: to continue to provide the control that enterprise customers need, without the constraint of always applying that control in a way that requires manual effort for every single interaction. At the same time, it’s a good idea to continue to reflect on your processes (as, remember, results are always driven by a blend of people, process and technology). Inertia is natural – if you’re used to standing still, then moving is uncomfortable. But once you have learned to move, continuing to move becomes the more natural action.
Do your processes default to the inertia you want (progress vs. stasis)?