Agile and DevOps Methodologies

Learning Objectives

By the end of this page, you will be able to:

• Explain what Agile is and state its core values and principles as defined by the Agile Manifesto.
• Describe how Scrum organizes work into sprints, roles, and ceremonies.
• Explain what DevOps is and how CI/CD pipelines automate the path from code to production.
• Distinguish Agile (a development philosophy) from DevOps (an operations/delivery philosophy) and explain how they complement each other.
• Trace a feature through a real Scrum sprint and a real CI/CD pipeline.
• Identify common misconceptions about Agile being "no planning" and DevOps being "just tools."

Quick Answer

Agile is a way of building software in small, working increments (sprints), gathering feedback from real users after each one, and adjusting priorities instead of locking in a rigid plan upfront. DevOps is a set of practices and culture that connects development and IT operations so that code changes can be built, tested, and released to production quickly, safely, and automatically — usually through a CI/CD (Continuous Integration/Continuous Deployment) pipeline. Agile answers "how do we decide what to build next?"; DevOps answers "how do we get what we built into users' hands reliably?" Together, they let modern teams ship small changes frequently instead of large, risky releases a few times a year — which is why nearly every fast-moving tech company runs on some combination of the two.

Core Content

Why Agile Exists

Definition: Agile is an iterative approach to software development that delivers working software in small increments, guided by continuous customer feedback rather than a single upfront plan.

Explanation: Before Agile, most teams used Waterfall — write all requirements, then design, then build, then test, then ship, often over a year or more. The problem: by the time the software shipped, the market (or the customer's understanding of what they wanted) had often changed, and the team discovered the mismatch only at the very end. In 2001, a group of software practitioners wrote the Agile Manifesto, stating four core values:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Importantly, the manifesto says the items on the right still have value — Agile doesn't throw out documentation or planning, it just weighs the left-hand items more heavily when they conflict.

Example: A team building a note-taking app doesn't spend six months designing every feature. It ships a basic "create and view notes" version in two weeks, gets ten real users to try it, and lets what they actually ask for (search? tags? sharing?) drive the next sprint's priorities.

Real-World Example: Spotify famously restructured its engineering organization around small, autonomous "squads," each running short iterations and shipping independently, specifically so that product decisions could be validated with real listener data every few weeks rather than guessed a year in advance.

Why It Matters: Software requirements are rarely fully known upfront, especially for consumer products. Agile treats that uncertainty as a fact to design around, not a planning failure to eliminate.

Common Misunderstanding: "Agile means no planning or no documentation." In reality, Agile teams plan constantly — just in small, frequent chunks (sprint planning every 1-2 weeks) instead of one giant document at the start.

Scrum: The Most Common Agile Framework

Definition: Scrum is a specific Agile framework that organizes work into fixed-length iterations called sprints, with defined roles, artifacts, and recurring meetings ("ceremonies").

Explanation: Scrum has three roles: the Product Owner (decides what to build and in what order, represents the customer/business), the Scrum Master (removes obstacles and keeps the process running, not a traditional manager), and the Development Team (builds the software). Work items live in a product backlog (everything that could be built, prioritized) and a sprint backlog (what the team committed to build this sprint, usually 1-4 weeks). Four ceremonies structure each sprint: sprint planning (choose what to build), daily stand-up (each member shares progress and blockers in ~15 minutes), sprint review (demo the working increment to stakeholders), and sprint retrospective (the team reflects on what to improve next sprint).

Example: A five-person team pulls the top eight items off the product backlog during sprint planning, works on them for two weeks with daily 15-minute stand-ups, demos the finished "export to PDF" feature to stakeholders at the sprint review, and then discusses in the retrospective that code reviews were taking too long and agrees to cap review turnaround at 24 hours.

Real-World Example: A food delivery startup uses two-week sprints: sprint 1 ships "browse restaurants and place an order," sprint 2 ships "live order tracking," sprint 3 ships "ratings and reviews" — each sprint's priorities set based on what beta users complained about most in the previous sprint's review.

Why It Matters: The fixed rhythm (same-length sprints, same ceremonies every time) makes progress visible and predictable to stakeholders, while still letting priorities change every sprint based on new information.

Common Misunderstanding: Students often think the Scrum Master is the "boss" of the team. The Scrum Master has no authority over what gets built or who does what — that's the Product Owner's and team's job. The Scrum Master's job is to protect the team's focus and clear blockers.

Kanban: A Lighter-Weight Alternative

Definition: Kanban is an Agile method that visualizes work as cards moving across columns (e.g., To Do → In Progress → Review → Done) with a limit on how many items can be "in progress" at once.

Explanation: Unlike Scrum, Kanban has no fixed-length sprints — work flows continuously, and a new card can be pulled onto the board as soon as capacity opens up. The core discipline is the work-in-progress (WIP) limit: capping, say, "In Progress" at 3 cards forces the team to finish existing work before starting new work, exposing bottlenecks (like a "Review" column that keeps filling up).

Example: A three-person support-and-maintenance team uses a Kanban board with a WIP limit of 2 per person; when a developer's card gets stuck in "Waiting on QA," the limit prevents them from just starting three new bugs instead, forcing the team to notice and fix the QA bottleneck.

Real-World Example: Many IT operations and bug-fixing teams prefer Kanban over Scrum because incoming work (incidents, support tickets) doesn't arrive in tidy two-week batches — it needs continuous triage and pull, not sprint-boxed planning.

Why It Matters: Kanban suits maintenance-heavy or interrupt-driven work better than Scrum, where committing to a fixed sprint backlog doesn't match how the work actually arrives.

Common Misunderstanding: Kanban is not "Scrum without meetings." It's a different underlying model — continuous flow with WIP limits, versus Scrum's fixed-length, batch-based iterations.

DevOps: Closing the Gap Between Building and Running Software

Definition: DevOps is a culture and set of practices that unifies software development (Dev) and IT operations (Ops), automating the process of building, testing, and releasing software so changes reach production quickly and reliably.

Explanation: Before DevOps, developers wrote code and "threw it over the wall" to a separate operations team, who deployed and ran it — often weeks later, with each side blaming the other when something broke. DevOps replaces that hand-off with shared ownership: developers care about how code runs in production, and operations engineers get involved earlier in development. The technical backbone of DevOps is the CI/CD pipeline.

• Continuous Integration (CI): every developer merges code into a shared repository frequently (often several times a day), and an automated system builds and runs tests on each merge, catching integration bugs within minutes instead of weeks.
• Continuous Delivery/Deployment (CD): code that passes all automated checks is automatically packaged and, depending on the team's confidence level, either staged for a one-click release (delivery) or pushed straight to production (deployment).

Example: A developer pushes a small bug fix to a shared Git repository. Within minutes, an automated pipeline runs the unit tests, builds a container image, deploys it to a staging environment, runs integration tests, and — if everything passes — deploys it to production automatically.

Real-World Example: Amazon has reported deploying code to production on average every few seconds across its systems, a scale only possible because CI/CD automation, monitoring, and rollback tooling replace the manual, ticket-based release processes that dominated pre-DevOps software delivery.

Why It Matters: Manual releases are slow, error-prone, and stressful — teams often batch months of changes into one "release day," making it hard to tell which change caused a problem. CI/CD lets teams release small, individually low-risk changes constantly, and instantly roll back or fix forward if one breaks something.

Common Misunderstanding: "DevOps is just a set of tools (Jenkins, Docker, Kubernetes)." Tools enable DevOps, but the core of DevOps is a cultural shift — shared responsibility, fast feedback loops, and blameless learning from failures — not any specific product.

How Agile and DevOps Fit Together

Definition: Agile and DevOps are complementary — Agile governs what to build and in what order, while DevOps governs how what's built gets delivered and operated.

Explanation: A team can run two-week Scrum sprints (Agile) while every merge automatically triggers a CI/CD pipeline (DevOps) that could deploy to production the same day. Agile without DevOps means fast planning but slow, manual releases — the team decides quickly what to build but takes weeks to actually ship it. DevOps without Agile means fast releases of the wrong thing — the pipeline is efficient, but priorities are set rigidly and rarely revisited.

Example: A team finishes a sprint's "add dark mode" feature; because CI/CD is already in place, that feature reaches production the same day it's merged, rather than waiting for a quarterly release train.

Real-World Example: Netflix combines short, feedback-driven iteration cycles for feature decisions with an extremely mature CI/CD and monitoring pipeline (including automated rollback and "chaos engineering" fault injection), letting it ship thousands of production changes per day with high confidence.

Why It Matters: Speed of decision-making (Agile) is wasted if releases still take weeks; and fast releases (DevOps) are wasted if the team is building the wrong features. Real velocity comes from combining both.

Common Misunderstanding: Students sometimes treat "Agile" and "DevOps" as competing or interchangeable terms. They address different questions and are commonly used together, not as substitutes for one another.

Agile Sprint and CI/CD Pipeline in One Flow

Key Terms

Term	Definition	Context/Related
Agile Manifesto	The 2001 document stating four values prioritizing people, working software, collaboration, and adaptability over rigid process	Foundation of all Agile frameworks
Sprint	A fixed-length iteration (usually 1-4 weeks) in Scrum during which a set of backlog items is built	Core unit of time in Scrum
Product Backlog	A prioritized list of everything that could be built into the product	Owned and ordered by the Product Owner
Product Owner	The Scrum role responsible for deciding what to build and in what priority order	Represents customer/business interests
Scrum Master	The Scrum role responsible for removing obstacles and facilitating the process	Not a manager; has no authority over task assignment
Kanban Board	A visual board with columns representing workflow stages, used to track work items	Alternative Agile method to Scrum
WIP Limit	A cap on how many work items can be "in progress" at once on a Kanban board	Forces finishing work before starting new work
DevOps	Culture and practices unifying development and operations to speed up and stabilize software delivery	Complements Agile; not a specific tool
CI (Continuous Integration)	Automatically building and testing code every time it's merged into a shared repository	Catches integration bugs quickly
CD (Continuous Delivery/Deployment)	Automatically packaging and releasing code that passes CI, either to a staging step or directly to production	Extends CI to actual release
CI/CD Pipeline	The automated sequence of build, test, and deploy steps that takes a code change to production	Technical backbone of DevOps
Retrospective	A Scrum ceremony where the team reflects on its own process and agrees on improvements	Drives continuous process improvement

Common Mistakes

1. Misconception: Agile means the team has no plan and just codes whatever seems interesting. Why It's Wrong: Agile teams plan constantly, just in small increments — sprint planning happens every sprint, and the product backlog is a living plan that's reprioritized regularly. Correct Understanding: Agile replaces one large, rigid upfront plan with many small, frequently revisited plans, so the team can adapt without losing structure.

2. Misconception: DevOps is a job title or a specific toolchain (Jenkins, Docker, Kubernetes) you install. Why It's Wrong: Tools support DevOps practices, but the defining feature of DevOps is a cultural change — developers and operations sharing responsibility and feedback loops, not any particular software. Correct Understanding: DevOps is a set of practices and a culture aimed at fast, reliable, automated delivery; tools are how teams implement that culture, not the culture itself.

3. Misconception: Scrum and Kanban are basically the same thing with different names. Why It's Wrong: Scrum is based on fixed-length sprints with prescribed roles and ceremonies; Kanban is based on continuous flow with WIP limits and no fixed iteration length. Correct Understanding: Choose Scrum for planned, feature-driven work with clear sprint goals, and Kanban for continuous, interrupt-driven work like support or maintenance.

Comparison and Connections

Aspect	Agile (Scrum)	Kanban	DevOps
Primary Question	What should we build next?	What's the most efficient flow of work?	How do we deliver and operate it reliably?
Time Structure	Fixed-length sprints (1-4 weeks)	Continuous flow, no fixed iterations	Continuous, triggered by every code change
Key Mechanism	Sprint planning, backlog, ceremonies	WIP limits, pull-based board	CI/CD pipeline automation
Best Fit	Feature-driven product development	Maintenance, support, interrupt-driven work	Any team wanting fast, safe releases
Relationship to Others	A specific Agile framework	An alternative Agile method	Complements Agile; handles the delivery side

Practice Questions

Recall

1. What are the four core values stated in the Agile Manifesto? Answer: Individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan.

2. What do the letters CI and CD stand for in a CI/CD pipeline? Answer: Continuous Integration (automatically building and testing every code merge) and Continuous Delivery/Deployment (automatically packaging and releasing code that passes those checks).

Understanding

3. Why does Kanban use a WIP (work-in-progress) limit instead of just letting the team start as many items as it wants? Answer: A WIP limit forces the team to finish existing work before pulling in new work, which exposes bottlenecks (like a slow review stage) instead of hiding them behind a growing pile of half-finished tasks.

4. Explain why the Scrum Master is not the same as a traditional project manager. Answer: A traditional manager typically assigns tasks and controls priorities, while the Scrum Master has no authority over what gets built or who does what — their role is to remove obstacles and keep the Scrum process running smoothly, with the Product Owner and team owning priorities and task assignment respectively.

Application

5. A support team constantly receives unpredictable incoming bug reports and can't commit to a fixed two-week backlog. Which Agile method fits better, Scrum or Kanban, and why? Answer: Kanban — its continuous-flow, pull-based model handles unpredictable, interrupt-driven work far better than Scrum's fixed-sprint commitment model.

6. A team ships features quickly in two-week sprints but each release still takes three weeks of manual testing and deployment before reaching users. What is the team missing, and what would fix it? Answer: The team has Agile planning but lacks DevOps automation; introducing a CI/CD pipeline with automated testing and deployment would let each sprint's work reach production quickly instead of waiting weeks for a manual release process.

Analysis

7. Compare how "flexibility to change priorities" differs between Scrum and Waterfall, and explain why this difference matters for a product with uncertain requirements. Answer: Scrum re-evaluates and reprioritizes the backlog every sprint (every 1-4 weeks), so new information can change what's built next almost immediately. Waterfall fixes requirements at the start and treats changes as costly exceptions, so a product whose requirements are genuinely uncertain risks building features nobody wants by the time it ships.

8. A company claims to have "adopted DevOps" because it bought a Kubernetes cluster and a Jenkins server, but developers and operations still work in separate teams that only communicate through tickets. Analyze whether this company has really adopted DevOps. Answer: No — DevOps is fundamentally a cultural and organizational change (shared ownership, fast feedback, collaboration between development and operations), not the presence of specific tools. Owning CI/CD tooling without changing how teams collaborate and share responsibility means the company has DevOps infrastructure but not DevOps practice.

FAQ

Q: Is Scrum the only way to "do" Agile? A: No. Scrum is the most widely used Agile framework, but Kanban, Extreme Programming (XP), and Feature-Driven Development (FDD) are all Agile methods too. All share the Agile Manifesto's values but organize work differently.

Q: Does Agile mean the team never has deadlines? A: No. Sprints themselves are fixed-length deadlines, and larger releases can still have target dates. Agile changes how work is planned and adjusted within those deadlines, not whether deadlines exist.

Q: What's the difference between Continuous Delivery and Continuous Deployment? A: Continuous Delivery means every change that passes automated checks is ready to release with a manual approval step (e.g., a button click). Continuous Deployment removes even that manual step — passing code goes straight to production automatically.

Q: Can a team use DevOps practices without being Agile? A: Yes, technically — DevOps focuses on the build/test/release pipeline and can be layered onto Waterfall-style planning. In practice, though, most teams that invest in fast delivery also want fast, adaptive planning, so the two are usually adopted together.

Q: Why do daily stand-ups only last about 15 minutes? A: The stand-up is meant for quick status sharing and surfacing blockers, not solving problems in the meeting itself. Deeper discussions are taken "offline" to a smaller follow-up conversation so the whole team's time isn't consumed daily.

Quick Revision

• Agile: build in small increments, adapt based on feedback, guided by the Agile Manifesto's four values.
• Scrum: fixed-length sprints (1-4 weeks), roles (Product Owner, Scrum Master, Dev Team), ceremonies (planning, stand-up, review, retrospective).
• Kanban: continuous flow, visual board, WIP limits — better suited to unpredictable/maintenance work than Scrum's sprint commitment.
• DevOps: culture + practices uniting development and operations to deliver software quickly and reliably.
• CI (Continuous Integration): auto-build and test every merge, catching bugs within minutes.
• CD (Continuous Delivery/Deployment): auto-package and release code that passes CI, with or without a manual approval step.
• Agile answers "what to build next"; DevOps answers "how to get it to users reliably."
• Agile without DevOps = fast decisions, slow releases. DevOps without Agile = fast releases of possibly the wrong thing.
• The Scrum Master is a facilitator, not a manager with authority over priorities or task assignment.
• WIP limits expose bottlenecks by forcing teams to finish work before starting more.
• DevOps is not a tool or a job title — tools like Jenkins, Docker, and Kubernetes support it but don't define it.
• Retrospectives drive continuous process improvement, distinct from sprint reviews, which showcase the product to stakeholders.

Related Topics

Prerequisites

• Software Development Life Cycle (understanding SDLC phases and the Waterfall model as a point of contrast)

Related Topics

• Software Project Management
• Software Testing
• Software Maintenance and Evolution

Next Topics

• Software Project Management
• Software Maintenance and Evolution