How I Pulled Myself Out of the Waterfall

Mark Thiele hates waterfalls. Not the ones found in nature, of course, but the traditional, sequential method of software development known as the waterfall model, in which a project flows downhill from one group to another in slow, rigid stages.

Mark Thiele, Chief Strategy Officer for Apcera

February 28, 2017

3 Min Read
InformationWeek logo in a gray background | InformationWeek

Imagine you’re having a house built. You’d assume the architect is working closely with the builder, and that both are staying in touch with you to make sure your requirements are being met. Once the foundation is laid and the house framed, you’d imagine that contractors would perform various tasks -- exterior siding, drywall, electrical work, plumbing, etc. – simultaneously rather than waiting for each phase to be completed before the next can begin. You expect the house will be completed on time, on budget and with minimal defects.

Software development projects should move the same way, but a surprising number of businesses are still bogged down by the waterfall method that takes a cumbersome, linear approach to the phases of conception, design and specification, development, testing, deployment, and maintenance. This antiquated system is why so many large software projects historically have run behind schedule and over budget, and have failed to meet the client’s rapidly evolving needs.

I was an IT executive several years ago at a large biotech company that was drowning in the waterfall method and our team knew it had to stop. We instituted an early experiment in DevOps, an organizational construct that calls for software developers and operations teams to exit their silos and collaborate closely to accelerate the frequency of code releases into production.

More than a buzzword

The experience vividly illustrated why DevOps has become such a hot industry buzzword: because it really works.

The biotech firm’s waterfall development process was a tedious mess.

Application teams often worked without direct contact with operations. Any application change required a review of company and US Food and Drug Administration policies. This sometimes occurred in Dev and sometimes in Ops.

Server and storage requirements were handled by different operations teams with different schedules.

Only after the storage and server provisioning was complete would the network and security teams be brought in.

At the end of these steps, all the parties would be brought together for additional reviews.

The result: Software projects were often delayed by months, costing the company millions of dollars in lost revenue opportunities, not to mention the late delivery of product features that ultimately could help patient treatment.

Benefits: Time, money, quality care

Enter a more agile philosophy. Our first move was to increase collaboration among the development, operations and compliance teams at the beginning of a project. This alone cut two weeks off the average release-to-production timetable under the waterfall method.

We then consolidated information about infrastructure capacity delivery to remove the roadblock of that information being available only to certain individuals on isolated teams.

We simplified major infrastructure capacity delivery models to allow for more rapid allocation of capacity across network, storage, and virtualized servers.

We shed the company’s habit of lumping together multiple updates into one larger release (a defense mechanism against the slow, ponderous process for deploying individual updates). The new, faster process we put in place allowed for the release of smaller updates, which in turn, reduced the number of application, infrastructure failures and performance issues that can accompany a single large release.

We instituted uniform compliance and security requirements for most application changes, rather than the previous hodgepodge.

All of these changes led to a huge reduction in the company’s average release-to-production cycle, from eight weeks or more to less than three weeks. We improved customer satisfaction and gained back some lost revenue opportunity.

[Read Mark Thiele's recent commentary in InformationWeek, The Strategy of Speed in IT.]

As this experience showed, the waterfall no longer makes sense for the delivery of software-based projects where there is a benefit to quickly responding to customer needs and changing market conditions.

If you’re still in it, you need to pull yourself out of the waterfall too.

 

About the Author

Mark Thiele

Chief Strategy Officer for Apcera

Mark Thiele's successful career in IT spans 25 years and has focused on both operating roles and on driving cloud adoption across enterprises of all sizes. Mark has deep industry experience and extensive knowledge of the requirements of policy-driven cloud computing and drives cross-functional strategic initiatives as Chief Strategy Officer for Apcera.

Prior to joining Apcera, Mark was the executive vice president of ecosystem development at Switch SUPERNAP, builders of the world's highest-rated data centers. He is also the president and founder of Data Center Pulse, an organization created to promote best practices in the data center industry. Mark has held executive roles at HP, Gilead, VMware and Brocade and is a member of nonprofit groups including The Green Grid and Infrastructure 2.0, where he advocates for data center and cloud industry evolution.

Mark is a regular content contributor to InformationWeek, GigaOm, Data Center Knowledge and other publications. Mark also serves on the technical advisory board of several startups.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights