To complete the discussion, this article will examine their relative strengths, challenges, limitations, and adoption in the software community.
2. Table Of Contents
3.1 Assessment Criteria
A few things to note regarding the approach we intend to take:
- The criteria used are insensitive to the variations of each method. We believe the results will remain relevant whether you are using Scrum, Kanban, Extreme Programming, or whichever preferred implementation of Agile you might have.
- The Hybrid model is not in scope for this discussion. The reader, however, will recognize this model’s challenges after carefully considering the difficulties of its roots, Waterfall and Agile.
- The assessment will look at six requirements for each methodology: accessibility, team structure and maturity, infrastructure and tools, scalability (vertical and horizontal), cost of change, software architecture and design.
4.2 Terms and Definitions
The only terms in this article that require additional clarifications are:
- Vertical scalability — refers to the ability of a delivery methodology to work on different levels, for example, on the technical and management level.
- Horizontal scalability — in this context, refers to the ability of a delivery methodology to function across different teams or project streams.
- cost of change — represents the effort you need to invest in fixing a problem or updating an existing feature, and it is the total effort to redesign, reimplement, and restest an updated version of the product.
4. Assessment of Agile, DevOps, and Waterfall
Before we continue
The first pie chart with 3% of participants reporting a non-Agile methodology presents a bleak future for Waterfall. No surprises there.
We will assess each model based on six criteria in the following sections. This assessment will allow for a fair comparison of all three and perhaps allow us to appreciate more the dynamics of Agile adoption.
- Its progression is sequential and, therefore, easy to follow. Iterations are allowed, but their use and implementation would make sense to anybody.
- Its stages are self-explanatory; we even see the same line-up across many other industries where products or services are created.
- Its roles are distinct, straightforward, and familiar. Rarely would staff need to wear multiple hats or become skilled in areas besides their immediate job.
- Process governance and management are easier compared to Agile or DevOps due to the simplicity of the setup.
4.1.2 Team Structure and Maturity
Teams of developers, testers, architects, and business analysts using Waterfall are typically compartmentalized and often work in silos.
This lack of cross-team interaction and mutual support between the different groups is one of Waterfall’s significant drawbacks.
Frequent misunderstandings, misalignments, and lack of visibility and empathy across boundaries reduce the team’s productivity.
On the positive side, Waterfall teams typically have one role per member, which leads to faster maturity, easier integration, and a gentle learning curve.
4.1.3 Tools and Infrastructure
Gantt charts, spreadsheets, and a basic source code versioning tool are the necessary and sufficient equipment to implement a solution using Waterfall.
This lack of sophistication makes the model ready to deploy and run but also highly inefficient, primarily due to the lack of automation and the dominance of manual and human intervention leading to all sorts of errors.
4.1.4 Vertical and Horizontal Scalability
These estimations would then be used to create a schedule and calculate a cost; if these do not align with the stakeholders’ expectations, resource allocation and project constraints are modified.
Regarding horizontal scalability, effort across multiple project streams or teams is still required. It is typically done via workshops, project meetings, steering committees, etc.
4.1.5 Cost of Change
cost of change in Waterfall is effortless to describe; it has been identified as early as 1970 in Winston Royce’s famous paper, “Managing the Development of Large Software Systems”.
- The fewer alternatives you would have, and
- The farther back you might need to go to fix a problem
Two critical enhancements were applied to remedy these problems.
While these measures improved the software quality produced by catching problems as early as possible, they did not have much impact on the cost of change of a bug if it managed to proceed undetected. The problem was only half resolved.
4.1.6 Architecture and Design
A typical project would contain several new features to be implemented. Once the requirements are signed off, architects and software engineers would produce architectural plans and low-level designs for the entire set during the design stage and before any implementation.
This method, a holistic top-to-bottom approach, is reliable and easy to manage because architects and engineers would:
- Be working side by side in a small team, and
- All interdependencies are tackled simultaneously.
This method is convenient and reliable but costly; any revision must go through the full feature set to determine any potential redesign effort.
This setup saw a trade-off between control and growth, to the latter’s detriment.
Agile brought improvements over Waterfall in many dimensions, and at its core is the concept of smaller, frequent releases. This modification alone requires quite some effort to explain to peers or management since, at first sight, its advantages are not evident.
On top of that, you have paradigm-shifting concepts such as the backlog and its management (called grooming), the cross-functional self-organizing teams, effort estimation through story points, Kanban boards, and team velocities.
To make matters worse, several implementations of Agile (like Scrum and Kanban) exist, making the topic seem overwhelming to new joiners. It’s even more difficult for people to decide which Agile version best fits their teams.
These attributes might explain why the top challenges cited in the 15th State of Agile Report (organizational culture, general resistance to change, insufficient leadership support, and inconsistent processes) remain unchanged year on year.
4.2.2 Team Structure and Maturity
Agile teams are supposed to be cross-functional, self-sufficient, self-organizing, disciplined, and educated in the Agile way. They usually consist of several profiles like developers, testers, architects, and tech leads.
Agile models have also created new roles, such as Product Owners and Scrum Masters.
This considerable variety of skill sets and diversity of profiles and methods make Agile teams look very different from one organization to the next.
To work together efficiently, the team must be mature, disciplined, and fluent in the Agile methods.
These properties create a complex system of interactions and an atypical hierarchical structure that varies with each group. This ability to self-organize, however, allows teams to find a comfortable setup that best suits their skills, profiles, and expertise while still functioning efficiently.
4.2.3 Tools and Infrastructure
The synergy between tools like JIRA and BitBucket and the greater adoption of Agile was perfect; these applications made Agile easier to implement, while more Agile customers allowed Atlassian to invest and grow them beyond recognition.
Another equally influential set of tools is those that support build and test automation like Maven, Gradle, Jenkins, and Robot.
Without automating many repetitive, time-consuming, and non-value-adding tasks, the overhead that resulted from smaller and more frequent releases would have overtaken any advantages the latter brought.
Conversely, fluency in these tools is now a must for Agile practitioners, thus raising the bar for new joiners and steepening the learning curve.
4.2.4 Vertical and Horizontal Scalability
The challenge with scaling up Agile is a genuine one. As one project manager once told me, Agile tells you that your feature is in the backlog, but it cannot tell you how much it costs or when it can be delivered.
Does Agile scale up quickly and comfortably?
The 15th State of Agile Report dedicated only one page to scaling up, which is not much. The report cites Scaled Agile Framework (SAFe®) as the most used method, with 37% of participants applying it within their organizations.
How successful and preponderant is SAFe? That remains an open question.
To efficiently collaborate, the customers, suppliers, project managers, senior managers, and developers must all be Agile. This requirement is much harder to achieve than it sounds since the reality is much more complex and messy than we would like it to be.
What about horizontal scaling?
Coordinating multiple project streams with interdependencies is a bit more challenging. This difficulty arises from release management in Agile (small frequent releases), where teams may run at different speeds. The team will be blocked if interdependencies exist until the dependency is resolved.
Reducing this interdependency may lead to siloing, another consequence we would like to avoid.
4.2.5 Cost of Change
With the introduction of smaller and more frequent releases, less design time is now allowed (more on that in the next section) and significantly more automation, especially around build and quality assurance.
Does this mean that cost of change has gone down proportionately? The answer would have been ‘yes’, except the introduction of so much overhead has muddied the picture quite a bit.
For example, the time it takes to run a full suite of unit tests does not heavily depend on the size of the change (unless your last user story has doubled the number of these tests!). Small changes, like big ones, have a cost.
What about the design and the short sprints? How has that impacted cost of change?
4.2.6 Architecture and Design
To manage two-week sprints that resulted in software being released into production, radical changes to the delivery process had to be made.
In addition to running automation in fifth gear, a sacrifice in software design effort (but not necessarily design quality) had to be made.
If software can now be architected and designed within the development teams (and not in s special guild), something must be changed.
The first change was that architects and senior engineers were now integrated within Agile teams. The second change was abandoning large-scale solution designs and favouring small-scale, feature-level efforts.
Two questions arise:
- How do we keep different teams working on the same codebase from implementing inconsistent software architecture and design?
- How do we ensure that an optimum software design is produced if closely related features are not designed and implemented together because they happen to be separated by a few weeks in the backlog?
This relaxed attitude toward design was counterbalanced by stricter rules and a higher skill level in software architecture. Also, technical debt management measures were instituted with the help of specialized software like SonarQube.
The emergent architecture was complex, arising from simple but strict rules applied iteratively with new features. This dynamic meant a bottom-up approach (think of complex systems like living organisms) instead of a top-down one.
So far, the result seems OK, especially since refactoring exercises (and other maintenance works) could now be budgeted at the management level but managed within an Agile team.
The assessment of the DevOps model is an extension of Agile’s in that both have the same impediments, albeit by varying degrees.
DevOps has added continuous delivery to the original Agile outputs and has brought operations under its umbrella. This supplemental sophistication rendered the complications inherited from Agile more acute.
Despite getting the people who built the software to operate it makes much sense, DevOps is no more intuitive and accessible than Agile. The profiles and skill sets are richer and more complex, and a “DevOps engineer” role has emerged.
The number of tools and services they render has also increased to cover continuous deployment, cloud support, and operations, thus also raising the bar for new joiners.
Every new generation of software project management methodology must accomplish two things. Firstly, it must provide a substantial improvement over its predecessor, and secondly, it must also work with the latest technology, such as cloud deployment, for instance.
5. What Else?
External factors almost always play a role in the success or demise of a new idea. These factors can sometimes be entirely unrelated to the merits or limitations of the concept itself.
The notions behind Agile and DevOps are no different. In addition to their implicit merits and challenges, external, equally influential factors played a decisive role in speeding up or slowing down their adoption and, therefore, their utility.
- Organisational cultures can work with or against Agile adoption. To understand that, we can try answering the following questions. How does management value time? Do executives look towards the future or the past? Is the objective long-term growth or short-term profit? How is the risk of failure perceived? For instance, if your organisation focuses on short-term gain, you will have difficulty convincing them to invest heavily in Agile or DevOps. This attitude towards change is one of the reasons why Agile has not yet dominated.
- process management and governance are vital for executing large-scale, high-risk, high-impact change. With inconsistent or poor production processes, it would be challenging to implement Agile with all the strict discipline it requires to succeed. Excellent Process governance is another requirement that Agile adopters must satisfy.
- A hybrid working model is now a tangible reality that will stick with us in the future. This new model, along with the highly problematic and unforeseen events of the last few years (as of 2022), has placed tremendous pressure on organisations, and not all have emerged victorious on the other end. Those who were resilient enough and could adapt more easily had higher chances of seeing it through. This strive for survival has pushed people to investigate new ways to improve should a new disaster hit.
5. Final Words
If this article were trying to deliver a message, it would read like this. Despite the obsolescence of the Waterfall model, Agile and DevOps are not silver bullets, and the question of which methodology is best suited for your situation is far from evident.
6. Further Readings
- A talk on Clean Agile, Back to Basics — Robert (Uncle Bob) Martin.
- A lecture on Agile architecture — Allen Holub.