The nature of the technology business is forward-thinking. It focuses on the future and what’s coming next. Innovations and creativity in our world of software development strive to improve the status quo and increase customer satisfaction through speed and increased connectivity.
Yet, while it’s exciting to see enterprises embrace new ways of thinking and advance their processes with cutting edge technology, it rarely happens rapidly or even simultaneously across all industries.
For most organizations, the adoption of new technologies is a slow process and the larger they are and the longer they’ve been around, the more time it takes to make significant changes.
What does this mean for the advancement of the software development industry? It means that solution providers need to assess not only where the market is going, but also the reality of where organizations are today. We must stop looking at development styles as segmented disciplines that organizations progress cleanly from one to another and instead support hybrid approaches.
I was recently asked about this in an interview with Alan Shimel on DevOps.com. While our industry has a spotlight shining on DevOps, both Waterfall and Agile development approaches are still popular and represent a significant number of Fortune 5,000 organizations.
Waterfall is by no means an obsolete practice, though we often make references to it such as, “back in the days of Waterfall development,” or “Waterfall, the grandfather of DevOps.” Agile and Waterfall are often pitted against each other with the speed of Agile emphasized and the simplicity and control of Waterfall highlighted.
There are some who make compelling arguments as to why for some situations Waterfall is still a more trusted approach to development. These reasons usually resonate most with organizations such as financial services or healthcare industries with strict regulatory considerations.
In highly regulated industries where security, compliance and scalability are main concerns, an Agile makeover or implementation of DevOps principals may seem like a risky move even though Agile and DevOps have been proven to improve and support security and requirements.
No doubt with new projects these organizations need to pick up the time-to-market speed and are generally moving away from Waterfall, but it’s not a quick process. A Waterfall approach may make the most sense on a project where the team’s culture and skill set are more traditional and the requirements are unlikely to evolve.
CollabNet is fully invested in both Agile training and educating the market regarding the adoption of DevOps practices, but at the same time we truly believe in the importance of meeting our customers where they are at. And many are humming along with Waterfall methods in place.
As Alan pointed out in our DevOps Chat conversation, for many of these customers Waterfall is working out just fine and believe it or not, with a good foundation in place—Waterfall or Agile—executing a DevOps strategy is a straightforward next step.
Many large organizations in fact will have a number of different types of development throughout the enterprise and managers must be flexible. We support customers with hybrid development environments. It doesn’t always have to be one way or the other, in fact, imposing a single style of software development enterprise wide won’t necessarily solve the challenges of having a fractured and disparate development environment.
The need for agility will regularly confront the need for stability and vice versa. Some projects will remain inherently best suited for one development style versus another, and sophisticated organizations will adopt filters to match processes to a project, or to a project’s phase. At the end of the day, no development team or development process is the same. Agile and Waterfall are two methods, and many teams select to work with a combination of processes using one or the other, or the large myriad of processes and toolchains in between.
While Agile adoption and in recent years, DevOps, have made great strides in enterprise IT, the fact is that in the enterprise as a whole this adoption has been very uneven. Attempting to shift workgroup approaches for the sake of participating in a unified system can possibly add unnecessary cultural and change management challenges to the mix. While CollabNet enthusiastically assists our customers in moving toward DevOps and helping them reap the benefits, development approaches don’t always need to be reconciled in order to be effectively managed.
About the AuthorMore Content by Flint Brenton