09 Reacting to change and product evolution

Editor's Notes

1. The super-freighter in the image moves deceptively quickly – it runs on a schedule, it’s movements within controlled shipping areas are published, it will cross the Atlantic in around 10 days though it is slow to start, it takes a long time to change direction and often needs help doing so, normal waves have no impact upon it, icebergs are foreseen and avoided. The containers it carries change regularly and occasionally a “reefer” falls off and is lost at sea. Now consider Office 365 to be the super-freighter, the containers a mix of product features. The service is evergreen – that is Microsoft updates it on a regular cycle. Some of their Roadmap is published (schedule), some of the changes are communicated (published shipping movements), some of the changes are just imposed (with the outcome that some of the containers simply fall overboard), new features are added whilst others are taken away (containers are loaded and others unloaded.) As a consumer, the bulk of this is out of our control. In addition A/B testing can temporarily add / remove functionality for specific users (or in freight terms, a container gets temporarily misplaced when it is unloaded – finding itself in the wrong bonded warehouse). Therefore we have to change our mind-set from “big change projects every x years” to “smaller updates every month”. Our services cannot be super-freighters that take significant time to turn or stop. To stay agile and reactive, we have established our Ships Bridge in yammer and have created an O365 Change and Strategy Group (https://www.yammer.com/mottmac.com/#/threads/inGroup?type=in_group&feedId=5849903) and are trying to #workoutloud. The group contains key stakeholders from across the IT service and we can invite others in as the need arises. The point is that it’s about preparedness, monitoring the channels you have access to, reacting as quickly as you can when something new is unloaded and not fighting the super tanker.
2. We monitor and react to change by:   1. Identifying the potential changes For this we have a network of inquisitive spy’s. We use a combination of the Microsoft Monthly Service Update ‘newsletter’, weekly reviews of the Message Centre, companies that we are working with, a near constant eye on the O365N, the O365 Roadmap and some other sources that we’d not like to reveal. All of the knowledge is discussed in a dedicated Yammer Group and when we know the MSG ID we tag the conversations with it (as well as adding links to threads on the O365N etc.). We also maintain a tracking spreadsheet (as you’ve got to have a spreadsheet). To be honest it is too much like hard work and Yammer and Microsoft should make this easier.   2. Discuss the potential changes We have an allocated slot in our weekly team meetings to discuss roadmap items and how we intend to tackle them. The tricky part is not knowing exactly when the change will arrive. I usually take actions to try and get more information. For example, Yammer announcements are usually pretty light on actual detail. What really helps is the Change Alerts (https://www.yammer.com/itpronetwork/#/threads/inGroup?type=in_group&feedId=4355152) group in the O365N as customers typically in North America get the change days or weeks before it arrives in our tenant. By following that group, we get an early warning of impact, mitigation and customers we can talk to. Occasionally Microsoft will retire a product as part of a change and so it is important to understand the Support Lifecycle https://support.microsoft.com/en-gb/lifecycle   3. Test the change Fingers crossed it arrives in our First Release tenant. At that point we play and test it, grab screenshots and prepare the communications. Each element of O365 has a dedicated space in our new Intranet. We typically prepare a new page that describes the feature and briefly explains how staff might use it. Massive exception to the rule is Yammer as from this day to the next we do not know what is A/B and what is feature release.   4. Communicate the change Obviously the greater the impact the more we do. Massive change means staff briefings, board meetings etc. Significant items are then reviewed with projects and/or change tasks created (in ServiceNow). The bulk of changes are communicated using our Intranet – we use the article created in 3 as the news item. We also push news out across yammer – again with links back to the article. Sometimes a targeted email blast is employed and we have a dedicated service alerts banner that we can enable in our intranet.     * As an aside, we operate a second tenant with a small amount of content in full First Release mode and our Production tenant has Selective First Release for named users - sometimes the change is hard to test as we do not have enough content or numbers of users in our test tenant - we are looking at using ShareGate to snapshot our production instance and replicate the content in test, though this will not replicate the number of users which is vital for testing items like people search and profiles