Microsoft's Agile Transformation Journey

This week Steve Denning published two great articles about Microsoft's Agile transformation journey. Both stories contain lot's of recognizable lessons learned. While studying both articles I simultaneously wrote down the highlights. I highly recommend reading the original articles, but these highlights might be useful if you're looking for a quick overview.

Article one: "Surprise: Microsoft is Agile"
Article two: "Microsoft's 16 Keys to Being Agile at Scale"

Part I - Microsoft's Agile Transformation Journey

• Microsoft proved to be less like a giant battleship and more like a flotilla of speedboats operating and maneuvering in an orchestrated fashion.
• Agile values are alive and well in the Developer Division of Microsoft. It is not only doing Agile. It is being Agile. There is a pervasive Agile mindset in which respecting, valuing and engaging those doing the work in response to customers’ needs is at the core.
• The commitment to creating a workplace characterized by autonomy, mastery and purpose is explicit. Teams have the autonomy to be the masters of the features they deliver.

They Way Things Used To Be

• In the past, the production cycles would be two or three years, not three weeks.
• They never shipped on time. They always felt that they were going to ship on time.
• "We ware making bicycles, while competitors were producing Ferraris."

The Agile Transformation Took Time

• But the Agile transformation journey was anything but a straight path from A to B. Initially there was a lot of pain. It took a long time before they could actually ship at the end of a three-week sprint.
• Let’s not be date driven, let’s be value driven. For a lot of people, it was very disruptive.
• "We are already five years into this. People need that time (emotionally) to let the changes evolve. You can’t make all the changes at once.”

Part II - Being Agile at Scale

1. Pursue "Agile at Scale", not "Scaling Agile"

• The question addressed at Microsoft is: “How do we make the whole organization agile?” not “How do we scale Agile or Scrum?”
• There is a continuing effort to get the right balance between alignment and autonomy.

2. Take care of planning and coordination

• Every team has the authority to make changes. If the team sees something that was missed, they don’t have to ask permission to make a change. They just keep the leadership team informed.
• The only important question is: how are the customers is responding to what was being done?
• The point is that a conversation is taking place. They are not just blindly following a plan.

3. Get the right balance of alignment and autonomy

• The goal at Microsoft in Agile at scale is to have alignment at the top and autonomy at the bottom.
• The managers are responsible for the rules of the road. This include clarifying the roles, the teams, the cadence, the vocabulary.
• The team has autonomy in terms of how they go about doing the work in both planning and practices.

4. Master the new role of the manager

• It’s the difference between the principles and the practices. It’s vital that people understand why they are doing the practices. And then taking responsibility for the value that is meant to come with them.
• Does the manager want perfect burn-down charts or the right conversation? In the end, it has to be the latter.

5. Handle dependencies at the team level

• The dependencies are handled to the extent possible by the teams themselves.
• The teams all know what the other teams are doing. They are all in it together.
• They are self-managing and learning how to become good at it.

6. Ensure Continuous Integration

• Continuous delivery has meant more modularity in design and a change in architecture.
• To ship every sprint, they had to make a fundamental change. In principle, all the teams are now “working in the same branch.”
• They come together all day, every day. So if a team breaks the build, it fixes the build immediately. They do whatever they have to do. The longer the team waits to put code together, the greater the risk of technical and integration debt—and disaster.

7. Keep on top of technical debt

• “Now the bugs never grow. There ‘s a Key Performance Indicator (KPI) we call ‘the bug cap.’ It’s the number of engineers on your team times four.
• If you get to 40 bugs, the team needs to stop work on new features and the next sprint, get the bug count back down below 40. It’s self-managing. Teams know this.
• It means that we can ship product all the time now, because we know we’re always in a healthy state.”

8. Embrace DevOps and Continuous Delivery

• In this way of working, development and operations merge. The teams own the planning of each new feature. They own the execution of the feature. They own the delivery the feature. And they own the operation of the feature.
• Who wanted to spend their time fixing someone else’s mistakes?
• The teams own the entire life of the feature. They own the features they create. No one else to blame.

9. Continuously monitor progress

• The teams do a great deal of monitoring how the features are being used.
• They use their brain and their gut feel as well as being informed by the data.
• Part of the very definition of “done” is having the right telemetry. It’s part of the acceptance criteria to ship.

10. Listen to customer wants, but meet their needs

• The teams don’t blindly follow what customers say. They have what they call “the cookie principle.”
• The program managers need to listen to what the customers say they want, but their job is to build them something they need.

11. Deal with directions from above

• There is very little load balancing among teams. If a team gets behind, they don’t break up the team or move individuals to the team to fix it. They ask the team itself to fix the problem. They try to keep the teams together for 12 or 18 months.
• If you’re reshuffling them every three sprints, or even reshuffling the things they are working on, that makes it pretty hard to get really good.
• The firm is making an investment in the team for at least nine months or a year.

12. Use self-forming teams to encourage team ownership

• The managers let people choose which team to work on. People can reshuffle every 18-24 months.
• The team owns the backlog. But a manager doesn’t tell the team what should be next on the Kanban board. Nor does the team dictate to the manager.
• These conversations require a level of mutual trust.

13. Recognize that the team is the product

• The team has a longer life-time of generating value than the product itself. That’s a big shift in focus.
• It’s more difficult for firms going Agile that don’t have a history of teams.

14. Build quality from the beginning

• In the beginning, they planned for “a stabilization sprint” after five sprints. However that encouraged some teams to think: “No need to worry about bugs, because we have the stabilization sprint!”
• It’s part of the concept of autonomy. If the team can control its own quality, they’re not surprised about what they’re going to have to do in the future.

15. Use coaching carefully

• External coaches and trainers at Microsoft were noticeable in the site visit by their absence.
• Some of the Microsoft staff and managers in effect became Agile and Scrum coaches. But overall, the group itself just set out and went for it.
• There is no “one size fits all” and that what works elsewhere may not fit the Microsoft culture.

16. Ensure top level support

• To achieve Agile at scale, the support of the corporate vice-president, has been central.

Take-a-ways

• Get good at the science of Agile and Scrum but don’t be overly prescriptive;
• Don’t copy others: learn from others;
• Build the culture you want … and you’ll get the behavior you’re after;
• Stop trying to predict the future;
• Optimize around customer feedback.