Last month, Brian Harry, corporate vice president of Microsoft, received an unexpected complaint on his blog. Is Microsoft too focused on Agile? “It is obvious,” a reader (Kasper L) wrote, “that you have focused on agile tools the last 6 months… My question is how long are you going to focus on this area?”
The idea that Microsoft is focused on Agile at all will come as news to some. “Microsoft? Agile? Are you kidding?” The image that many have had of this giant corporation with 2014 revenues of $86 billion and 128,000 employees is that of a giant battleship that is strong and powerful but slow to maneuver and not always customer-friendly.
In fact, that was the image came to mind in April 2015 when Aaron Bjork, a group program manager in Microsoft’s Developer Division, contacted us and offered to share the story of Microsoft’s “Agile transformation journey” with the Learning Consortium for the Creative Economy. (The Learning Consortium is a group of firms, sponsored byScrum Alliance, that have committed themselves to learning from each other about themanagement practices of the Creative Economy, or, as Fortune has called it, “the new industrial revolution.” Scrum Alliance is a membership association of more than 400,000 members with the mission of transforming the world of work.)
Several months later in July 2015, when the members of the Learning Consortium visited Aaron and Microsoft’s Developer Division, what we found was less like a giant battleship and more like a flotilla of speedboats operating and maneuvering in an orchestrated fashion.
The Developer Division as a whole ships a range of products and services, including Visual Studio, Visual Studio Online, Team Foundation Server, Release Management, and TypeScript. Other groups at Microsoft, like Windows, Office and Bing, are separate, but all of them are in various stages of an Agile transformation. The Developer Division is leading the Microsoft charge to become Agile. It owns the “first party engineering system charter” (IES) and is driving that across the company. There are monthly scorecards on how the big divisions are doing in adopting it.
“We are very much a Scrum organization,” says Aaron. “If you observed a day in the life of a team, you would see a daily stand-up, in a team room. You would see sprint planning. We have implemented Scrum at scale.”
Can Big Corporations Be Truly Agile?
Four years ago in July 2011, when Microsoft corporate vice-president, Brian Harry, announced a corporate commitment to Agile in a blog post that was almost a love-letter to Scrum, many were skeptical. Was it conceivable that a giant firm like Microsoft could become truly Agile?
The co-founder of Scrum, Ken Schwaber, spoke for many when in a blog post he questioned whether a big corporation like Microsoft would ever able to emancipate itself from the bureaucratic tendency to “view people as assignable, parsed, optimized resources.” Just as only a very small percentage of US adoptions of Lean manufacturing reflect its core principle of “respecting, valuing and engaging the workers,” would the commitment to Scrum announced by Microsoft be a commitment to the outward forms of Scrum, but without its values? Would this be the same old “predictive manufacturing model, wrapped in Scrum tools,” that would be unable to generate creative, sophisticated, quality products?
Happily, we can report from our site visit in July 2015, four years later, that Agile values are alive and well in the Developer Division of Microsoft. The division is not only implementing the regular practices and methodologies of Agile, Scrum and DevOps for itself but also promoting them for others. Everyone we talked to—including unscripted conversations with the developers—is living, thinking, talking and acting with Agile values. 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.
Autonomy, Mastery and Purpose
A guiding light for managers like Aaron is Daniel Pink’s book Drive. The commitment to creating a workplace characterized by autonomy, mastery and purpose is explicit. That implies a balance of power between management and team-level work that is quite different from top-down bureaucracy, where people are treated like things and no one grasps that the term “human resources” is an oxymoron. In the Developer Division, managers help create the common understanding of purpose, roles, teams, cadence and vocabulary, while also creating the space where the members of teams can be truly autonomous, contribute their own mastery and genuinely own the work.
In this “new industrial revolution,” teams have the autonomy to be the masters of the features they deliver and a virtuous cycle can be seen where a more effective and engaged workforce operates faster, with better quality, is more readily able to connect with and understand customer’s needs and respond faster so customers are regularly delighted.
The connection to the customer is close and interactive. The Developer Division maintains an on-line list of requested features so that customers and developers can carry on a conversation about and even vote on. So the product evolves with continuous social inputs from their daily users. In cloud-based software, it is also easy to measure the adoption and use of features to keep track of, and guide, the direction of product development.
During the site visit, we spoke with one developer, an engineer team-member who has been on board for the entire journey, with both experience in the old ways and the new. We asked him: “How has this transformation gone for you?” He answered candidly, as engineers are prone to do, “Not always easy.” We followed up, “Would you go back to the way it was before?” His reply was instant and emphatic: “No way!”
The Commercial Imperative To Go Agile
The commitment to Agile is driven by commercial necessity, not just a recognition that it generates more vigor, energy, vision and vitality in the workforce and that it is after all a better way to get work done. The days when new releases of software were delivered in a box every few years are gone. Now software is delivered online with updates in weeks or months, not years. In order to keep up, Microsoft had no choice but to go Agile.
Back in 2010, there were already pockets of Agile within the Developer Division. Aaron himself was all-in—a “true Scrum believer,” even as the organization was still doing things the old way. There was talk of being more agile, but it was just talk. It wasn’t working.
There was a growing realization across the division that they had to do things differently. Then Brian Harry, the corporate vice-president, decided that they were going to go Agile. He saw the need for change. “Do it,” he said, “and report back and tell me how it goes.” He didn’t try to manage it or control it. He let the developers make it happen. And it grew from there.
The Way Things Used To Be
This was a huge change for Microsoft. In the past, the production cycles would be two or three years, not three weeks. For six months or more, the developers would write specs and develop a beautiful plan. They believed they knew what to build and, what’s more, they knew that they were right. They knew exactly when the product would be ready.
But it never was. They never shipped on time. They always felt that they were going to ship on time. “This time is going to be different,” they would say to each other. But it never was.
There would be two distinct phases: a coding phase, and then a test-and-stabilization phase. They would have a big celebration at a milestone which they called “code complete.” They would hold a big party, because it was a big achievement. They had written all this code! Amazing!
It was when they moved on to testing and stabilizing and delivering the beta version of the code that the trouble started. They would find an unexpectedly large number of bugs in the code. And they kept discovering more bugs. They would also get feedback that some of the features they had built were not quite right. But now they had no time available to deal with these issues, since they were so busy fixing bugs. So the issues would become change requests to be dealt with in the next release, still several years away. “It was a train wreck,” says Aaron. “A death march. Long hours. Weekends. Crazy. Employee morale was in the toilet. Nobody enjoyed that.”
What they hadn’t realized in those celebrations at the end of the coding phase is that they were actually sitting on top of a mountain of unresolved quality problems. They had no idea that instead of a huge achievement, they had just incurred a massive amount of technical debt. And yet here they were, celebrating! In retrospect, says Aaron, it was ridiculous, but that’s how it was.
The real moment of truth came in 2010. Aaron’s team had been working on a product. They had worked intensively and they felt they had done really well. But when they looked around and compared their work to what was on the market, they saw that what they had produced was like a bicycle while their competitors had produced Ferraris. That’s what set off the decision to launch the Agile transformation.
Microsoft’s Agile Transformation Took Time
Aaron had begun experimenting with Agile and Scrum with his team back in 2008. About a year later, several teams began implementing Scrum, and there were other pockets of Agile in various places. In 2010, the Visual Studio Online team and the Team Foundation Server decided to “go Agile,” with all their teams operating with Scrum practices and roles in 3 week sprints, all in the same cadence. Based on the success of these efforts, in July 2011, corporate vice president, Brian Harry, publicly announced in his blog the commitment to Agile and Scrum. In late 2011, the entire Developer Division decided to “go Agile.”
By July 2015, Visual Studio Online was in week #1 of sprint #87. The three-week sprints continue in a steady rhythm, through holidays and corporate upheavals, come what may. Over the holidays, it’s just a lighter sprint. The teams like the rhythm. They like the balance that it brings.
But the Agile transformation journey was anything but a straight path from A to B. Introducing the practices of Scrum—sprint planning, backlogs, daily stand-ups, retrospectives—were only part of the challenge. More important—and difficult—was the shift in mindsets for all involved.
It is a journey and the journey never ends. The journey is neither a train wreck nor a tale of unbroken triumph. It’s more like ups and down. They did some things right and some things wrong. There are places where they have improved.
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. “In reality, we were running three-week milestones,” says Aaron. “That’s all they were. We would get to the end of a sprint and a team would claim that a feature was done and be celebrating and then you would go and try to use it and it wouldn’t work. The team would say, ‘Oh, we didn’t do the set-up and upgrade for it.’ And we would ask, ‘I thought you said it was done?” And they would reply, “Well, yes, it’s done. We just didn’t do the setup and upgrade.” It took a long time for everyone to grasp that we needed to get fully done in every sprint.”
It took about a year to get through the transition of learning really how to do it. “You do something,” says Aaron. “And you find it doesn’t work. So then you agree: we shouldn’t do that anymore.”
Like, “Let’s not be date driven, let’s be value driven. Let’s ship the product when it’s ready. We learned not to change ship dates based on external events. We follow the rhythm of the sprints. The cadence stays consistent always.”
If there is a problem, the team fixes it if they can. If they can’t, they just don’t deploy that feature. The team decides. The team does its own stress testing and documentation.
“It felt awkward and weird for a long time,” says Aaron. “For a lot of people, it was very disruptive. But it doesn’t feel weird any more. Now it’s part of our DNA. It’s just the way we work.”
The Agile Workplace
What was visually striking in the site visit was the physical space, which were dramatically different from traditional workplaces. With open space, fresh, vibrant colors, comfortable meeting rooms, and multiple variations and opportunities to encourage collaboration in a pleasant and informal atmosphere, along with pervasive “information radiators,” the physical space looked and felt Agile.
All the individual offices, including those of senior managers, that formerly occupied the windows have been replaced by team rooms with mobile desks, and the entire space has been reconfigured in unexpected shapes and patterns. (Interestingly, the buildings we saw were the second iteration of office redesign. The first was for complete open space, which they found to be ineffective. One unintended outcome was a “library effect,” where people felt discouraged from having open communication.) The current iteration is being expanded to other buildings in the Microsoft campus.
The sight of senior executives routinely sitting at mobile desks of exactly the same size as the most junior staff member is a powerful visual signal of the shift from a top-down, authority-based culture. The implicit message here is clear: Anyone can talk to anyone.
The physical arrangements also become a powerful recruiting tool. These workspaces are “cool.”
“It takes time,” says Aaron. “We are already five years into this. We didn’t make all these changes at once. The physical space change is one of the last changes we’ve made. If we had moved into a team room, put all the disciplines together, tried to do three-week sprints, it wouldn’t have worked. It has to evolve. People need that time to let it evolve. Emotionally, it takes time. You can’t make all that change at once.”
Agile at Scale at Microsoft
Doing Agile and Scrum in a single team or even a couple of teams is one thing. Doing Agile and Scrum in hundreds of teams that have to coordinate their world is a whole different ballgame. How are dependencies handled? How do the teams keep in sync? How does management know what’s happening if the teams are autonomous? I will discuss these issues later this week in Part 2 of this article: “Microsoft’s Sixteen Keys To Becoming Agile At Scale.”