Commentary
2/28/2017
09:00 AM
Mark Thiele
Mark Thiele
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS

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.



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.

 

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 ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Email This  | 
Print  | 
RSS
More Insights
Copyright © 2019 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service