Comparison of Them — DevOps, Agile, and Scrum

Published in

Strategio

7 min readJan 23, 2023

Forewords — Why are we making this Comparison?

The most important thing: such a comparison is just for clarifying and deep-diving the knowledge, not for building borderlines. They are all perfect ideas in the modern IT world; the more crucial is how to use the right tool in the proper scenario.

From the pain points to the revolutions…

I know, it will be a challenge for you if your team asks you for a comparison of these three concepts. You might think: “Wait, there’s no way to distinguish them — they are just some cultures, methodologies, or even preferences… Some are even covering each other. Why do I have to do this?” However, that’s what we “professional people” should do: tell our team which tool might be the sharpest one on the specific condition, with the truth of how well we understand our toolbox.

When it comes from the waterfall

Yeah, the waterfall. It might be a glace about how the world moved from the industrial age to the internet age, since this method — a super linear process — looks like the logic from traditional engineering and manufacturing.

Initially, the software developers and their managers were using this way to implement products or services for their customers. However, with the world getting more connected, along with the expending of the virtual side, two gaps are exposed.

First, customers found out one thing:

“We need faster and more continuous innovation!”

And that also makes one stage of the SDLC — requirement analysis — ask for more frequent communication with an “agile” development team, which could react to the requirement changes more rapidly and confidently. However, with the traditional waterfall method, changing requirement documents frequently made developers very frustrated:

So that’s the first gap: the gap between the Line of Business and the Development Team.

And when the Development Team got faster (after Agile was introduced, we’ll explain more below), the Operations Team found that their culture of “Being stable for being less risky” could not fit the fast-moving Development Team, which could be explained by the “Wall of Confusion”:

So at that point, the two teams found a gap between them: they had different working cultures and KPI factors, resulting in a conflict between their department-scale partial targets.

Fill in the gaps: Agile and DevOps

I’m a problem-solving person, so I really like the logic when the forerunners were facing the two gaps — In my own words: “Where there is a problem, there is a revolutionary way.” Gaps are problems, so they tried, and did excellent work to solve them.

The first gap was solved by the Agile methodology. The 12 rules that first defined the Agile Manifesto (Link: Principles behind the Agile Manifesto) allowed the development team to communicate with other departments and customers and react to changes efficiently. Frequently changing the requirement document is still a bad practice in most scenarios, but it won’t bother the development team as much as it was (However, it’s still a lot, so a good requirement analysis and planning at the beginning is still critical).

The second gap was solved by DevOps. As the image mentioned above, there was a “Wall of Confusion” between the two parts, and the task for DevOps is to break it. One interesting thing is, there wasn’t a solid public definition like the Agile Manifesto, so every company will show some different points in the resources in the DevOps docs:

AWS — What is DevOps?

Atlassian — 5 Key DevOps principles

IBM — What is DevOps?

There was a company used two concepts to explain DevOps:

D2O, which means Dev to Ops, is the traditional meaning of DevOps which also mentions the problem it was solving.
E2E, End to End, focuses on the process from planning, through development and finally to the operation tasks — the loop of “plan, code, build, test, release, deploy, operate, monitor.” There was a joke mentioning the update of DevOps: “Dev&Ops -> Traditional DevOps -> BizDevTestOpsSec -> Modern DevOps.”

After the inventive exploration and development of Agile and DevOps, the two gaps got increasingly filled. There might be many smaller and deeper gaps in the bigger gaps discovered and stated to the industry, but the update of the methodologies will always continue.

Wait, did we forget… SCRUM?

YES! because we have to introduce Agile before talking about SCRUM.

The reason is: Traditionally, SCRUM is actually considered a practical methodology of Agile, or we could say SCRUM itself is an Agile process/Agile framework. It focuses more on the human side, by grouping up the knowledge from everyone in the team, and dividing a project into sprints to ensure continuous delivery, especially delivering the value incrementally in a collaborative way.

What is Scrum?

Fun Fact: Scrum also means a rugby method of restarting play, and you could find a lot of connections between the two “Scrum”s.

5 Interesting Similarities between Rugby Scrum and the Agile Scrum Methodology

As someone who experienced Scrum, I could say that it fits me a lot: one daily standup meeting is excellent and good enough for me to report processes, ask questions, discuss barriers, and solve each other’s problems. After that, we could still talk about everything on slack, without sitting in the same room or the virtual room together. It also makes the schedule very “Agile”.

Wrapping Up!

Now, let’s wrap up everything, with different aspects!

Definition and Purpose

Agile: An SDLC that involves constant iteration testing in the software development lifecycle, emphasizing incremental, iterative, and evolutionary development. It was made to fill the gap between business lines and development teams.

DevOps: An SDLC focusing on communication, collaboration, and integration among the whole IT process. DevOps looks forward to building the bridge between the Dev and Ops teams, and finally seeking among things before (like planning) and after (like operating and monitoring) development phases.

Scrum: A methodology that is also a practice of Agile, which is designed to fit an environment susceptible to change better. A Scrum team will try their best to achieve high efficiency, continuous testing and delivery, and great teamwork contributing to the same target.

Scope

Agile and Scrum: the business line includes communication with stakeholders, and the development process.

DevOps: planning, coding, building, testing, releasing, deployment, operation, and monitoring — From the Biz to the Ops.

Roles

DevOps: DevOps Evangelist, code release manager, automation architect, experience assurance expert(XA), software developer/tester, security & Compliance Engineer.

Agile and Scrum: Product owner, team lead(Scrum Master in Scrum), development team members, and stakeholders. There will also be an integrator, an independent testing and audit team, technical and domain experts, and an architect owner for larger projects.

Tools

DevOps: planning tools (Trello), coding tools(VSCode, Github), build tools(Gradle), test tools(Junit), release tools(Github Action), deploy tools(Docker, AWS Cloud Formation), operate tools(Docker, AWS Cloud Formation), monitor tools(AWS Cloud Watch)

Agile and Scrum: source control tools(Git/Github), continuous integration tools(Git/Github, Jenkins), team/product management tools(Agile Manager, JIRA Agile, Kanban tools)

Artifacts Created

DevOps: deployment artifacts(deb, rpm, exes, tar.gz), library artifacts(from maven, npm, pip), bundle artifacts(cloud storage, virtual machine), pipeline artifacts(Github Workflow Artifacts, Jenkins Archive Artifacts)

Agile and Scrum: product backlog, sprint backlog, product increment, extended artifacts including burndown chart, the definition of “Done”.

Benefits

DevOps:

Faster and better quality product/service delivery
Spend more time on innovation
More automation
Less Resource idle time
Greater scalability and availability
Faster issue resolution
Reduction in complexity

Agile (and Scrum):

Increased — visibility, adaptability, alignment, product quality, business value, and customer satisfaction
Decreased — risk

Specific point for Scrum:

Quicker release of useable products
Lower costs
Better employee morale
Being able to complete complex projects which could not be done before using Scrum methodology

In the End

The methodologies are still keeping updated to fit the fast-changing industry, so the concepts involved here might have a groundbreaking correction in the future.

However, that’s why we love the IT industry: we are not only enhancing along with the world, but also enhancing the world.