(Originally published on LinkedIn)
In this post, I´ll keep covering our digital transformation. If you haven’t read the previous part, you can the first part here and the second here. This is the story of how we left a legacy workplace in 2018 and started to build for the future.
One thing I’ve noticed that you often come across when you working bigger changes, and especially moving to new technology, is variations of the phrase “yeah we don´t do it like that here, it would never work”.
If you have never tried it and you don’t really know what it is/means, how can you be so sure that it will not work?
I quite often play the “hey I´m a millennial”-card when discussing change (it works surprisingly well), especially when I talk about things that might be a bit naive and oversimplified. But it´s an effective way to push forward and skip over some of those road bumps which you tend to get stuck on.
We now live in a world which is ever changing when it comes to the workplace. You can update the Office suite every month and Windows feature updates are released every six months. This is quite different from the past.
So how did we decide to navigate this?
The first step we took was to accept that this is what the world looks like now. No matter how much we complain by the coffee machine, this is the reality now.
The second step is to sell this to the organization, especially key stakeholders such as application owners and senior management. This is the tricky part since this is not so much technology as politics.
Instead of seeing each upgrade as a project itself, we built a process to support this flow of an evergreen world. This means that once we have finished the last step in the process, it’s time to start over again. Our process contains the following steps (imagine this as a circle):
- Inform stakeholders that new release is coming in 2-3 weeks.
- Release update to first evaluation group (ring 0) to clear any compatibility issues in the environment.
- Release update to second evaluation group (ring 1) which contains application testers for business-critical applications, to give them as much time as possible to evaluate.
- Release update to third evaluation group (ring 2) which contains application testers for important business applications which are not deemed critical but still would like to evaluate on an early stage.
- Release update to the first pilot group for broad deployment (ring 3) to make sure that deployment works on a global scale. This step is estimated to happen 2-3 month after the Windows 10 feature upgrade is released, but it also depends on the outcome of the previous steps.
- Release update to broad production (ring 4).
During this entire process, we are monitoring the deployments and keeping track that nothing breaks. If an application is identified as problematic, the computers can simply be rolled back to the previous version of Windows 10 and that application will be put on an exclusion list (basically be put in ring 5) until the application owner has taken action on the application. This has however not yet happened.
Does this process work in the real world?
Yes. We ran through this but at a slightly higher pace when moving from Windows 10 1709/1803 to Windows 10 1809. To our knowledge, we did not have any major incidents where we broke an end user’s computer. We upgraded roughly 18 000 computers in a matter of a few weeks.
We did have errors though, and a lot of them during the first week. But all errors were indicating that users were not able to run the upgrade (it was blocked). This was also expected based on the earlier test we had run with the earlier rings, but nothing we couldn’t handle. Everyone was confident in the servicing, and all errors were either “solved by them self” or fixed by our technicians in bulk or case by case.
After our first major Windows as a Service experience, we still trust the servicing. We were even more confident after the upgrade that the Windows as a Service process works.
BUT, having static rings as we do today is far from ideal. Until we have better tools (such as Microsoft Desktop Analytics) to create dynamic rings, this is our approach. We will spend some time fine-tuning the setup and move to dynamic rings once we have the tools.
The outcome
- Users had the update as available for 21 days, after that the installation was mandatory
- We upgraded roughly 18 000 computers in about a month
- No major application compatibility issues
- Branch Cache took about 50-60% of the workload
- No reported network disturbances during this time caused by SCCM
Bonus learning
One thing we realized quite early on was that the phrase “application testing” scares people, especially management. Testing is expensive and time-consuming is a general feeling and causes unwanted friction when you want to speed up the pace. Therefore, we decided to rephrase it. We were not aiming to do “application testing” in ring 1 and 2, we are aiming to do “application verification“. This minor change in the wording changed the dialogue a lot and people became less scared of the flow we set up. Verification is less scary then testing.
