Software Development Lifecycle, Waterfall, and Agile

This session lays the foundation for DevOps. We walk through the software development lifecycle (SDLC) phase by phase, watch what DevOps changes in each phase, and then compare the waterfall model with agile methodology. The session ends with the roles that make up an agile team and the difference between a methodology and a method. Almost every idea here reappears later in the course when we build continuous integration and continuous delivery pipelines with tools like Git, Jenkins, and Selenium.

1.1 The Software Development Lifecycle (SDLC)

1.1.1 What SDLC Is

SDLC stands for the Software Development Lifecycle. Think of it as the day-to-day diagram of activity of a software engineer. It is the engineering process we apply to convert an idea into working software. Anyone who works in the software industry — or in any industry that builds software — is expected to be familiar with these phases and to apply this engineering process consistently. The lifecycle is not a management afterthought; it is the routine rhythm of how software gets built, from the first conversation with the customer to the software running in production.

1.1.2 The Phases in Sequence

The lifecycle runs through six phases:

1. Requirement analysis — understand what the customer is asking for.
2. Design — turn the requirements into something the development team can build.
3. Development — write the code.
4. Testing — verify the software behaves as intended.
5. Release — deliver the software to the end customer.
6. Maintenance — keep it working and improve it after release.

The phases are presented in this order in most discussions of the SDLC, and we will use this same sequence as the spine of this session.

Each phase consumes the output document of the previous phase as its input — the design phase starts from the specification document, development starts from the design, and so on. That chain of documents is why "clear output per phase" becomes one of the selling points of the waterfall model in section 1.9.

1.1.3 Reliability after Release

Once the software is deployed and released to the end customer, the job is not finished. The product has to remain available 24 x 7. That is where reliability and stability come in: you must keep the product available for the customer, which is exactly the responsibility of the maintenance phase. Many engineers think the lifecycle ends at deployment; in practice, the longest part of the lifecycle begins there.

1.1.4 Why We Study SDLC in a DevOps Course

We will not spend much time on requirement analysis as general background knowledge, because most IT professionals already know these phases. The interesting question for this course is different: what changes did DevOps introduce into each SDLC phase? Every phase section that follows asks the same question — what did DevOps add here, and why? Keeping that question in mind turns a familiar diagram into the roadmap for the rest of the course.

The repeating question of this session: for every phase — requirement analysis, design, development, testing, release, maintenance — ask "what did DevOps change here, and why?" The answers form a pattern: iterate instead of front-load, automate instead of hand-perform, and keep feedback loops short. Later in the course this pattern becomes concrete tooling — continuous integration servers, deployment pipelines built with Git, Jenkins, and Selenium.

1.1.5 Student Question: What Does "DevOps" Stand For?

The question is worth keeping because the word itself invites the wrong reading: "DevOps" sounds like "development + operations", and many newcomers so reduce it to a pair of departments working together. As the course will develop, DevOps is better understood as a set of practices aimed at a concrete goal — reducing the time between committing a change and that change working reliably in production — which changes teams, architecture, and culture, not just two job titles. The professor deliberately postpones the full answer: this session builds the foundation (the SDLC, waterfall, agile) on which that answer rests.

Real-world connection. The SDLC is not an academic exercise: job descriptions in the industry routinely name these phases. Requirements analysts and business analysts live in phase 1, architects and UI/UX designers in phase 2, developers and testers in phases 3 and 4, release engineers in phase 5, and site reliability and operations teams in phase 6. A software engineer's career is largely the story of moving between these phases — which is precisely why "familiarity with the SDLC phases" is a baseline expectation for anyone working in the field.

1.2 Requirement Analysis Phase

1.2.1 The Specification Document

Requirement analysis is the very first phase of the SDLC, and most of the problems in a software project are encountered right here. The output of this phase is the specification document: the place where you understand what exactly your customer is asking for, and where the requirements of the software get jotted down. Because this is the first phase, it sets the skeleton for the entire software. If that skeleton is wrong, everything built on top of it is wrong too — which is why this phase deserves the highest attention.

1.2.2 Challenge One: Finding a Common Language

The very first challenge is finding a common language between the people outside of IT and the people in IT. Take a normal scenario: an IT person needs to collect requirements from people in the manufacturing department who want software for their music system. Those non-IT people do not understand terminology like modular, object oriented, or microservices. Those words are simply not suitable for the non-IT audience.

A second layer of the same challenge appears when the people you are collecting requirements from are not good at English. The best strategy in that situation is to collect the requirement face to face rather than through online workshops or meetups. When you talk face to face, you understand much more — expressions carry meaning that words alone lose in a workshop format.

1.2.3 Challenge Two: Terminology That Differs between Groups

Different people use different terms for the same concept, and that creates confusion. For example, a few people call a partner a supplier, while others call the same kind of partner a third party vendor. There are many such pairs. Even within this course, delivery, deployment, and release are three terms that carry misconceptions for many people (we untangle them in section 1.6). When every group uses its own vocabulary, the requirement discussion itself becomes a translation problem.

1.2.4 The Cost of Getting Requirements Wrong

The biggest problem with the requirement analysis phase is this: if you capture the requirement incorrectly, your overall business flow becomes a mess, and the end product is not the one your customer expected. You come up with a chaotic product instead. There is a funny example that used to circulate widely — the picture comparing what the customer asked for with what we delivered. IT engineers feel like heroes after such a delivery: the team believes it did very well, and a smart business team even added extra features on top. But those extra features were never required by the customer. They are bulky, dead features — they consume capacity in your infrastructure, but nobody uses them. Then everything goes to zero: no customer satisfaction, no revenue out of the product.

That is why requirement analysis is so critical: it is the very first phase, where the skeleton of the software is created. If the customer asked for an elephant and we deliver a buffalo, the whole project has failed before a single line of code exists.

1.2.5 What DevOps Adds: Iterative Requirements

According to DevOps, requirement analysis should be handled with an iterative approach rather than by creating a bulky document in one go. You go step by step and furnish the requirements from your customer by taking frequent feedback. Small, repeated rounds of feedback replace the big upfront specification, so a wrong interpretation gets caught early instead of surfacing after months of work.

Real-world connection. The elephant-versus-buffalo failure is not folklore — it is measured. Industry research on project failure consistently ranks "requirements-related" causes (missing, misunderstood, or changing requirements) among the top reasons projects fail or blow their budgets, which is why business analyst and requirements engineer roles exist as dedicated careers. Modern approaches — like involving operations people in requirements so that logging and monitoring needs are captured at the start — are direct descendants of the same lesson: get the requirement right early, or pay for it forever.

1.3 Design Phase and the Minimal Viable Product

1.3.1 From Document to Design

The design phase starts after the requirement analysis document exists; this phase depends on it. Here you convert the written requirement document into a flowchart or design diagrams that your IT people will understand — the people who will work on this software must understand what exactly they are being asked to build. A familiar example is the CRC diagram — Class, Responsibility, Collaboration cards — which describe each class's responsibility and its collaborations. The design diagram is the bridge that turns a business-oriented document into a technical blueprint.

1.3.2 What Is an MVP?

With respect to DevOps, the design phase focuses on minimal viable products, or MVP. Before defining it formally, the room was asked what the term means to people who already knew it. The answers that came back give a good sense of the idea: a proof of concept, a pilot, a draft with the basic workable features, a prototype. The goal of an MVP varies by team — for some it is just to attract investors, for others it is to start generating revenue. All of these are valid strategies.

1.3.3 Student Discussion: Defining MVP

1.3.4 Worked Example: The Morning Routine

The clearest way to feel what "minimal viable" means is a layman example. Suppose you must reach the office by 10 a.m. — that is your timeline. If you start your day at 7 a.m., you have three hours in hand. The commute takes 15 minutes, so you actually have about 2 hours 30 minutes for your basic morning tasks: 15 to 20 minutes of exercise, your bath, preparing and eating breakfast, and getting the lunch box ready. You can do all of this comfortably and still start for the office by 9:30. The workable product here is one thing: reaching the office by 10 a.m. Everything else — brush, exercise, bath, breakfast, lunch box — is just tasks that help you produce that output.

Now change the start time to 8 a.m. You no longer have the time to complete everything. So you hunt for the minimal viable set of tasks that still delivers the product: you skip the exercise, take a brush and bath, eat a quick breakfast, and skip the lunch box — you will order something at the office.

Push the start to 8:30 a.m. and even the breakfast disappears; you skip preparing it and eating at home. In every scenario you cut down to the smallest set of tasks that still lets you reach the office by 10 a.m. — the minimal viable thing needed to deliver the workable product to the customer.

1.3.5 Worked Example: An E-Grocery App

In IT language, the same logic applies. Say you want to create an e-grocery app, and you want to start with registration first. What is the minimal viable thing you need for registration? You need a login page, and the login page must have a registration tab so people can start registering. You would not spend time on the best filtering approach, nor on a great search engine, nor on rich payment options like credit card, PayPal, Paytm, or Google Pay — you would probably start with cash on delivery and not build many features at all. Your workable product is that the customer can register. So the minimal requirement is a login page with a registration form that allows a user to register. Real-world: this is how real e-commerce and consumer apps approach their first release — one working slice instead of the whole catalog of features.

1.3.6 What MVP Means for Design

Rather than taking a bulky requirement and converting it into a bulky design document, DevOps gives more focus to the MVP: you design only what is required — the minimum that has to be delivered to achieve revenue, to attract people, to win a business case, or to give a demo to your customer. Which of those goals drives you depends on your own business requirement; the point is to decide deliberately what to build now and what to postpone.

Real-world connection. The MVP is the standard opening move of modern product companies. Startups pitch investors with a prototype, product teams ship a login-and-register slice before building search or payments, and marketplaces launch in one city before expanding. The discipline behind it — decide deliberately what to build now and what to postpone — is exactly what product managers practice every sprint, and it is the same logic that keeps the development cycle short enough for the "deliver early, deliver often" mantra of section 1.4 to work.

1.4 Development Phase

1.4.1 Building the Artifacts

The development phase is where you build the software. The coding happens here. Whatever you wrote in the specification document gets converted into code, and you generate your workable artifacts in this phase. The development work should follow a small delivery cycle so that the feedback loop stays short — which is the mantra deliver early, deliver often.

1.4.2 Deliver Early, Deliver Often

Everything in development works hand in hand with the MVP. Since you build only the minimal thing, you code less, and the coding takes no more than two to three weeks. Within three weeks you give this prototype to your customer and collect feedback. That is the mantra: deliver early and deliver often.

The same principle says to involve the stakeholders when you do your testing — give them an alpha and beta testing round so they can test it. The issues that stakeholders raise get resolved at low scale, because the code base is small. Involving stakeholders early is a good strategy for converting that idea into working software.

1.4.3 Worked Example: 500 Lines versus 10,000 Lines

Why is a small code base easier to fix? Take the example of a bug hiding somewhere in your code. If you have 500 lines of code with a bug in it, identifying that bug and fixing it is easy. If you have 10,000 lines of code, finding the same kind of bug is far harder. With the minimum scope, you identify and solve problems easily. This is what DevOps suggests: deliver often and early, and involve your stakeholders, so that issues surface while the code base is still small enough to navigate.

1.4.4 Modular Code for Ongoing Change

Whatever we build, the software has to be modular. Software is something that undergoes ongoing change — that is exactly why agile came into being, to invite changes. No matter what you do, there will be changes in your software, and to accommodate those changes your code should be modular. A monolithic lump of code resists change; modular code lets one change land without breaking everything around it.

Real-world connection. The two-to-three-week cycle and the small-module discipline are the same principles behind the service structure described in the reference material: small teams working on small, well-encapsulated, loosely-coupled pieces, so that changes are small and failures are contained. Modern version control practice (commit small, commit often) is the direct coding-level translation of deliver-early-deliver-often — and both are what later sessions will automate with Git and Jenkins.

1.5 Testing Phase: Continuous Testing

1.5.1 The Continuous Integration Server

What does DevOps suggest for the testing phase? Have a continuous integration server. Whenever you make a single-line change in your code base, that continuous integration server should trigger, pull the source code, and follow the testing cycle. The result is continuous testing — testing runs constantly, on every small change, rather than once before a big release.

1.5.2 Why Continuous Testing Builds Confidence

Why go through this effort? Continuous testing boosts confidence in your team members: they know the software is going to work well in the production environment, because every change has been verified continuously. The software that comes out of a continuously tested pipeline is more qualitative than software tested once at the end.

1.5.3 Automation with Flexibility

The continuous integration and continuous testing server performs all the testing with automation. Wherever you feel manual intervention is still needed, you should be in a position to accommodate the same — that is, keep the flexibility at the same time as doing the automation. Automation is the goal, but the pipeline should not force full automation where a human check still matters.

Real-world connection. CI servers are standard industrial equipment today — Jenkins, GitLab CI, GitHub Actions, and others run exactly this trigger-pull-test-report cycle on every commit, and "did CI pass?" is the first question a developer hears before a merge. The automation-with-flexibility balance is institutionalized in the deployment pipeline: automated stages (commit stage, acceptance tests) feed manual gates (showcases, exploratory testing) before a release candidate is approved — a structure the course textbook describes as making every part of build, deploy, test, and release visible to everyone involved.

1.6 Delivery, Deployment, and Release

1.6.1 Student Debate: Are the Three Terms the Same?

Before the definitions, the room was asked whether delivery, deployment, and release all mean the same thing. The answers came back in several directions, and it is worth keeping all of them in mind because they show exactly where the confusion sits.

1.6.2 The Definitions

Every organization runs multiple environments. You have a capacity testing environment, a staging or pre-production environment that closely mirrors production, an acceptance testing environment, and white box testing and integration testing environments, among others. The rule:

• Delivery — your code base is ready, and you push the code to your internal environments to run your testing. Pushing code into any of those test environments is delivery.
• Deployment — after testing shows the code is fit to use, you push it to the production environment. The moment the code lands in production, it is a deployment.
• Release — once the code is in production, if you make the feature it implements visible to your end user and the end user starts using it, that is a release.

1.6.3 Why We Never Test Where the Developer Worked

One point deserves repetition: we never do testing on the same environment where the developer wrote the code. The person who wrote the code already did a first level of testing on their own side in that environment, so testing it there again adds little. In industry, testing runs on the different environments described above — capacity, integration, acceptance, pre-production — and your tester engineers follow the testing process there. This is why delivery, the act of pushing code into those environments, is a stage in its own right and not the same as deployment.

1.6.4 Real-world: Facebook Live and the Six Months in Production

Real-world: consider Uber or Ola cabs — everyone has used ride-hailing apps. When these companies launch, not all of their features are accessible to the end users. Take Facebook's live video feature: the code base for live video sat in the production environment for six months before it was launched for the end user. The feature was accessible only to third-party vendors who were doing their testing, and whether users would adopt it was analyzed over those six months. After six months the feature was launched for the end users — that launch is the release. And the six months the feature spent in production, live but not user-visible, is deployment. Real-world: this pattern — code in production before the feature is switched on for users — is common in large consumer platforms, where the production environment doubles as the final validation ground.

1.6.5 Terminology Variants across Organizations

The takeaway: the environment names differ from company to company, but the process — test before production, then go live — stays the same.

1.6.6 Continuous Delivery with Manual Production Intervention

There are organizations that believe in continuous delivery: the code is pushed through the pipeline with automation into the subsequent delivery environments, like the subsequent testing environments. But when it comes to pushing the code to the production environment, they want manual intervention. So even in a continuous delivery setup, pushing the code into production is called a deployment.

Real-world connection. These three words are used daily in release engineering: release trains, feature toggles, canary releases, and dark launches all rely on the deployment-versus-release distinction — code runs in production for many users' infrastructure long before it is released to users. The textbook on the DevOps lifecycle uses the same split: code is deployed into production for live testing and close monitoring, and only after passing is it promoted to be equivalent to previously deployed code.

1.7 Maintenance Phase

1.7.1 Evolutive Maintenance

Maintenance comes after the software is deployed and released, and it happens in two forms. The first is evolutive maintenance — the name appears in some books as "evolve with you" maintenance. Say you launched one feature, and now you see you can make your product or software more fantastic or more useful by launching another feature. You are improving the functionality or adding new business features — evolving the existing software and releasing new upgraded versions. That is evolutive maintenance.

1.7.2 Corrective Maintenance

The second form is corrective maintenance. If bugs, errors, or defects are raised by your customer, you have to resolve them to make your software fit to use. You make those changes in your code base to solve those bugs, defects, or issues, and that is corrective maintenance.

1.7.3 Minimizing, Not Eliminating, Maintenance

You can minimize maintenance, but you can never totally avoid it. Following a good strategy or good process — like DevOps or agile — minimizes the number of defects. Continuous monitoring minimizes the tickets raised by your customer. But the maintenance phase itself never disappears. The DevOps view is to achieve a more proactive way of maintenance by having continuous monitoring, instead of reacting to failures after the customer reports them.

1.7.4 Student Questions: Handshakes and Enhancements

The second exchange ties a vocabulary pair together: "enhancement" and "evolutive maintenance" are two names for the same activity — improving the software with new features and upgraded releases. The handshake question, by contrast, is left deliberately open: handshake is the professor's word for the people dependency between teams (the handoff from one team to another), and its timing question belongs to later sessions on team structure and release coordination — a signpost, not a loose end.

Real-world connection. The evolutive/corrective split is standard industry vocabulary in software maintenance practice, and the proactive shift is exactly what monitoring platforms, alerting systems, and incident-response processes exist for. When a product releases monthly feature updates, that is evolutive maintenance at scale; when a hotfix ships within hours of a customer report, that is corrective maintenance — and observability (logs, metrics, traces) is the tool that lets teams catch the defect before the ticket arrives.

1.8 Case Study: From Manual Releases to Seven-Second Deployments

This case study comes from the course textbook on automated deployment and continuous delivery. It shows a team that moved from fully manual releases to a fully automated pipeline, and the numbers are worth remembering.

1.8.1 The Manual Release Checklist

The team used to do manual delivery and manual deployment. A manual release meant following a proper checklist: a document with multiple checklists where you verify whether this command was executed or not, whether the Tomcat server was turned on or not — all of that was done manually. The process had very high intervention and dependency among the development team, the tester team, and the operational team. Because of the lack of handshakes — the checks between teams — and the heavy dependencies, releases used to take a long time. Real-world: the Tomcat server check is a concrete example of the manual operations that release engineers used to walk through by hand.

1.8.2 The Automated Pipeline

That team moved to an automated build, deploy, test, and release system: continuous integration, continuous build, continuous delivery, and continuous deployment. Instead of people executing checklists, the pipeline itself built the code, deployed it, tested it, and released it.

1.8.3 Seven Seconds to Production

With the pipeline in place, the team could deploy the code base into the production environment within seven seconds. If any major bug or major defect was identified during that deployment, rolling back to the previous version and recalling the code base that had been pushed took a similar amount of time. This is how the continuous integration pipeline helped that team push code faster and be available to the market faster. Real-world: seven-second deploys with equally fast rollbacks are the speed target that modern release pipelines aim at — the cost of a bad release collapses when pushing and rolling back are both automatic and measured in seconds.

Real-world connection. Seven-second deploys are at the extreme end of a spectrum the industry measures directly: the reference material describes deployment lead times of months in traditional organizations (tightly-coupled applications, scarce test environments, manual testing, multiple approvals) versus minutes in the DevOps ideal. Today's platforms — Jenkins pipelines, GitHub Actions, GitLab CI/CD — are the direct descendants of the automated system in this case study, and "can we roll back?" is a standard checklist question in every release review.

1.9 The Waterfall Model

1.9.1 A Sequential Classic Lifecycle

The waterfall model is a sequential model — a classic lifecycle. When we say sequential, we mean that all the SDLC phases are arranged in a sequence, and we complete each and every phase once, fully, before jumping to the next phase. Once the requirement phase is completed, you move to the design phase; after design, you move on to the subsequent phases. Because it is systematic and sequential, it reflects the SDLC phases in order, and it is easy to understand and easy to follow: you complete one phase at a time, completely, and then move to the next phase. That is how the waterfall model was designed.

1.9.2 The Amendment: Feedback Loops

An amendment happened to the waterfall model: a feedback cycle, or feedback loop, was added among the flow. Once the requirement phase is done, you jump to the design phase and do the complete design. During that design work, if any concerns are raised, you can go back to the requirement phase, furnish it more, and then start the subsequent phase — implementation, then testing. So the feedback loop lets a later phase pull information back to an earlier phase instead of locking everything into one strict one-way pass.

1.9.3 Advantages

The advantages of the waterfall model follow directly from its sequential nature:

• Easy to use and follow — it is just your SDLC turned into a sequential workflow.
• Cost effective when your requirements are very clear.
• Clear understanding and clear outputs — because each phase is completely developed before the next starts, the output of every phase is a complete document or working software.
• Very little chance of rework when the requirements are clear, since the process runs in a sequential manner.
• Easy to manage the code and the project throughout.
• Documentation is well structured and well managed, because every phase finishes with a document as its output.

1.9.4 Problems and the End-Stage Risk

The problems of the waterfall model are the flip side of its discipline. It is really difficult to accommodate changes once you have started the process. Say you have completed requirement analysis and design, and the team is now in the development phase: it is really hard to bring in new changes during development, because the model is sequential. You have to wait until the product is completely developed and delivered to the customer. Only then does the customer give feedback — either corrective feedback, fixing the product, or enhancement feedback, adding to the product.

If there are any flaws or bugs in the product, or if the requirements were collected incorrectly and the delivered product behaves incorrectly, all of that is addressed only at the end, after deployment. That is where the huge risk of the waterfall model sits. In the early traditional way of working, the customer used to get access to the product, or at least see it, only at the very end stage of development. Customers visualize the product only once development is done — that is the biggest challenge with the waterfall model.

1.9.5 Worked Example: Project Timelines Then and Now

In the traditional way of working, project lifecycles used to run one year, two years, or three years of timeline to complete a project. Today the projects are very small scale, and the lifecycle of a project is two months, three months, or six months — not more than that. Shrinking timelines made the wait-until-the-end model of waterfall much more painful, because a year of waiting for feedback is no longer affordable when the whole project is meant to finish in six months.

1.9.6 When to Choose Waterfall (and When Not To)

If your requirements are unclear, or your budget is unclear, waterfall is not a good choice — no matter how easy it is to adopt, you will not get output from it. If your requirements are stable, the schedule is fixed, and you have a clear budget, it is always good to go ahead and opt for waterfall. The same logic applies when you have delivered the same kind of project many times before — for example, web development in the same domain. You already know the shape of the work, so the sequential pass is cheap.

1.9.7 Why Waterfall Is Cost Effective

When we say waterfall is cost effective, the reason is concrete: you do not have many roles and responsibilities to add, and you do not have to change your organization structure. With agile methodology, you have to create a Scrum master role, you have to have a product owner, and you have to give training to your development team to follow the agile process — all of that is cost. With waterfall, no such cost is involved; it is a kind of converting your SDLC into a sequential workflow, and that is it.

1.9.8 Student Question: Which Is More Cost Effective?

Real-world connection. Waterfall never disappeared — it is still the right tool in regulated and hardware-adjacent domains where requirements genuinely are fixed in advance (safety-critical systems, government contracts with legally binding specifications), and it survives inside modern processes as phase-gate thinking: a stage must complete and pass review before the next begins. The reference book makes the same assessment: waterfall makes sense where the cost of delivering software is high or requirements are unlikely to change — and it remains a legitimate option even inside DevOps, which evaluates methodologies by their fit rather than their age.

1.10 Agile Methodology

1.10.1 The Fears That Drove Agile

If waterfall was fine, why did agile come up? The common thinking of any developer or development team was a list of fears. The project will produce the wrong product first. The product will come out with losing quality — quality will not be very good. The project will be late, so you have to break the other commitments you made, whether that was a planned holiday or a week off. There will be more escalation from your customer, and everybody will raise fingers at you. You end up stressed out, and you do not have fun working in the team. To minimize — or rather, to mitigate — this set of fears in any development team, the storm called agile boomed in the market.

1.10.2 The Adoption Numbers: VersionOne State of Agile Report

According to the VersionOne State of Agile Report, in 2007, 94 percent of organizations started practicing agile. In 2008, it reported 97 percent. That is a growth of about 3 to 4 percent every year in terms of practicing agile. And with DevOps, it boomed again, even more. The report also shows a concrete survey — organizations from marketing, finance, medical, manufacturing, and IT domains were asked whether DevOps will improve ways of working. Both the VersionOne report and the Puppet reports are worth studying to understand where the industry stands with DevOps and agile.

1.10.3 Why Organizations Adopt Agile

When the survey asked why organizations adopt agile, the reasons came back with numbers:

• Accelerating the software delivery — 71 percent of organizations chose this option.
• Enhanced ability to manage changing priorities — 63 percent.
• Increasing productivity — 51 percent.

So the top reason is speed of delivery, followed by handling changing priorities, then productivity.

1.10.4 The 12 Principles

The agile methodology rests on 12 principles. The first one is achieving early and continuous delivery — following the iterative way of delivering software very early, often, and taking the feedback. Since we are not following a sequential approach but an incremental and iterative one, we can welcome changing requirements — that is the second principle: there is room, or scope, to welcome changing requirements. And likewise there are 12 such principles in total.

1.10.5 The Four Pillars

Agile focuses on four values, each of which is a priority statement:

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.

1.10.6 Student Question: Do We Skip Processes and Tools?

1.10.7 Working Software over Comprehensive Documentation

This pillar does not mean there is no documentation. You do have to have documentation — like a document explaining how to use your product, or the steps of the process. That is a document. But the priority goes to working software. In one iteration or one incremental cycle, you do not have a timeline to do both; you have two ways — you can complete your testing, or you can write a document. Agile says: complete the testing and be ready with the working software. The document you can do later.

1.10.8 Customer Collaboration and Responding to Change

On customer collaboration: you do not try to negotiate; your focus is on collaborating with your customer. Invite your customer to your review meetups. On responding to change: you do have a plan, but that plan changes according to the changes that come up from your customer. A plan is a starting point, not a contract.

1.10.9 The Agile Manifesto

By combining the principles and the pillars, you get the agile manifesto. The agile manifesto is your principles and your pillars of agile — the single document that both lists the 12 principles and states the four values. Waterfall was fine as a starting point, but agile is the more customer-friendly and developer-friendly methodology, and that is why we follow it.

Real-world connection. The VersionOne State of Agile Report (now the State of Agile survey) and the Puppet reports (State of DevOps) are the industry's own longitudinal evidence that this lecture cites — and the survey's top reason, accelerating software delivery, is the same goal DevOps formalizes as deployment lead time. The manifesto's four values are quoted verbatim in countless job postings and team charters, and the 12 principles still frame agile coaching practice today — which is why the professor treats the report numbers and the manifesto text as material worth studying directly.

1.11 What Agile Brings to a Team

1.11.1 Worked Example: The Traditional Question Chain

To see what agile changes, compare how a doubt used to travel in the traditional way. A project comes in, and you have a project manager, a team lead, and a development team working on the project. If any team member has a concern or doubt about developing the requirement, it used to go to the team lead in the everyday meetup. If the team lead does not know the answer, the concern goes to the project manager. The project manager talks to the customer's project manager — a counterpart who sits at the customer place. That customer manager then raises the concern to the team that raised the requirement in the first place — the team that wanted to improve their working or grab more customers. The answer then travels all the way back down the same chain to the team members.

Look at the dependencies: the whole chain is nothing but waste in your process. It increases the timeline instead of increasing productivity. Agile says: why can't team members interact directly with the customer? The customer people give the answer directly, and the chain of handoffs disappears.

1.11.2 Breaking the Wall between Business and Development

This is what agile gives your organization: it breaks the wall between your business people and your development team. Business people give the product requirement idea, and the development team converts that idea into working software. Whenever the team feels it needs feedback from the customer, the business, or the stakeholders, agile gives you the room to bring them in — to involve your customer and your stakeholders as part of the development team.

1.11.3 Review Meetings and Stakeholder Demos

In scrum language, you have review meetings where you involve stakeholders and your customer: you give a demo to your customer, discuss the feedback in more detail, get the feedback, and then act on it in your next increment cycle. The loop of demo, feedback, and adjustment is the engine of agile delivery.

Real-world connection. The question chain is not a straw man — it is the standard complaint behind every "too many meetings" and "why is this ticket in my queue" frustration in large organizations, and the wall-break is the reason agile teams sit with business representatives, product owners, and customers in the same sprint reviews. The same idea reappears in DevOps at the operations boundary: just as agile brought the customer into the development loop, DevOps brings operations into the same loop — a preview of the sessions ahead.

1.12 Agile Methodologies and Methods

1.12.1 Methodologies: Scrum and Extreme Programming

As part of the syllabus, we discuss a few methodologies. Scrum is one of them. Extreme programming (XP) is not part of the syllabus, but we will discuss a little of it because it helps you understand TDD. There are other methodologies too, but they are not part of the scope of this course.

1.12.2 Methods: TDD, FDD, and DDD

TDD, FDD, and DDD are the methods. TDD is test-driven development, FDD is feature-driven development, and there is also a data-driven method, DDD — but that is not in the scope of our syllabus. BDD, behavior-driven development, will be explained together with TDD and FDD in an upcoming session. A method sits inside a methodology; the two are different levels, as the discussion below makes concrete.

1.12.3 Student Question: Methodology versus Method

Real-world connection. This methodology-versus-method distinction is used daily in hiring and certification: "Scrum master certification" is a methodology-level qualification, while job ads for "TDD practice" or "BDD with Cucumber" name method-level skills. Teams in industry combine them exactly as the professor describes — the reference material likewise treats Scrum, extreme programming, and feature-driven development as agile methodologies, and DevOps as the broader movement that extends agile's collaboration ideas beyond development into the whole organization.

1.13 Roles in Agile

1.13.1 The Three Roles

Agile has only three roles, basically. The first is the user — meaning your stakeholders, your customer, your end user, everybody. The second is the product owner — the person who owns the product. The third is the software development team — the team working to accomplish that product, which includes developers, testers, everyone.

1.13.2 The Scrum Master Is Not an Agile Role

One correction worth noting: the software development team does not include the Scrum master as a separate agile role. The Scrum master is with respect to Scrum. If you talk about agile as such, agile has three roles: user, product owner, and the software development team. Keep the two levels separate — Scrum is one methodology inside agile thinking, and its Scrum master role does not generalize to all of agile.

Real-world connection. These three roles are the skeleton of nearly every agile team in industry: business stakeholders as users, a product owner managing the backlog and priorities, and a cross-functional development team that owns delivery. When companies adopt DevOps on top of agile, the same three-role team grows extra DevOps-oriented functions (service owner, reliability engineer, gatekeeper, DevOps engineer) — but the agile core remains the three roles, which is why the professor insists on keeping the levels clean.

Exam Guidance Summary

This course runs as practice, process, and tools rather than coding. You will learn the tools — Jenkins, GitHub, Git — and there is no coding that you have to follow for the course; you can refer to the open code available on GitHub for the labs.

The hands-on labs run on a virtual lab platform: you book a slot, and within 24 hours you get remote desktop access to a machine where the DevOps toolchain is already installed — Git, GitHub, creating a source code folder, running Git commands, creating a Jenkins job — and you just start and perform your labs. There is no limit on booking; you can book multiple times as per availability.

For Selenium specifically, the expectation is a small script, not huge coding: a demo will be held and a reference script shared — the reference is in Python, but you can write yours in Java or any language you prefer, for example automating a login page.

Study advice: do not worry about the examinations — if you attend the sessions and go through the recorded sessions, you can crack them easily. Give more attention to clearing your doubts and increasing your knowledge base. For certification-style material like agile and DevOps, go through the tutorials and documentation very thoroughly before the examination, because in industry people mold the processes to their business requirements, and that is how misconceptions get absorbed.

Key Industry Applications

The reference books are the industry's own materials. The course textbook on continuous delivery is written in line with industry experts, and you can correlate its concepts with real release engineering; the book DevOps: A Software Architecture Perspective is the better one for clearing your conceptual thoughts about DevOps.

Seven-second deployments are the speed target. The seven-second deployment case study shows a team that replaced manual release checklists — like verifying commands and checking whether the Tomcat server was turned on — with an automated build, deploy, test, and release pipeline, achieving production deployment in seven seconds and equally fast rollbacks. This is the same "deployment lead time" the industry measures to evaluate its pipelines.

Staged feature rollouts are standard in large consumer platforms. Facebook's live video feature lived in the production environment for six months, accessible only to third-party testing vendors, before it was launched to end users; ride-hailing apps like Uber and Ola also ship features that are not all accessible to end users at launch. Deployment (code in production) and release (users can use it) are separated by design.

MVPs are how consumer apps open. E-commerce and consumer apps start their first release with a minimal viable product — a login page and registration form — before building search engines, filtering, or payment integrations like credit card, PayPal, Paytm, and Google Pay; many start with cash on delivery. The registration-first slice of section 1.3 is the actual opening move of real products.

The survey reports are the industry's own evidence. The VersionOne State of Agile Report and the Puppet reports are the industry's own survey data on agile and DevOps adoption — 94 percent of organizations in 2007 and 97 percent in 2008 practicing agile, with reasons like accelerating software delivery (71 percent), managing changing priorities (63 percent), and increasing productivity (51 percent) — surveyed across marketing, finance, medical, manufacturing, and IT domains.

Certifications keep practitioners current. Certified Scrum master and the DevOps Leader certification from the DevOps Institute are two recognized paths, and the Effective DevOps book, about building a culture of collaboration, was written for that certification track. Certification-style material like agile and DevOps is exactly the content the exam guidance says to study thoroughly — in industry, people mold processes to their business requirements, which is how misconceptions get absorbed.

The teaching background is industry-grounded. This course's teaching background comes from industry experience in the PLM domain — product lifecycle management — at Tata Technologies, working with Tata Motors, and at Dassault Systèmes working with CATIA, before moving into teaching software engineering, software project management, software product management, data mining, and machine learning; the research thread is embedding ML and data mining into SDLC phases to bring more automation into software engineering.