How Microsoft Disrupted Microsoft: Don’t Go Chasing Waterfalls (Part 2 of 3)
As mentioned in my previous blog The Beginning of the End, in early 2000’s the product development at Microsoft was in a state of chaos. Even with some of the most talented software developers and engineers in the world, Microsoft simply could not develop great software. Aaron Bjork, a group program manager in Microsoft’s Developer Division, acknowledged at one point that “we were building bicycles while our competitors were building Ferraris.”
Let’s take a closer look at the issues that Microsoft — and many other large-scale development organizations — faced developing software for a large public-facing customer based utilizing Waterfall methodology.
1. Internal Focus
Waterfall was originally developed as an internal process that focuses very little on the end user or client involved with a project, and instead focuses on helping internal teams move more efficiently through the highly structured phases of a project, which can work well for certain organizations.
However, the best products are typically built not only with end users as the central focus, but also with their heavy involvement for discovery, testing, and feedback.
Without this external focus Microsoft was flying blind with Waterfall from day 1, perhaps propelled by their own success. And if you’ve been drinking the Kool-Aid for too long, you start to think that you know what’s best for your products. Their thinking must have been along the lines of “Why the hell would the end users know more about the product than the developers of the product??”
2. Broken Discovery Phase
Imagine starting a business without doing market analysis, or buying a car without taking it for a test drive. Both scenarios would often end badly. But that’s exactly what Microsoft was doing early in the development phase where they focused on requirements gathering as a largely internal process.
Secondly, their product development lifecycle was taking 3 years from start to finish, and all of Microsoft’s assumptions about their products would have radically changed in the past 3 years. The general rule of thumb for validating assumptions is that the results will remain true for about 6 months. Even if they had the right external focus during the discovery phase, most — if not all — of their product assumptions would have been wrong by the time they launched a product.
Read more about the Discovery Phase: The Top 5 Reasons That 90% of Companies Fail at Product Discovery
3. Impossible to Change Scope
Waterfall is based entirely on following a set of steps that keep teams always moving forward.
The methodology — in its traditional form — leaves almost no room for unexpected changes or revisions. And as time went on, Aaron and his team were finding more and more features that were either built incorrectly or were no longer needed. His teams had diligently followed the steps of Waterfall nearly to the end of the project, but encountered many unplanned problems that necessitated a change in scope or goals, where pivoting became impossible. They thought they were building software correctly, spending almost a year and a half to two years developing a well-thought project plan using very specific, rigid assumptions. And then realizing after two years of work that these sudden scope changes would render much of the work they’ve finished useless, which often forced them to make many difficult decisions regarding features — often delaying features until releases years in the future.
4. Testing Failures
Microsoft — in following the Waterfall methodology — waited until step four out of six to test their products. This was extremely risky because Microsoft had major deadlines to hit, all of which were coordinated with their marketing department to coincide with with major announcements, product launches, and distribution. Most of the time the testers
wouldn’t get the code until well beyond the original deadline, which resulted in testers rushing through their tests and often overlooking a series of smaller bugs that led to bigger issues once deployed to millions of users. And this led to many product launch failures… anyone remember Windows Vista? Windows Vista launched in November 2006 after Microsoft’s still popular OS Windows XP. The OS became a huge disaster because of its massive scale of unnecessary features, extreme slowness, hardware and software incompatibilities, high cost, confusing versions, security fumbles, and other additional points of failure.
Microsoft knew they had to change to stay relevant and be able to produce software that was useable, feasible, and valuable to their customers. But how?
