As mentioned in the last post in this series, Don’t Go Chasing Waterfalls, Microsoft was dealing with a plethora of issues in early 2000’s utilizing the Waterfall methodology in their product development. Aaron Bjork, a group program manager in Microsoft’s Developer Division, postulated that the move away from Waterfall was largely driven by commercial necessity, where Microsoft needed to move smarter and faster while focusing on their customers if they were going to remain relevant.
But move to what? And how?
Many startups and some of Microsoft’s peers – including Google, IBM, and Apple – were already using Agile and Scrum to guide software development projects with success.
At a high level, Agile is a methodology for developing software that delivers potentially shippable working code in short iterations, while providing the flexibility to manage uncertainty and adapt to changing requirements. It works by breaking software projects down from large feature sets into smaller bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two-week iterations called sprints. Analysis, design, coding, and testing are continuous activities that continue for the duration of the project.
The primary measure of success at the end of each sprint is working software. And the rate at which teams can turn their customers’ wishes into working software is how Agile practitioners measure productivity.
From a historical perspective, the Agile methodology was designed as a solution to circumvent the pitfalls associated with Waterfall, i.e. the de facto software development process since the beginning of software engineering in the 1960’s. The primary benefits of using Agile over Waterfall include greater ROI with incremental return, faster time to market with greater adaptability, greater visibility, and higher quality.
Another important aspect of Agile is that it’s a framework rather than a defined process. Because of this, you can customize it to meet the specific needs of your organization, team, and clients or customers.
Aaron started experimenting with Agile and Scrum with his team 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 start using 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 was using Agile.
By July 2015, Visual Studio Online was in week #1 of sprint #87. The three-week sprints continue in a steady rhythm, which provides balance and excitement within the teams. But the journey they set out on – transforming Microsoft development with Agile – was anything but easy. The introduction of the Scrum practices – sprint planning, backlogs, daily stand-ups, retrospectives – were only part of the challenge. More importantly was the shift in mindsets for all 4,000 staff in the Developer Division.
Many of the designers, developers, PM’s, QA testers, and analysts were not thrilled with the change because it seemed too unpredictable and so different than how they had done things before. But the slow introduction of Agile over the course of about 7 years allowed the company and teams to gain comfort with the new methodology, as well as to determine the best ways to implement and optimize Agile that would meet both their internal needs as well as those of their customers.
Now there’s a recognition that Agile generates more vigor, energy, vision and vitality in the workforce and it is a better way to get work done. The days when new releases of software are 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.
And still to this day Agile values are alive and well in the Developer Division at 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. The developers have fully embraced Agile and it’s seen in their daily 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. Now Microsoft can focus on delivering better products to their customers, as well as enabling their organization to be nimble enough to lead their markets and destroy the competition once again.
And somewhere Steve Ballmer is running around the stage like a madman.