Earlier this week we, the Developer Division at Microsoft,release a series of short videos telling the story of how we made the transformation from our old waterfallian ways to a scaled agile way of working.

Here is where you can find all of the videos.

This is the story of a division of 3,000+ engineers who had been following a well defined waterfall approach for years, even as we were advocating Agile and all of its virtues. In truth, we weren’t the hypocrites that statement indicts us as. In fact, we had small agile teams popping up all throughout the division for years. In true agile fashion, the momentum grew as more and more small teams saw the value in Agile. We had many small agile teams working within a waterfall framework. As the momentum grew we decided to make a change.

I love the was Soma (S. Somasegar, our Corporate VP) puts it when he talks about how he made a decision about Agile. He says the decision he made was not to implement Agile, it was top not stop teams from trying Agile.

As our business needs changed and the need for our release velocity to increase, Agile gained more momentum, until a few years ago when the momentum had grown enough that we decided to formalize Agile across the division. That meant getting the entire division onto the same sprint schedule (we have 3-weeks sprints, and all teams start and stop sprints on the same day). Over time we moved into a new building that was designed with Agile teams in mind (team rooms, focus rooms, etc.).

Today we are on sprint #66 and we have had countless releases since we began this transformation, including releases of Visual Studio Online every three-weeks, and internal releases of the Visual Studio clients, to several public releases of Visual Studio (2012, 2013) and related updates.

I encourage you to check out the video series (rather than have me retell it here). There is some great insight shared by my peers and me, and lots of footage of how we work, where we work, and what we do.

Here are links to the individual videos in the series.

History

Everything we do around development — collaboration, testing, and customer feedback — has changed.

Waterfall vs. Agile

Today, we think about how fast we can translate an idea into reality, and get it into customers’ hands.

Visual Studio Transition

We needed to work more incrementally, deliver to customers faster, and let feedback make the product better.

The Agile Shift

We didn’t decide we were going to be agile starting tomorrow. There was gradual buy-in with teams and leadership.

Physical Transformation

We moved out of our individual offices, and put teams together into the same room.

The New Normal

We need to make sure we’re hearing our customers, and learning from them as we’re building the software.

Employee Response

We’ll talk about what’s working and what’s not working… the idea is continuous improvement.

Measuring Success

We need to know that what we’re building scales for software teams around the world.

Takeaways

Your software development efforts have to aid your business. That’s why they are there.