Many managers are skeptical that scaling agile organizations is feasible. Microsoft's successful five-year large-scale agile transformation shows that the answer is yes. Microsoft is less of a giant warship and more of a fleet of synchronized speedboats: hundreds of teams doing Agile and Scrum in a coordinated fashion. How are dependencies handled? How do teams stay in sync? If hundreds of teams are autonomous, how does management know what's going on, let alone control it?
Can big companies be truly agile? Microsoft's 5-year transformation
In July 2011, when Microsoft Corporate Vice President Brian Harry announced an enterprise commitment to Agile in a blog post to the Scrum community , many people and employees were skeptical. Can a large company like Microsoft become a truly agile company?
The transformative commitment to agile is driven by business imperatives, not just the recognition that it generates more dynamism, energy, vision, and dynamism in the workforce, which is, after all, a better way to get work done. Gone are the days of delivering new versions of software in a box every few years. Software now delivers updates online over weeks or months rather than years. To keep up, Microsoft had no choice but to go agile.
Happily, 5 years later the Agile values are still alive and well in Microsoft's R&D organization . The division not only implements the general practices and methodologies of Agile, Scrum and DevOps for itself, but also promotes them for others. Including developers live, think, talk and act with agile values. It's not just doing agile. It's being agile. There is a general agile mindset where respecting, valuing and engaging those who do the work according to the client's needs is at the core.
This is a huge change for Microsoft . In the past, the product cycle was two or three years, but now it is three weeks. Team autonomy, mastery and purpose are greatly improved. A virtuous cycle can be seen where a more effective and engaged workforce operates faster, with better quality, it is easier to connect with and understand customers' needs, and respond faster so that customers are satisfied on a regular basis.
But the agile transformation journey is by no means a straight path from A to B. The approach to adopting Scrum—sprint planning, iteration virtuals, daily standups, iteration reflection meetings—is only part of the challenge. What's more, and more difficult is the shift in the minds of all involved.
Agile workplaces have emerged : with open spaces, fresh, vibrant colours, comfortable meeting rooms, multiple variations and opportunities, encouraging collaboration in a pleasant and informal atmosphere, and ubiquitous "information radiators", physical The place looks agile. Seeing executives often sitting at the exact same mobile desks as the youngest employees is a powerful visual signal of a shift away from a top-down, authority-based culture.
How did Microsoft succeed in its five-year, massive agile transformation? It's one thing to do Agile and Scrum in one team or even several teams. Doing Agile and Scrum in a coordinated way across hundreds of teams is a completely different concept. How are dependencies handled? How do teams stay in sync? If hundreds of teams are autonomous, how does management know what's going on, let alone control it? This article lets us discuss the hot topic "How does Microsoft scale agile".
This case study is based on an in-depth interview with Aaron Bjork, a program manager for Visual Studio Online, a Visual Studio team in a development organization with approximately 4000 developers. Interviews and surveys show that Microsoft is no longer a giant warship, but more like a fleet of speedboats traveling simultaneously.
Enterprise Agile Transformation
1) Pursue "Agile at Scale" rather than "Agile at Scale"
Note first that the managers at Microsoft talk about "scaling agile" not "scaling agile." By implication, "scaling agile" is like "scaling the legal department" or "scaling the cafeteria," which means nothing more. Agile and Scrum are not what zealots sometimes think they are: a panacea for every possible management or leadership problem. There are many aspects of an organization's activities, including strategy, planning, finance, marketing, and sales, that are not related, at least not significantly, to the goal of "working software" as referred to in the Agile Manifesto.
The question Microsoft explores is: "How do we make the entire organization Agile?" rather than "How do we scale Agile or Scrum?" Scrum and Agile methodologies in software development have huge potential contributions to answering this question, but Scrum and Agile are just stories a part of.
Microsoft's "Agile at Scale" does not require teams to blindly adhere to whatever the goal is. The essence of "Agile at scale" practiced by Microsoft's development department is the core value of agile. This includes a close focus on delivering ongoing value to customers, not just generating quarterly profits or boosting current stock prices. It is also based on a deep respect for the capabilities and talents of employees, rather than viewing employees as assignable, one-time “resources” that can be optimized.
A key aspect of the managerial mindset is the manager's own explicit awareness that managerial power has the potential to both motivate and inspire employees and to discourage and demoralize them. So, a deliberate, even subtle use of administrative power is required in a sustained effort to strike the right balance between alignment and autonomy.
2) Focus on planning and coordination
Planning begins with establishing a product vision. Then, a program manager like Aaron develops and is responsible for what is called a "scenario", which is what the product is going to be for the next 18 months, the story of what the program will be 18 months from now. Stories can engage other teams. The group had 60 percent confidence in their ability to predict and deliver what customers wanted. The year is divided into two seasons called "spring" and "fall" - words that are a local joke that reflect the very short summer in Seattle.
There is a scene review every six months. The group reviews progress and checks next steps. This usually means scene reshaping, and here are three questions: Based on the product we built, what have we learned in the past six months? What do our customers tell us? What has changed in the market? It's both planning and learning.
Every team has the power to change. If the team sees something missing, they just need to inform the team lead, they don't have to ask permission for the change.
After six months of execution, the team looked back at the plan, and the group felt confident about what they could accomplish in six months. But they didn't build a Gantt chart across multiple teams, schedule time or those details. They all gain intuition through the conversations between the teams to judge what needs to be done and what can be done in six months. And based on what they learn from the customer and what they learn, plans may change.
At any time, each team maintains and is responsible for a well-thought-out and detailed plan that consists of three sprints of three weeks each. The team always has a good idea of what to do in the next three sprints. At the end of each sprint, the team decides what to do. They may decide to develop a new feature or decide to learn something new, they may decide that something needs to be brought forward two sprints from now. There is room for adjustment here, and that adjustment is expected. In fact, that's the whole point.
How to plan and coordinate, there is no single correct answer. It's not just adding a new sprint at the end of the just completed sprint. Teams are talking about these issues and discussing with managers, reviewing what they have learned. In each sprint, they revisit from the user perspective.
At the end of the sprint, the team recognizes what they have accomplished. But they don't look backwards too much. They don't say, "We really did three sprints planned!" They have some awareness of what they did, but they don't celebrate what they did right, or mourn what they did wrong. The only question that matters is: How do customers respond to what they're doing?
In the past, teams would blindly follow plans because they were agreed and approved by management. And the team appears to be delivering on the plan. In the end, the team will say, “We delivered the plan! How cool, right?” On the surface, yes. But in reality, hidden quality issues tend to pile up, and technical debt is accumulating that will have to be paid back someday. What is the customer thinking? No one cares, the focus is on the inside.
Of course, not everything happens as expected. For example, a team has a plan that consists of three sprints, and they say, "We're going to do A, B, and C in the next sprint." But they don't, and the next sprint is still A, B, and C, and the third sprint Also still A, B and C. Clearly something is not right. what happens? The team discusses it, and if it's an internal team issue, they discuss it with management. If what they're doing is more complicated than expected, maybe they should do some planning again. That's okay, the point is that the conversation is happening, not blindly following a plan.
3) Effective alignment and autonomous balancing
The goal of agile at scale at Microsoft is to have alignment at the top (of the organizational structure) and autonomy at the bottom. Teams need autonomy, which drives them to work and create great products. But at the same time, their work must be aligned with the business. Nothing gets done with too much control: no one wants to work there, it's not a fun environment, in fact, it's a disaster. With too little control, chaos ensues: everyone builds what they want, there is no end-to-end scenario, customers get frustrated, and nothing is done that makes business sense. So managers strive to strike the right balance between the two.
Managers are responsible for traffic laws. This includes clarifying roles, teams, cadence, vocabulary, and limits on the number of bugs a team can have (“bug ceiling”).
Teams have autonomy over how they do their work, both planning and doing. Within the general framework, everyone can take a different approach. Specific engineering practices depend on the team. For example, teams decide for themselves whether to do pair programming or not.
The role of management is like establishing traffic laws. You can drive fast on the highway, in fact, highways are designed to let you go fast. But the rules exist. When you turn your car, you must turn on the indicator light. You have to slow down at a certain point. You have to pay attention to these things. Traffic authorities can make highways safer by placing speed bumps every 100 yards and traffic lights every mile. While this will be more secure, it will slow things down. Microsoft managers take the same approach. They dictate the minimum set of basic traffic laws that teams need to obey. Their goal is to ensure that these regulations help teams move fast and get where they want and need to go, rather than slow them down.
Of course, if you ask an engineering team, as Aaron puts it, "What is the leadership telling you to do that slows you down?" you're going to get a bunch of feedback, not just one or two. They often ask clusters of questions. The team is just waiting for the manager to ask questions! The team will tell the manager everything he did wrong and have a dialogue about it. The point is to have this conversation, and it's a safe conversation.
4) New role of transition manager
What happens when the team cannot complete a sprint? The manager does not monitor the team's burndown chart. Burndown charts are for teams. If they're behind schedule, guess what the team does? They talk about what to do. This is exactly the behavior the manager wants. Managers support this behavior because the culture supports it. Guess what the manager gets if he yells at the team or monitors their burndown chart? The perfect burndown chart! So do managers want perfect burndown charts or decent conversations? In the end, it has to be the latter.
This is the difference between principle and practice. It is vital that people understand why they are doing what they are doing. People take responsibility for the value of what they do. If daily standups aren't working, be an adult and make a difference! This is autonomy. "You are in control! You are in charge!".
5) Handle dependencies at the team level
In Microsoft's development department, teams handle dependencies as much as possible among themselves. All teams are together and know each other what the other teams are doing. Managers or teams don't just care about their part of the product, they know what other teams are doing, they know what other teams are doing. If one team has a dependency on another team, they don't wait until the meeting to let each other know. Program managers and engineering managers talk about and discover this dependency upfront. They self-manage and learn how to become good at self-management.
Of course, sometimes, the team leaders come into a meeting and find out, "Oh, have you guys started this? We don't know! You should tell the other team." They make sure there's a chat between the teams, and the chat is offline After completion, the leader clarifies the status quo.
We want this three sprint plan to include all dependencies. Aaron works with his team of five. Six groups of other teams followed the same process. Managers sit down and talk about team-level dependencies and tease them out on an ongoing basis. They sit in the same room and it's an ongoing conversation.
There is a standing meeting across all teams every three months. It's called "Functional Team Talk". During the meeting, each team joins in and discusses their plans. Aaron had 90 minutes total, and each of his teams had 15 minutes to join in and share the team's plans. His colleagues also took part in the sharing with the team. All teams participate in this meeting, so everyone is informed. The leadership team of the development department also has the opportunity to synchronize current progress.
6) Ensure continuous integration
Continuous delivery means that the design becomes more modular and the architecture changes accordingly. When development first entered the service business, they took a custom product, put it in the cloud, and prayed. Turns out the product didn't work. When a part of a product doesn't work, the whole product doesn't work. They understood that they needed to layer their services to isolate the problematic parts without compromising the entire product. Therefore, continuous integration requires deep architectural changes to support.
When they started, each team worked on a branch of code during a three-week sprint. At the end of the sprint, they would put the code all together and it would be a mess. In fact, the team owed so much "integration debt" that the model didn't work. So, in order to deliver every sprint, they had to make fundamental changes. In principle, all teams are now "working on the same branch."
"Working on the same branch" means that each team uses a program called Git, pulls the branch, and makes changes. But teams don't work in isolation for three weeks and hope the code comes together. It's that they're together all day, every day. So if a team breaks a build, it does what it can to fix the build right away. The longer the team delays putting code together, the greater the risk of technical and integration debt, ultimately leading to disaster.
The team uses what they call a "feature flag", and here's a concise description of how it works. If they're going to do something new, the first thing they do is isolate the code they're changing and build a switch for the changed code to go into the integration code. This switch is provided by a flag in the database. This is a configuration change. When the team writes the code, they write it after the security of the logo. At a certain stage, when everything is ready, they are only open for the team. This switch is not a global switch, but a dedicated switch for this team. If it goes well, then the team can flip the switch for certain customers. These customers can see and try, helping the team find bugs and problems. When the team passes the above gates and thinks that everything is really ready, they will prepare to release instructions and announcements to turn the switch for everyone. Then they go back and refactor the old code. The working mechanism of "feature flags" allows multiple teams to work together on the same code without interfering with each other.
At the end of each sprint, the team sends an email to all 450 people including the Visual Studio Online team and the leadership team. They talk about what they accomplished in the sprint and what is their plan for the next sprint. They record a 3-5 minute video. (Hint: If the team has an ambitious Hollywood director, the video is amazing.) The video replaces the sprint presentation.
7) Make technical debt a priority
“In the old days,” says Aaron, “teams had parties and celebrated when code was written. They felt like they had accomplished something. But in reality, they were sitting on a mountain of bugs that they hadn’t even found ...and now they have to go back and find all these bugs and fix them. They're months away from delivery. It's a nightmare.
"Now bugs don't grow any more. There's a key performance indicator (KPI) we call a "bug ceiling" that's four times the number of engineers on your team. So if you have ten engineers, your bug ceiling is 40. If your team hits 40 bugs, you need to stop new feature development, and in the next sprint, get the bug count down to less than 40. This is self-management, and the team understands it. It means that now we can Release products because we know we are always in a healthy state.
8) Embrace DevOps and Continuous Delivery
Work as a merged development and operations. The team plans, develops, delivers, and operates each new feature.
So if a service isn't working properly, then they have to stop what they're doing to deal with it. If a bug is found or needs to be fixed, they are the ones who fix it. There used to be separate support teams doing this stuff, but who wants to spend time fixing bugs from other teams?
The team is responsible for the entire lifecycle of the feature. If the service crashes frequently, then this is a code quality issue and an incentive to build good code. Teams work on a continuous basis. The team takes responsibility for the features they create without blaming anyone else. They don't have the pressure of a big release, they can stage their work and solve problems at their pace.
A change in time frame makes a big difference. Now the deadline is three weeks. Three weeks is no big deal. Before, you only had two chances, and if you missed it, you had to wait two years. Now, if the product is not high quality, you don't launch it, you withhold it. It's disappointing that it didn't come out on schedule. You talk about it in retrospectives. did you do something wrong Or are you just underestimating the complexity? Are you missing something? It's better to have a chat than to fix or punish a team that doesn't deliver on their promises, than to deliver a poor quality product.
Things have changed dramatically. It used to be that there were a lot of bugs in the organization, and people were pointing fingers at who was responsible for which bugs, but the result was that bugs persisted for a long time and multiplied. Now the team finds them themselves, fixes them, and gets it done. Bug cycles have been greatly reduced.
Two years ago, the team flirted with the idea of delivering code daily. But they found that customers didn't want it, which meant too much variation, and the business need for daily delivery didn't exist. At the same time, the team is learning to do work in small pieces.
9) Continuous reflection and refinement
The team does a lot of monitoring of how features are being used. The monitoring results enter the to-do items and become lofty goals, which are called scenarios. Each month, program managers report metrics on the usage of different services. In this way, the group is learning to be a data-savvy team. They don't call it "data-driven" because that would risk blinding Mount Tai. They think intuitively, but also with data. But data is not the end of thinking, it's often the beginning of a conversation.
Data can be used to locally predict "done" situations. Teams can see and monitor this data while testing features and as soon as they go live. Monitoring data is not something they do in Sprint after they release the function, but a part of the release acceptance criteria.
Once the code is released, the team asks: How is the software used by people? Is it driving people to the core of our conversations? Will they become regulars? Or just a casual customer? They use metrics to drive the business forward.
10) Listen to what customers want, but meet their needs
Program managers conduct a variety of customer visits, including visits at the top at the Executive Release Center for strategy, people using the product on customer boards, and Microsoft Most Valuable Professionals. These professionals are often on-site as consultants, sell Microsoft products in some form, and are not Microsoft employees. There is also a distribution table called the champion list. These people write to Microsoft all day long about what they want. The program manager talks to them. The sales team hooks developers up with customers. Program managers spend more than 7.04% of their time on Twitter communicating with customers.
The team does not follow blindly what the customer says. They have their own "cookie principle". If you have a plate of cookies and you ask people if they want to try them, they will say yes. No one can say no to cookies. If you go to a customer and ask, "Do you want this feature?" guess what they say? Why not? This is the innovator's dilemma. There are so many good things out there that you can do. You need to listen, but not follow blindly. Program managers need to listen to what customers say they want, but their job is to build products that customers want and that the company can sell. Otherwise, managers are remiss.
11) Handle guidance from the top
Aaron has never heard any higher-ups say, "Stop the agile thing!" One reason, of course, is that agile teams are already very successful. Agile has grown and expanded because of its success.
Teams still receive guidance from the top. During our visit, a team was being reassigned to other things. While it's disruptive, it's happening because the team is needed elsewhere. Team members stay together as a unit, and managers sit down with the team to discuss this.
The burden of keeping balance between teams is next to nothing. If a team falls behind, they don't disband the team or move manpower to the lagging team to fix the problem. They asked the team to figure it out on their own. They try to keep the teams together for 12 or 18 months. That's what the team likes. The goal is for them to get good at building software together. That's their job. If you reorganize the team every three sprints, or even reorganize what they are doing, it will be difficult for the team to cooperate with each other. Companies are investing in teams for at least nine months or a year.
12) Encourage collective responsibility with self-organizing teams
As stated in an interesting article by Microsoft corporate vice president Brian Harry, managers let employees choose which teams they work on. Employees can restructure every 18-24 months. About two-thirds of the team members decided to stay with the original team. Therefore, brand new teams are not very many. But team members have the right to re-select. The result of this is a significant investment in a lasting team that leads to higher performance in addition to team health.
The team owns the backlog. Of course, there was a lot of talk about priorities. But the manager doesn't tell the team what the next item on the board should be. The team doesn't command the manager either. They will always talk about it. This is an ongoing conversation. It's like, "Hey, how about this? Should we do that? Do you think we've invested a lot there? Should we go here?" The program manager has the same conversation with his manager.
These conversations require a certain level of mutual trust. As a manager, you can't be in everything, you can't know everything. The manager says something to the team, and the team listens but doesn't follow blindly. It's giving and taking. It's a conversation based on knowing the data. Such conversations go on all the time.
innovation plan sprint
The direction of many innovation projects is not clear, and the team has made little progress in delivery and cannot continue to advance. How to solve the difficult problems such as strategy, product and growth faced by innovation projects? Using the most popular design sprint method in Silicon Valley, it only takes 1-3 weeks for the team to get a quick answer!
13) Recognize that the team is the product
In software, product life cycles are shortened. In traditional accounting, business assets are products. But in practice, a team that can deliver a product becomes an increasingly important asset. The life cycle of the team to generate value is longer than the product itself. This is a major shift in focus.
Long before starting the agile transformation, Microsoft had the advantage of having teams . A strong team culture already exists at Microsoft. Agile transformation can be more difficult for businesses without a history of teams. When you think about Agile, you realize that a lot of Agile's values stem from the fact that work is done by teams. So, it's important to see the baseline from which you start.
Microsoft sees itself as investing in those people. Sometimes organizations don't recognize this investment. There is a risk that higher-ups might just see people as movable resources. "At Microsoft, that didn't work," Aarson said. "The leadership team understood that."
But change is sometimes necessary and comes with a cost. For example, when a team is transferred, other teams feel bad because they have already spent time and energy dealing with this team, they worked together for a year last year, it is an investment. When a team gets moved, it's disruptive to everyone. Aaron explained the reason for the decision, telling the team: “You guys don’t have the same speed in a new field. You have to advance and build expertise.” But in this case, at least they were already a team, so they already have a level of trust. If a whole new group of people are working together in a whole new field, the cost will be much higher.
14) Focus on quality from the start
At the beginning of Microsoft's agile transformation, there is a lot to learn. In the first few sprints, there is an agreement for 3 week sprints. The leaders signed off on the idea of Agile and Scrum, but they were a bit concerned about how Agile and Scrum would work. So they planned a "stabilization sprint" five sprints later. But then, some teams were encouraged to think: "Don't worry about bugs, because we have a stabilization sprint!" As a result, a lot of bugs were generated, and all teams had to participate to help solve them.
In effect, they've told people to do one thing, but they've created an environment that pushes some teams to do the opposite. And who can blame the team? A good example of unintended consequences is the team telling the manager: "Don't do this to us again!"
Most importantly, the goal is to avoid sequences: write code in the first sprint, test it in the second sprint, and fix bugs in the third sprint. The traffic law is: deliver finished product every sprint.
It is part of the concept of autonomy. If the team can control their quality, they won't be surprised what they will have to do in the future, like work weekends. They can run their own business independently of things beyond their control.
15) Correct coaching empowerment
On-site interviews revealed the absence of Microsoft's external coaches and trainers was noticeable. Scrum started with some coaching and basic training. But after a while, the group starts to just "do it" on its own, figuring out what works and doing more and what doesn't. Some Microsoft employees and managers actually turned Agile and Scrum coaches. But overall, the group set out on their own, and went boldly.
Recently, many people who have not done basic training have joined. So the company gave the practice of doing more agile training . At the same time, the company realizes that there is no "one size fits all" approach, and what works elsewhere may not fit the Microsoft culture.
16) Ensure high-level support
Microsoft's top management was cautious at the beginning of the agile transformation. But that has changed now. "There's widespread acceptance now," says Aaron, "that Agile is the modern way of building software, and it's not too difficult to implement at the team level. You grab ten people and a Scrum guide and you can do it. But how do you span Four thousand people implementing Agile and keeping them in sync? That's the challenge. How do you implement Agile at scale?"
In order to achieve agile at scale, the support of corporate vice president Brian Harry has been at the core . Now, in the development department, Scrum and agile practices have a firm foothold, and Aarson has benefited from it. The Visual Studio team is leading the change at Microsoft as a whole. It has a "First Group Engineered Systems License" (IES) and is rolling it out across the company. There are monthly scorecards tracking how well most departments are doing agile.
This leadership is partly contextual, as seen in offering cloud services: their customers are writing user stories before they even know what a user story is. So they must be fast learners.
"It's going to take time," Aaron said. “We’ve spent five years working on this. We didn’t make all the changes at the same time. The physical space change was one of the last changes we made. If we moved into a team room and put all the specs together , trying to do a three week sprint, it won't work. It has to evolve. People need that kind of time to let it evolve. Emotionally, it takes time. You can't make all the changes at the same time.
key summary
When I asked Aarson what advice he had for other large companies starting agile transformations, he offered the following:
- Use Agile and Scrum theories, but don't be too rigid
- Don't copy others: but learn from others
- Build the organizational culture you want...and you'll get the behaviors you're after
- stop trying to predict the future
- Optimize around customer feedback
Original link :
Extended article :
1. Innovation Guide｜Ten Steps for Product Managers to Manage Product Lifecycle
5. Innovation Guide｜Chain operations start with a single store profit model
For more exciting cases and solutions, please visit the Runwise Innovation Community .