Achieving Operational Excellence in your Software Project Deliveries requires that you make a decision on which delivery methodology to use. In fact, it will be the backbone of the ensuing routines and processes.
In the next section, we will see why that is absolutely critical for the success of your business.
Ideally, you have two broad paths to choose from:
- Lightweight: Agile, DevOps, Extreme Programming, etc.
- Heavyweight: Waterfall, Hybrid
Agile, Waterfall, Hybrid, or DevOps?
If you are unsure of what Agile, Waterfall, and DevOps mean and how they differ from one another, we recommend you have a look at this article first. If you do not feel like it, it’s also alright, we will include links to the relevant paragraphs as we go.
In the coming sections of this article, we will offer a few guidelines that can assist you in making that decision.
2. Table of Contents
2. Software Delivery Methodology: Why Bother
Choosing a project delivery methodology will pretty much dictate every aspect of your development, testing, and delivery processes.
Here are some of the main areas that will be heavily impacted:
|1||Technical Tools||If you are using Agile, you need project tracking tools that support User Stories, Kanban boards, etc. Also, setting up a CI/CD pipeline requires specialized applications/tools as well.|
|2||Day-to-day Activities||Meetings (stand-up or otherwise), decision-making, documentation style, and team member roles can differ significantly between the two methodologies.|
|3||Skill Sets||Specifically when being a team lead, being fluent in the processes is quite essential to maintaining rhythm and discipline. Passing the necessary knowledge to the team can be a lot smoother.|
Team members also need to be familiar with the automation or integration tools (Jenkins, git, Robot Framework, etc.) if they want to use them as well as their duties and responsibilities within that framework.
|4||Terminology||The terminology used between team members and with customers can vary significantly. If you want to avoid any “translation” problems, make sure you are using the correct terms in the right context.|
But there is more at stake. In fact, the total success of your enterprise could depend on it.
Implementing the right project delivery methodology raises your chances of delivering quality projects, on time and within budget. This means:
- An edge over competition
- Happy customers and therefore more business
- A growing reputation
- Higher morale within your team
3. Agile vs Waterfall vs DevOps
Before we start, let’s take a moment to look at the three (perhaps four) contenders.
The main question is really whether Waterfall can “put up a fight” against Agile and DevOps in this day and age. If not, perhaps we just eliminate it from the list?
There is a wide acceptance within the community that Waterfall is pretty much DEAD and cannot be used in any setup.
Viability of the Hybrid Model
The Hybrid Model emerged as a compromise between Waterfall and Agile. It allowed practitioners to leverage some of the very powerful techniques that Agile introduced and retrofit them into a cherished, but seriously outdated, Waterfall model.
IMPORTANT to note that in the coming sections, whenever we state that Agile (or any other lightweight methodology) is not applicable, the Hybrid Model (and not Waterfall) is expected to fill the gap.
4. Guide to Choosing a Software Delivery Methodology
4.1 Topic Fluency
Throughout many of my discussions with colleagues and professionals, I found that impressions of Agile, Waterfall, etc. were somehow different than actual facts on the ground.
The below table summarizes those impressions.
|Waterfall||Stable, reliable, intuitive, but also rigid, old-school, outdated|
|Agile||Modern, more hype than substance, fast, silver bullet, difficult, vague, and too complicated.|
|DevOps||Magic, powerful, complicated, outlandish, and more science-fiction than real.|
Unfortunately, some of that is true while the other is not quite.
To avoid a “holy war” within your team, make sure you have a thorough understanding of the following:
The following sections will focus on the major players in this competition between Waterfall, Agile, and DevOps.
We will also attempt to describe the impact of using one methodology over the other. Hopefully, it should help you eliminate the incorrect choices.
4.2 Product Nature
There are two properties of a software product that are particularly interesting for us in this discussion: cost-of-change and iteration-friendliness.
Cost-of-change is a direct measure of how easy (or difficult) it is to change your mind about the design of a certain feature in the different stages of the Software Development Lifecycle (or SDLC).
For Waterfall-based approaches, once you are past the design phase, the cost-of-change increases dramatically as you progress from development to testing to production.
To avoid that, Waterfall-based approaches focus a lot on design and planning, which is very sensible if you have a solid set of requirements. Unfortunately, in the software business, solid and stable requirements can often be a luxury.
To remedy that problem, lightweight methodologies were invented. Their basic mantra is: ship sooner, and more often. This will help you gain valuable information about the usage of the product and the success of its current implementation.
If the measured success is not adequate, perform another iteration and so on.
By definition, low cost-of-change products can afford to ship smaller features, more often. This makes them perfect candidates for lightweight methodologies such as Agile and DevOps.
If the features are interdependent, whether by design or simply by virtue of dealing with legacy code, you can expect the cost-of-change to be high, and shipping those features one at a time is just too risky.
In this case, you would need to perform a lot of design work and a thorough impact analysis before any development. This makes Agile-centered approaches less than ideal.
Having explored some of the rationales, we can state a few rules-of-thumb:
Qualifying for Agile does not mean you can immediately apply it; at least, that’s what the 15th State of Agile Report tells us. There are other compounding factors and these will be the target of the coming sections.
4.3 Organizational Culture
Migrating to Agile or DevOps from Waterfall can be painful.
This is especially so in the case of a well-established organization that has delivered so many successful projects using Waterfall. A difficult cultural transformation would be expected if the migration was to complete successfully.
In fact, Edgar Schein, one of the most influential researchers on Organizational Culture, thoroughly discusses cultural transformation in his monumental book Organizational Culture and Leadership.
The author states that cultural transformation can only be triggered by the appearance of an existential threat combined with enough psychological safety to allow such a traumatic experience to successfully conclude.
These hurdles make two of the top 5 reasons for slow Agile adoption according to the 15th State of Agile Report:
This brings us to the next two rules.
4.4 Test Automation
Regardless of which methodology is ultimately used, a proper Test Automation Strategy and Framework must be present to support quicker, more reliable deliveries.
A published test strategy allows your team to understand:
- How software testing should be conducted
- How to use the tools and infrastructure (including any automation frameworks) available
- The industry best-practices that are being followed
- What artefacts should be produced at each stage
- The roles and responsibilities of the QA staff
- The rules of engagement with the developers and the customers
5. Final Words
Selecting a software delivery methodology can be daunting and requires thorough knowledge of the organization, its culture, the stimulus for change.
The people managing the change should expect an amount of resistance proportional to the strength of the organization’s culture.
Having said that, quick and immediate gains can be made by:
- Creating and publishing a test strategy
- Introducing automation where possible
- And moving to a Hybrid model if not already there.