Introduction to the two project management styles
Modern project management styles within the IT and software development disciplines are usually variations on two basic concepts: the upfront requirements gathering method (Waterfall) and the iterative or continual requirements gathering method (Agile). While these processes have evolved and improved over time, both Waterfall and Agile methodologies lack the critical perspective—they don’t take account of or leverage the production environment on which the application runs.
The Waterfall methodology has the benefit of managing risk and ensuring that requirements are well composed from the beginning, however, teams working under this methodology are less able to be responsive to the changing needs of the business. Waterfall also adds a significant amount of time from the inception of a project to delivery of a working system due to the need to gather a full set of requirements before starting development work.
As a response to these limitations, Agile frameworks were developed for technical project management. Agile methodologies (such as Scrum, XP or pair programming for example) aim to lower the barrier of entry for projects by focusing on iterative design and requirements development, along with iterative delivery of smaller, more focused pieces of software that, in the end, add up to the sum total of the intended application. This methodology is also more responsive to the changing needs of the business and reflects the fact that some requirements are not articulated or understood until the system is already under development.
Limitations with change management
Agile has been well accepted and adopted within software development teams in many businesses. However, it soon became apparent that the process of releasing changes or updates to production environments still followed a gated, waterfall-like process, as the release would be handed over to the operations-focused IT team to handle the change. This slowed down the process and defeated many of the benefits of Agile development.
The response to these limitations is DevOps, a literal combination of “Development” and “Operations” but also encompassing quality assurance testing. It emphasises collaboration within different IT groups as well as advocating the automation of software delivery. The aim is to establish an environment where building, testing and releasing software can happen rapidly, frequently, and more reliably. It shifts the focus to delivering business value through feature velocity – the ability to deliver functional software quickly.
The shift to DevOps
The shift in moving to a DevOps-oriented view of systems development and management requires that teams align according to the products they are working on rather than by technical or functional discipline. Historically, software design and production environments are owned by two disparate teams; so removing the separation between Development and Operations gives developers the responsibility for the operational system and gives operations teams the ability to influence and work within the development lifecycle.
DevOps is not just a realignment of teams; it is also a cultural shift. To be successful, businesses have to be able to take advantage of this shift. Change is hard and is something that people generally struggle with. The key is to find tangible ways to help teams connect with the value of the transformation on a business, technical and personal level.
DevOps and Cloud-first strategy go hand-in-hand
As companies adopt DevOps methodologies, they gravitate toward a more programmatic and automated way of managing their technical estate, and naturally move towards a cloud-first strategy. The culture of continuous development, agility, and fast delivery marries very well to cloud computing. A streamlined development programme that can respond quickly to changing business requirements also needs infrastructure that can move fast too. By nature of an API-first approach, the cloud offers automated provisioning and scaling, in other words, the flexibility that DevOps needs.
It is no coincidence therefore that businesses which are fast to embrace DevOps are also moving their infrastructure to the cloud. After such a move, businesses become more agile, more responsive to change and able to deliver a better product to their clients. This enables them to keep ahead of the game in the ever-changing market landscape.
How to tell when it is time to use DevOps
Many organizations look at the concept of “shadow IT” as a generically “bad thing” as it relates to the IT function within a company becoming decentralized. This can be true but the reality is that this “shadow IT” function exists within companies primarily as a means to an end. Business units and teams, in general, want to move forward and when the centralized IT function cannot deliver value to the business fast enough or at an appropriate level, business units will generally go and hire their own technical staff in order to achieve their outcomes. Although this is a simplified view, the core problem is not that the business is attempting to make reckless choices to undermine technical teams. Rather, it is an indicator that the business has pressure on it to perform and the need to move faster in the development cycle than the centralized IT function of a given organization can offer.
The solution becomes clearer when looked at from this vantage point: it’s time for the centralized IT group to undertake an effort to better understand their customers (internally) and work to help them deliver value rather than blocking their progress due to their current tools and processes. Rather than continuing to simply be a ‘service provider’ within the organization, technology can serve to deliver value. In an ever-growing digital world, the ability to translate this capability into value for the company is, after all, one of the major reasons the DevOps movement is so strongly rooted in automation.