History of Agile: What can we learn from Microsoft and Cisco?

Written by Divine Odazie

September 22, 2021

Agile was born out of a need to adapt to changes in technology and customer demands. The Agile manifesto is a concise, four-paragraph document that outlines the Agile philosophy. It states that “working software is delivered quickly,” “responding to change over following a plan,” and “embracing feedback from users.” 

This article will explore the history of agile and what can we can learn from the agile transformation journey of two waterfall corporations: Microsoft and Cisco.

We will cover:

Why these companies embraced Agile

Before Agile, corporations had to rely on the waterfall software development method. This method began with a detailed project planning cycle. It concludes with a lengthy code assessment cycle (during which quality is measured and customer feedback is taken into account). Working in a confined waterfall environment without regular customer feedback increases the chance of project failure and results in uneven customer satisfaction.

It’s possible that the development team misunderstood the customer’s needs at first or that those needs have changed by the time the project is delivered. Features that seem great in PowerPoint presentations and charts may not work with existing processes or be too complicated to use quickly and effectively. 

In most cases, by the time the software is delivered, it has over-promised and under-delivered in the view of the customer.

Agile at Microsoft

How agile was introduced in Microsoft

In late 2014, the idea that Microsoft is agile would have come as news to some. Many had an image of Microsoft being a giant battleship that is powerful but slow to maneuver and not always customer-friendly. 

Who would have thought that Microsoft’s transformation from Waterfall to agile started as far back as 2008 when Aaron Bjork, current Principal Group Program manager – Azure IoT, began experimenting with Agile and Scrum with his team at Microsoft Developer Division.

After a year, additional teams started using Scrum, and there were other pockets of Agile in various teams across Microsoft. In 2010, the Visual Studio Online team and the Team Foundation Server (TFS) team decided to “go Agile,” with all their teams operating with Scrum practices and roles in three-week sprints, all in the same tempo. 

Due to the success of these efforts, in June 2011, former Corporate Vice President (now Technical Fellow), Brian Harry, publicly announced in his blog Microsoft’s commitment to Agile and Scrum.

Four years later, Steve Denning, author of “The Age of Agile,” a well-known book on agile transformations, published two great articles covering Microsoft’s agile transformation journey.

The first article explained how Microsoft successfully implemented a large-scale agile transformation over five years. Though it was successful, the Agile transformation journey at Microsoft was anything but a straight path from A to B. There was a lot of discomfort at first. And it took a long time before they could actually ship at the end of a three-week sprint.

How did Microsoft scale Agile?

It’s one thing to use Agile and Scrum in a single team, or even a handful of teams. It’s a new ballgame doing Agile and Scrum in hundreds of teams that have to synchronize their world. The second article from the articles as mentioned earlier, as the title stated, focused on being Agile at scale and not scaling agile — saying that there is an implicit recognition that “scaling Agile” makes no more sense than “scaling the cafe” or “scaling the legal department.”. 

At Microsoft, they had to address the question: “How do we make the whole organization agile?”. And for an organization with core waterfall methods, that was a tricky question to answer.

Aaron explained that the process works by continuously trying to get the right balance between alignment and autonomy to answer the question. 

Alignment and Autonomy 

For alignment

At Microsoft, Aaron shared that alignment happens from the top-down, ensuring people understand what they’re (management) doing and that people line up on the business goals, aspects, and why they’re trying to do what they are doing.

For autonomy

At Microsoft, Aaron shared that autonomy happens from the bottom up, ensuring people come into work every day and feel like they significantly impact day-to-day activities and decisions.

Alignment enables autonomy. Autonomy is key in building the right culture to scale agile. As we know, to successfully make agile work requires addressing both the culture and tools within an organization. 

Agile at Cisco

How agile was introduced at Cisco

Like Microsoft and many enterprise IT vendors, Cisco has long used the waterfall development methodology. However, as part of an ongoing effort to accelerate innovation, the engineering team of Cisco’s Collaboration and Communications Group (CCG), in charge of identifying market transitions in the way enterprises collaborate and deliver collaboration software, infrastructure, and more, began trying the Agile method in 2008.

According to Barry O’Sullivan, CCG’s senior vice president and general manager at the time, “Waterfall worked reasonably well but had some drawbacks. It wasn’t very efficient with a big, long development cycle and a big, long testing cycle. If we found something late in the test cycle, it was hard to go back to the start and make changes.” In many ways, the shift to Agile was a logical fit with Cisco’s culture of collaboration, both with customers and among employees.

Despite Agile’s promise, its benefits did not come in automatically as the shift from the traditional “waterfall” method to an Agile method required a change in thinking and behavior. 

As part of the shift to agile, CCG executives brought in new leaders with deep Agile expertise to guide, coach, and promote the method to make the transition easier. The executives also invested in training to support an Agile culture and understand the process and new technology tools for capturing customer feedback.

Implementing Agile across Cisco

CCG pioneered Agile at Cisco, but more Cisco Development Organization teams became interested as time went forward. CCG assisted those teams in establishing their Agile initiatives by providing guidance, advice, and support. But ultimately, CCG found itself in a circle of Agile interest and looked for a solution to help Agile scale across Cisco. 

With CCG pioneering Agile at Cisco, an engineering team in charge of supporting standard processes and initiatives in the Cisco Development Organization took it upon themselves to standardize the Agile methodology. The new initiative leader, Jack Dickranian, audited Agile sessions in CCG to learn more about the process and then developed the Agile@Cisco team, a group of Agile champions from diverse technology and business groups with about 4700 colleagues.

A Cisco example of Scaling Agile

An excellent example of scaling agile at Cisco was the challenge with the WebEx App for Samsung. In early 2014, the mobile application for WebEx Meetings came preinstalled on Samsung Android tablets. Leading up to release, despite regularly changing requirements, developers had to work swiftly to meet the deadline.

Solution

To tackle this challenge, Cisco adopted the Scaled Agile Framework (SAFe) and used an Agile Scrum structure for geographic rollout, with three sprints of 3 weeks each and a final sprint of 5 weeks.

Cisco IT and others gathered requirements and assessed the preparedness of environments, partners, and engineering and marketing teams during the planning phase. They were also using extreme programming and test-driven development to deliver simple and easy to maintain code.

The solution resulted in a 25% reduction in the quality assurance defects on the WebEx app. Because engineers checked code many times each day, the business teams could examine new features earlier in the cycle than before. Each sprint became faster than the one before it.

Word on Agile

The methodologies of “Agile” do not serve as a remedy for every possible managerial or leadership issue. The aim of “working software” as prescribed in the Agile Manifesto is simply not relevant (at least without significant modification) to many aspects of a corporation’s activities, including strategy, planning, marketing, sales, and finance.

0Shares
0 0

You May Also Like…