Aug 13, 2014
An interesting article on ARS Technica on Microsoft’s journey with scrum: “How Microsoft Dragged Its Development Practices Into The 21st Century”
It’s worth the read, but here’s the condensed version, with annotations.
Increase Frequency of Delivery, Shorten the Feedback Loops
MS Visual Studio was delivering to production every two years, and they were considered “fast” by comparison (most other MS products were on a 3-year release cycle). Customers’ expectations changed. No longer was it acceptable to report a bug or request a feature and wait, on average, three years before seeing any feedback. Now this team is releasing updates to production every three weeks.
“With the new process [scrum] in place, the Visual Studio team has been able to build better software and deliver it more frequently. It’s now approaching its 70th successful three-week sprint. TFService, now rolled into a broader suite called Visual Studio Online, has a service update every three weeks, putting new capabilities and features into users’ hands on a continuous basis. On-premises software hasn’t been forgotten either. The sprint-based updates are rolled into quarterly updates for the on-premises TFS.”
Lower the Lake, Expose The Rocks
Frequent delivery to production, while useful in itself, is useful even if you don’t take advantage of it (you don’t go to production, but you have made it production ready every sprint). That seeming contradiction is captured in this observation from the Microsoft Visual Studio team after they switched to scrum:
“The need for regular iterations has also caused improvement to some unsexy parts of the software. The setup and upgrade process for Visual Studio was annoying and complicated, with a large testing matrix to handle upgrades from various different versions. With an iteration every three weeks, this situation was set to become intractable. Because setup and upgrades are done every sprint, the system needed to be more robust and easier to test and manage. The agile process motivated that work, and the result should be that upgrading end-user machines is less disruptive and prone to failure.”
Putting this another way: “If It Hurts, Do It More Frequently, and Bring the Pain Forward.” – Jez Humble. The knock-on effect on your organization and it’s processes is important because by shortening the cycle time for delivery we stress/improve the most important parts of the value stream, the one that holds us back from increasing the flow of value to our customers. Nothing else has the same laser focus for cutting through the noise as does shortening the delivery cycle times.
Internal Open Source Code
“Microsoft is traditionally viewed as a series of fiefdoms, with each team jealously guarding its own work and not sharing with others. As such, people in one team have historically had little access to other teams; they couldn’t see what they were working on or the source code they were producing.” [an example of Conway’s Law, where the org chart ends up reflected in the code]
“… source code is now viewed as a shared resource. If people in the Bing team, say, want to look at the Windows code, they can. Further, we’re told that if they want to fix something in the Windows code, then that too is possible …”
The Dark Side
Microsoft recent announced the largest round of layoffs in their history.
“…one victim group appears to have been the dedicated programmatic testers in the Operating Systems Group (OSG), as OSG is following Bing’s lead and moving to a combined engineering approach …
Obviously they still have some lessons they haven’t yet assimilated. One would have preferred the lean value of ‘job security, not role security’ to be applied. It’s insane to think employees will willingly engage in adopting practices that improve things for the company if they believe they will lead to their own demise. There is a limit to corporate loyalty.
Other
Other items of note: the changes to the physical space to allow teams to collaborate much more effectively, the photo of the working agreements for one of the teams posted on the whiteboard (page 3). While Microsoft has largely adopted scrum bottom up, they appear to be hitting the limit of the benefit and are now feeling pressure to become a more agile organization. The implications of that will be hard for their management team to swallow, but entertaining to watch … from the outside.