DevOps Misconceptions, Anti-Patterns, and Agile Methods

This session moves into the process side of DevOps. We start by clearing up the most common misconceptions about what DevOps is, look at the anti-patterns that signal DevOps is missing from an organization, and then break DevOps into its three dimensions: people, process, and tools. After that we look at how DevOps changes the agile lifecycle, how teams are structured (component versus feature), and the agile methods the syllabus expects: TDD, BDD, and FDD.

4.1 DevOps Misconceptions

People hold a handful of recurring myths about DevOps. Each one shrinks the real idea down to a smaller, easier-sounding thing. Here are the myths and the fact behind each.

4.1.1 "DevOps is a team"

The first and most common misconception is that DevOps is a team. If you add another team to your organization and call it the DevOps team, it will not help. Adding more members to more teams creates more communication overhead — the more members you add, the more communication issues will happen. So you cannot say "my organization has a team called DevOps, so we are doing DevOps."

The communication math matters here. In any organization, communication links grow roughly with the square of the number of people involved: two people have one link between them, five people have ten, ten people have forty-five. Every new team you add creates new links between its members and every other team, and every new link is a place where information gets delayed, distorted, or lost. A team called "DevOps" does not remove a single one of those links — it adds more.

4.1.2 "DevOps is just CI/CD"

The next misconception is that DevOps equals a CI/CD pipeline — continuous integration, continuous delivery, or continuous deployment. That is not the fact. DevOps actually takes care of scalability, consistency, and reliability. It is not only about implementing a CI/CD pipeline; the pipeline is one piece of a much larger practice.

A goal-based definition helps here: DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality. Notice what this definition does not mention: no specific pipeline, no specific tool, no specific vendor. The pipeline is the machine that moves code through, but the practice is the whole system around it — how teams share knowledge, how requirements include operations concerns, how failures are investigated, how monitoring is set up after deployment. If your organization has a perfect pipeline but a blame culture, broken communication, and no monitoring, you have a pipeline, not DevOps. The pipeline is one piece of a much larger practice; scalability, consistency, and reliability are outcomes that the whole practice produces.

4.1.3 "DevOps is not compliant with industry standards"

This is the biggest mistake organizations make. They feel DevOps is not compliant with industry standards because there is no governance body behind it. For ITIL, for example, there is a governance body that certifies you. The DevOps Institute exists only to give tutorial sessions and takes a license for giving you a certification; there is no general governing body for DevOps, and no ISO-style certification. The fact is the opposite: DevOps is about regulation — implementing controls to remain compliant with industry standards while reducing the risk that may affect the confidentiality, integrity, and availability of information (the CIA triad of information security).

The confusion comes from mixing two different ideas: certification and compliance. Certification is a piece of paper from a body that audits you. Compliance is a state — the state of having controls in place that keep you within the rules of your industry. Regulated domains such as banking, health care, and utilities have long treated DevOps skeptically for this reason, yet the practices themselves are adaptable: the controls, approvals, and audit trails that the regulator demands can be built into the process instead of bolted on as a separate ceremony. So the argument "no ISO-style certificate exists for DevOps, so DevOps is not compliant" fails: compliance is built into the practice through control and regulation, not through a certificate.

4.1.4 "Automation eliminates all bottlenecks"

This is a common misconception held by development teams (less so at the higher hierarchy). The belief is: if we automate, it will reduce all the bottlenecks. That is not the fact. If your process has handoffs and waiting times, automation alone will not help increase the feedback loops. So when you look at automating with tools and technology, you are supposed to adhere to the lean approach: minimize the waste in your value stream and increase the value-added time. Improve the partnership between development and operations — dev, test, and operations teams — so that there are fewer handoffs and fewer people-dependent approaches executing your process. Automation multiplies a good process; it does not repair a waiting-chain process.

In lean terms: your value stream is the full set of activities that turn a customer request into a delivered product. Some of those activities add value — writing the feature, testing it, shipping it. Others are waste — waiting for another team, reworking misunderstood requirements, passing knowledge between people by meetings. Automation makes both kinds faster. The lean discipline is to first shrink the waste so that the value-added time is a large share of the total, and only then automate. A team that automates first and improves the process second has ordered the steps backward.

4.1.5 "There is one universal continuous delivery pipeline"

People think some ideal company has already built the perfect CI/CD pipeline and we just have to replicate the same thing. That is not the fact. Even if you say Facebook completes their development and delivery of 10 or 20 features in about an hour, that is not true for Amazon. Amazon has a different frequency — they deliver every new change every second, in a fraction of a second; whenever there is a change, it resides in the production environment. Every organization has a different aspect of delivering features or changes. So we are not looking for a process that fits all organizations universally; we create a process, we improvise the process, which is the best fit for our own organization and business need — not vice versa.

The same pattern appears across the industry at smaller scales. The social network IMVU, for example, deploys new code about 50 times a day: a commit triggers an automated test suite, and a statistically significant regression automatically rolls the change back. A bank, by contrast, might release once a month with extra approval gates because its regulator demands them. Neither organization is doing DevOps "wrong" — each cadence is a choice shaped by business need and risk. That is the point: cadence is an output of the practice, not a template you copy.

The takeaway from the table: when to pick which cadence is decided by your own business need — customer expectations, risk tolerance, regulatory environment — never by copying another company's numbers.

4.1.6 "DevOps is all about tools"

That is not correct either. As already mentioned, there are other aspects to DevOps. It is mandatory for a developer to use tools in order to automate some processes, but the tools you use should come from the people — that means you need effective people management at the same time. What DevOps looks for is empowered, smaller, self-sufficient teams and continuous delivery engineering. That is the output DevOps is aiming at: people, organized well, driving the tools.

This is also why the history of DevOps is full of tool innovation but the movement itself is not a tool movement: many startup companies came up with very innovative tools because of DevOps, but the core concept of DevOps was already present across industries long before any of those tools existed.

4.1.7 "We must release as fast as Amazon and Facebook"

People adopt different ways of working with a CI/CD pipeline. Recall the earlier distinction between delivery and deployment: there are organizations that do continuous delivery with automation, but when it comes to pushing the code to the production environment, they keep some manual intervention. So you do not have to use the same release process or the same pipeline that Amazon and Facebook use. The pipeline should be relevant to the business need of your particular organization.

Two organizations can both practice continuous delivery and still look very different at the deployment step: one pushes every change to production automatically, the other delivers the change all the way to a production-ready state and then stops for a human to press the button. Both are legitimate choices; the manual step may exist because a regulation demands human sign-off, or because the team simply is not ready for fully automated releases yet. The mistake is to measure your DevOps by someone else's release numbers. Measure it by whether your process fits your own business need and is improving over time.

4.2 DevOps Anti-Patterns

If DevOps is missing or done badly, you see characteristic anti-patterns. A useful way to think about them: nothing in this field is rocket science. Every new terminology that comes into the market is made of bits and pieces that were already there, here and there, in different industries. Someone collects the good things together and gives them a new name — that is exactly what happened with DevOps. All the best practices existed; many startup companies came up with very innovative tools because of DevOps, but the core concept of DevOps was already present across industries.

That claim is easy to verify from history. The practice of investigating failures to prevent their recurrence came into IT from total quality management in manufacturing. Kanban boards came from the Japanese manufacturing floor. The idea that the person who builds something should also run it dates back to the earliest computer programmers, who were also the operators of their machines. DevOps did not invent these pieces; it collected them, gave them one name, and connected them. The practical consequence: when an organization shows the four anti-patterns below, it is not facing a new problem — it has simply not yet applied the well-known good practices that DevOps assembles.

4.2.1 Blame culture

The first anti-pattern is the blame culture. DevOps works to reduce the blame game in the team. Rather than pointing fingers, you combine all the team members into a single team, and that team holds one shared business goal — not different, different goals — and moves in the same direction.

Notice what "one shared business goal" does to the structure: it removes the other team that the blame would attach to. The development team and the operations team stop being adversaries with separate scorecards and become one team whose scorecard is the delivered product working in production.

4.2.2 Silos and the sharing culture

The second anti-pattern is keeping knowledge restricted to yourself. DevOps breaks the silos by improving the sharing zone in the organization. According to the research reports on DevOps adoption — the DORA reports (DevOps Research and Assessment, the research program behind the annual State of DevOps reports) — the first mandatory thing for any organization looking to adopt DevOps is: start sharing. A sharing culture is the prerequisite for adopting DevOps.

There are several ways organizations build this sharing culture. Many have started a weekly meeting where all department people are invited and everyone shares their thoughts and achievements with colleagues — what you achieved this week, what you are working on. Even VPs and other leaders join these calls and share what the earnings were from one particular department, who performed well, and — in terms of motivating people — they give benefits, certifications, honors, extra payment, or awards for achieving something good. Then the people who were awarded are asked to share their thoughts on how they accomplished it, and the organization starts a mentor-mentee program. All of these are different aspects of getting into a sharing culture.

It is a great example of breaking silos: you are no longer keeping your knowledge to yourself and creating a dependent zone in the organization; to grow, you have to share your knowledge with your juniors.

4.2.3 Root cause analysis

The next anti-pattern is the wrong kind of failure investigation. In a DevOps culture, an effective root cause analysis is performed rather than finding who introduced the problem — the question is never "is this from the development team, the operations side, or the testing side?" In the DevOps culture, root cause analysis exists to find the problem and prevent it from reoccurring again. The goal is the fix and the prevention, not the blame.

A root cause analysis (RCA) is a method to identify the contributing and root causes of an event and the actions needed to prevent it from happening again. Two classic tools support it. The 5 Whys technique asks "why" repeatedly — for each answer, ask why again — until the discussion reaches a process reason that can actually be fixed. An Ishikawa (fishbone) diagram groups causes into categories — people, process, tools, environment — to see the relationships between contributing factors instead of fixating on one. Both tools share the same discipline: keep digging past the obvious first answer. If the investigation stops at "a developer made a mistake," it has found a stopping point, not a cause — the productive question is what in the process made that mistake likely or even inevitable.

4.2.4 Human errors

The final anti-pattern to expect is a high rate of manual mistakes. Since we are increasing automation, the manual mistakes will be lessened — that is the first thing automation gives us. If your organization still shows heavy human-error rates in delivery, automation is missing.

The reasoning is mechanical: every step that a human performs by hand — typing the same configuration, remembering the same sequence of commands, copying the same artifact — is a step where a person can misremember, mistype, or skip something. Automation takes those steps out of human hands and makes them repeatable and identical every time. That is why a high rate of manual mistakes is such a telling signal: it means the organization is still running critical steps by hand, which is the opposite of the DevOps direction. Note the parallel with root cause analysis: the DevOps response to a human error is not to blame the human but to look at the process — and the first place to look is whether that step could have been automated. The automation answer is what turns a repeated human error into a design fix.

4.3 The Three Dimensions of DevOps

DevOps has three dimensions: people, process, and tools or technology. The dimensions pair up, and each pairing produces one of the three outcomes DevOps depends on.

4.3.1 People and process: collaboration

When you have people who are adhering to a best process, you bring the greatest collaboration into your team and your organization. People following a good, defined process is what makes teams work together instead of past each other.

The mechanism is worth making explicit. A process is an agreement about how work moves — who does what, in what order, and what each person hands off. When everyone in the team knows and follows the same agreement, they do not need to negotiate the ground rules on every task; the process settles it. Collaboration is not people simply being friendly — it is people able to work on the same goal without stepping on each other, because the process coordinates them. This connects directly to the anti-patterns: a blame culture and knowledge silos are what happens when people do not share a process, so collaboration is the positive counterpart of breaking the silos.

4.3.2 Process and tools: automation

When you talk about process and tools, you are adhering to the process and trying to accommodate the tools within that process. That is how you bring automation: you automate the process with the help of tools and technology.

The direction of fit matters: the process comes first, and the tools are chosen to encode that process. A continuous integration server, a configuration management tool, a deployment pipeline — each one takes a step that people used to perform by hand and executes it the same way every time. That is exactly what automation means in this dimension: the process stops living in people's heads and starts living in the tools. Recall the anti-pattern of manual mistakes: the process-and-tools pairing is its cure, because the tool performs the step identically on every run. The tools do not replace the process; they make the process reliable and repeatable.

4.3.3 Tools and people: innovation

Since you are using tools and technology, and your people are the ones who will use them, the third pairing is people with tools. When people learn new things and write scripts, innovation arrives. For a tester, bringing automation means learning how to write test scripts — code, test as code. For an infrastructure or configuration person from the operational domain, it means writing infrastructure as code or configuration as code, working with tools like Puppet or Ansible. Real-world: Puppet and Ansible are the classic configuration-management tools named in this session for the operations side of DevOps.

Innovation here is not a vague buzzword — it has a concrete shape: people who are empowered to use tools start automating their own corners of the world. A tester who learns to script tests changes testing from a manual checklist into a repeatable artifact. An infrastructure engineer who writes infrastructure as code describes servers and their configurations in files that can be versioned, reviewed, and recreated — instead of configuring each machine by hand. The common pattern is that the people closest to the work are given tools, learn them, and then write their own automation; that is the people-and-tools pairing producing innovation. It also explains the feedback loop from the misconceptions: because the tools are chosen by the people who use them, people keep learning and keep improving the process, which feeds the process-and-tools pairing in turn.

4.4 DevOps and the Agile Lifecycle

DevOps takes the best practices already in the market and modifies them to make them better. DevOps and agile run hand in hand: DevOps carries the practices of agile, with a couple of changes made to agile practices in order to adhere to the DevOps culture.

4.4.1 The agile cycle: inception, construction, transition

The agile cycle looks like this. In the inception phase you actually collect the requirements and design and model them: for your organization you have a vision, you have collected the requirements, and those are converted into an initial module. A high-level ranking is given to the particular features — what to release first and what not to release first — and according to that prioritization your release plan is made ready. Next you move to the construction phase, where you are supposed to adhere to agile principles, but to adhere to those principles you need a method: either you follow Scrum, XP, or Lean — whichever is suitable for your project or your business, your organization picks one. This is the phase where, using that method, the team develops a solution. Then the solution moves to the transition phase, where it gets deployed into the production environment. That is the lifecycle, the cycle, of agile.

Each phase answers one question. Inception answers what are we building and in what order — requirements are collected, designed, and modeled into an initial module, features are ranked, and the ranked list becomes the release plan. Construction answers how do we build it — the team picks an agile method (Scrum, XP, or Lean) and develops the solution according to that method. Transition answers how does it get to the customer — the finished solution is deployed into the production environment. The cycle then repeats for the next release.

4.4.2 Inception: bring the operations team in

DevOps has an impact on all three phases — inception, construction, and transition — and each phase has some modification or add-on with respect to the DevOps culture. In the inception phase, release planning includes feature prioritization, but it also includes coordination with operational personnel. The change that DevOps brings here is: we involve the operation team as well, during the inception phase itself. Operations stops being a downstream receiver and becomes part of planning.

Why does this matter so early? The operational personnel are the people who will run the system after it ships, and they carry knowledge the developers do not have: how the production environment behaves, what configurations break, what logs the support staff can actually read. If operations is consulted only at the end, that knowledge arrives too late — the release plan may already promise features that the environment cannot support. Involving operations in inception means the release plan carries their constraints and requirements from the start: what the deployment will need, what training the support people will require, and how the rollout will be handled. Operations stops being a downstream receiver and becomes part of planning.

4.4.3 Construction: continuous integration and automated testing

In the construction phase, a key element of DevOps practice is the management of the code branches. What DevOps suggests here is to follow continuous integration: whenever you make a small change, that change should go and reside into your code branches and the source code repository, and the continuous build and the subsequent processes should follow. So continuous integration, continuous delivery, and deployment should happen in the construction phase. At the same time, the testing you are doing should be automated testing — as the build is continuous, the testing should also be continuous, and you bring automation into testing as well.

4.4.4 Transition: the development team deploys, monitors, and decides

In the transition phase, the development team should be able to deploy the process: the development team should be responsible for the deployment, they should also monitor the process of deployment, and the development team is the team that should decide whether to roll back. Notice the balance: in the inception phase we gave a room for the operation team, and in the transition phase we give a room for the development team to understand the operation aspect as well. That brings more collaboration into the team — the team works as a team, not as individual job roles.

The three responsibilities are a deliberate package. Deployment is no longer "thrown over the wall" to a separate team — the developers who wrote the code move it to production. Monitoring the deployment means watching the rollout itself as it happens, not walking away after pushing a button. And the rollback decision — whether the new version is healthy enough to keep or should be pulled back and the old version restored — sits with the people who understand the change best. Together the three responsibilities force the development team to experience the operations side of their own work, which is what turns job roles into one team. This is also the balance point with inception: operations moved upstream into planning, and development moved downstream into running.

The answer names two layers of work. The first layer is the testing sequence applied to the ready solution — alpha testing with internal users, beta testing with a limited external audience, canary testing where the new version runs on a small set of real users first, then capacity testing to check the system handles the expected load, and security testing for vulnerabilities. The second layer is infrastructure readiness — the hardware must be in place, the operating system at the right patch level, and the application's configuration present, such as the Tomcat application server or JRE 7 (Java Runtime Environment version 7) the application depends on. Only when both layers are done does the code move to production.

4.4.5 Silos and handoffs before DevOps

The two habits connect: gold plating hides failures from the outside, while the golden member hides knowledge from the inside. Together they are why "silos" and "handoffs" became dirty words. A handoff is the transfer of work (or the responsibility for work) from one person or team to another; a silo is a team that does not share its knowledge with the rest of the organization. Where there are silos, there are handoffs — every time work crosses a silo boundary it waits, and the waiting is what automation removes.

The endpoint of the process is worth stating precisely: both habits — the silo and the handoff — survive even with DevOps if the organization has not reached the maturity level where its process is automated. But slowly and steadily, by adhering to DevOps, improving the process, and automating as much as you possibly can, everything will be removed, and there will be no handoffs at that point.

4.5 Flow-Based and Non-Flow-Based Agile

4.5.1 The two families of agile methods

In agile you have two broad types of methods: flow-based and non-flow-based. The non-flow-based methods are extreme programming (XP), Scrum, FDD, BDD, and TDD. The flow-based methods are Kanban, hybrid agile, and distributed agile. The course on agile software processes is where you get more hands-on and more expertise in this particular domain; here we focus on when to choose which.

The two families also carry the same tradeoff into one formula. For a flow-based system, the time a piece of work takes to move from start to finish — its cycle time — is set by how much work sits in progress and how fast the team completes work:

$$\text{Cycle Time}=\frac{\text{Work in Progress (WIP)}}{\text{Throughput}}$$

where cycle time is the average time from a card being picked up to it being done, WIP is the number of work items currently in progress, and throughput is the average completion rate (items completed per unit of time). If the team holds ten items in progress and completes five per week, the average cycle time is $\frac{10}{5}=2$ weeks. Halve the WIP and the cycle time halves too — which is exactly why flow-based methods are obsessed with limiting WIP rather than pushing more work in.

4.5.2 Choosing between them

If your organization is in the manufacturing domain, or you have a large project that is distributed in different locations, it is always good to opt for the flow-based approach. If your organization is in the software industry — an IT organization — with a small team that is co-located, it is good to follow non-flow-based. In the IT industry generally we all follow the non-flow-based approach. If your customers are manufacturing people for whom you are developing something, then you can see a mixture of Scrum and Kanban: you will adhere to the Kanban board so that your manufacturing people can understand what tasks are to do, what are in working, and what is done. Those are the two broad families. The same logic applies in DevOps: there is no change — looking at what the project really requires and what the business needs, your organization or team will adhere to either the flow-based or the non-flow-based method.

The decision rule in one sentence: match the method family to how the work physically flows through your organization. The same logic applies in DevOps — there is no change: looking at what the project really requires and what the business needs, your organization or team will adhere to either the flow-based or the non-flow-based method.

4.6 Team Structures: Component Teams and Feature Teams

Before you choose a team structure you decide the planning side: you adhere to a method, you prepare a plan — a release plan, a project plan — you create tasks and subtasks, and you decide the iteration and the tenure of one cycle. That all happens when you decide on the method and the planning. Then comes resource planning: how will we organize our resources? Either we follow a component team structure or a feature team structure. These two are the ones widely accepted in the industry.

The order of decisions matters: method first, plan second, and only then resource planning. The team structure is not the starting point — it is the answer to the question "now that we know the plan, who works on what?" The two structures answer that question in opposite ways: component teams divide the work by the parts of the system, feature teams divide the work by the slices of customer value.

4.6.1 Component teams: experts in one domain

A component team is full of experts — component experts in a specific domain — and that becomes one component, one team. In the reference diagram: team one is the user interface expert, team two is the business logic expert, and team three is the database (DB) experts. Three different teams, each specialized in a different domain.

The best advantage: whatever work is delivered or completed, you know the work is qualitative, because it has been done by special people. The work is done efficiently, with a low defect density. That is the greatest advantage of a component team.

The disadvantages: it is people dependent. How does being people dependent impact the time to deliver? Think of a scenario: your business team wants to work on a feature that is being designed by the user interface team. Until the design is ready, your business logic team will not be able to proceed ahead — that is the dependency — and because of that, the delivery timeline gets delayed.

4.6.2 The productivity trap: a worked example

Working in a component team also has a negative effect on productivity that cannot be overemphasized. Here is the full scenario.

That is the biggest disadvantage of component teams, and that is why nowadays most of the IT industry, when it comes to project implementation, tends to follow feature teams for their resource planning.

4.6.3 Feature teams: vertical slices and generalizing specialists

Feature teams contain multi-discipline individuals who have the ability and freedom to work in any area of the system. Think of it like a cake: you had the user interface layer, the business logic layer, and the DB layer, and now you are just picking up one slice that involves all of them — user interface, business logic, and DB expert. Every multi-disciplined individual can work on every aspect of these three expert domains. A feature team usually has at least one member with specialist knowledge for each layer of the system. That allows feature teams to work on what are known as vertical slices of your architecture — and that is where the term full-stack engineer comes from: someone who knows everything across the layers.

The characteristics of a feature team:

• Long-lived. Why long-lived? The first problem with a feature team is finding those experts — the generalized specialist is really hard to get. And once you get them, you cannot lose them: you cannot say "the project is done, so you can leave this team and join another." We want the feature team to live long, because if they work together for a longer time they gel together very well, and that impacts their performance — they achieve very high performance when they gel. So a feature team is something like six, seven, or eight people who move from one project to another simultaneously, together, throughout. We do not break the team; when the previous project is completed, we move that entire team to another project.
• Co-located. To create the bond between a team, you need to meet face to face. Communication and connection feel good when you do it face to face rather than online — the same reason the instructor turned the video on for the first sessions, so that you feel from whom you are listening, and that connect makes you more attentive. Delivered face to face, the same session is more fruitful. The co-location requirement is the same idea: the bond of the team is built through face-to-face contact, and a team that has gelled communicates with a few words where a remote team needs an email thread.
• Work on a complete customer-centric feature across all components and disciplines. You do analysis, programming, and testing in terms of features, not as a whole system: you pick one feature, do the requirement analysis for that feature, design it, program it, test it, and that feature gets deployed.
• Composed of generalizing specialists. In Scrum terms, a feature team is seven plus or minus two people — minimum five, maximum nine. That is the strength of a feature team in Scrum.

The disadvantages: if the members are untrained and not well experienced with the domain, the work delivered will not be qualitative, because they are not skilled to that level yet. And the biggest disadvantage is finding those generalizing specialists. Nowadays, with the certifications and institutes that provide full-stack engineering certification programs (BITS runs such a program), you get at least an idea of where to upskill yourself — an introductory idea that brings the motivation and instinct to learn more in the domain. And DevOps itself gives the opportunity to learn: because you allow people to opt for tools, that brings innovation, people learn new things, and gradually they become generalized specialists because they learn almost everything.

4.6.4 Student experiences with team structures

The two student observations together give the honest tradeoff. A feature team pays the cost of feature-level knowledge concentration (the expert who knows the feature is a dependency), while a component team pays the cost of integration (the time spent making the separately built components fit together). Each structure moves the dependency somewhere else — the choice is which dependency your organization can absorb.

4.6.5 SRE engineers inside feature teams, and DevOps versus SRE

The discussion then turned to a third structure in the wild — Site Reliability Engineers embedded in feature teams — and the relation between DevOps and SRE.

4.7 Extreme Programming and Project Velocity

4.7.1 The XP cycle

To understand TDD, the very first prerequisite is to know extreme programming (XP), because the idea for TDD came from XP itself: from the pair programming concept of extreme programming, the TDD method emerged. XP is not part of the syllabus — this is just an overview — and you will get more familiar with it in your other courses, especially the agile software process course. Resource planning, similarly, is something you will cover in the product management or software project management course.

XP is again an iterative and incremental cycle. In the planning phase, you plan for user stories: you come across the user stories and decide what story point values you will provide for each user story; then you are ready with the acceptance test criteria and the iteration plan. With respect to the design phase, XP adheres to CRC cards — class responsibility and collaboration cards — to design the requirements into a low-level or high-level design: you draw the classes, the roles, and the collaboration between the classes. In terms of design, XP strongly suggests a prototype: create a prototype so that you get feedback from your customer, which minimizes the risk of rework after a long time. In the coding phase — the heart of extreme programming — comes pair programming. In testing, you perform all the testing that is mandatory for your project — acceptance test, capacity test, integration test, system test, and so on. Once testing is done and everything is okay, the user stories developed in the coding phase are pushed to the production environment — that is the release, the software increment. And once the software increment is done, you compute the project velocity for your next cycle.

The cycle in one line per phase: planning decides the stories and their story point values plus the acceptance test criteria and iteration plan; design turns requirements into classes and collaborations through CRC cards and validates the design early with a prototype; coding runs as pair programming; testing runs every test the project needs; release pushes the increment to production; and velocity is computed to size the next cycle.

4.7.2 Student questions and answers

The two answers sit on opposite ends of the planning spectrum. The waterfall answer is about matching the team structure to the lifecycle: phases in sequence, experts in sequence. The velocity answer is about the planning arithmetic inside an iterative cycle: capacity in, commitment capped, measurement after delivery, recalibration before the next cycle.

4.7.3 Project velocity: a worked example

Velocity is the measure of how much a team can commit to for a particular iteration, computed by looking at what the last increment actually delivered.

Take the numbers from the explanation above. The backlog has seven user stories, and every user story carries five story points:

$$\text{total points in the backlog}=7\times 5=35$$

where story points are the weightage of a story — the number of hours of work needed to complete that user story. Out of the 35 hours of work, the team's measured capacity for a two-week increment is only 20 hours:

$$4\times 5=20\le C$$

with $C$ the team capacity, here $C=20$ hours. So in the first planning the team took four user stories — exactly the 20 hours it could commit to — and pushed the remaining three stories to the next increment.

The general rule behind the numbers: the committed stories in any increment must total no more than the team capacity, and the capacity itself is re-estimated from the last increment's actual delivery. Written once:

$$\sum _{i\in S}{p}_i\le C$$

where $S$ is the set of user stories taken in the increment, $p_i$ is the story point value of story $i$ (hours of work), and $C$ is the team's capacity (initially 20 hours, revised to 25 after the first increment). That is what velocity is for — calibrating how much the team can honestly commit.

4.8 Test-Driven Development

4.8.1 What TDD is

TDD stands for test-driven development, but it is known by many different names in the market: test-driven development, test-driven design, test-first development, and emergent design are all labels people use for the same idea. Kent Beck's writing on TDD carries two memorable statements: test-first code tends to be more cohesive and less coupled than code in which testing is not part of the intimate coding cycle; and — the sharper one — if you cannot write a test for what you are going to code about, then you should not be thinking about writing the code.

4.8.2 The red-green-refactor cycle

TDD follows three steps: red, green, and refactor.

• Red: you just write a new test, which will fail because there is no code for it yet.
• Green: you write the simplest possible code to make that test pass — the test should turn clear, not fail.
• Refactor: you refactor the code, including the test code, wherever the team feels it should be refurnished.

4.8.3 Worked example: adding UPI to a payment gateway

The team is working on a payment gateway task — they would like to add a payment gateway option into their product. First, choose a small task: the team picks the task. There is already implementation code — the team is already contributing, and they have some production code: the payment gateway equals some function for credit card and net banking, and that is what exists. The team wants a UPI option.

4.8.4 Test-first versus test-last

Test-first (TDD): you pick the story, you understand the story, you design it. Then you write a single test case and run it — it fails. To make it green, you write production code for that particular test. Then you run all the tests: if the results fail, you rework on your production code; if the tests pass, you see whether your story is complete. If it is complete, you go to the next story; if it is not, you go back and write a single test for another part of the same user story.

Test-last: you pick the story for the first increment, you understand it, and you implement the production code for that story fully. Then you write the test for the story and run the tests: if they fail, you rework; if they pass, you jump to the next story.

The difference in shape: test-first grows code test by test, while test-last writes all the code first and only then asks whether it works.

4.8.5 Why TDD: the productivity debate

TDD can lead to a more modularized, flexible, and extensible code. You adhere to better clean code practices. There is better code documentation, because you are writing your test scripts first. And it is claimed to be more productive — but this is an ongoing debate: researchers are still debating on white papers whether TDD is productive or not. One finding from a paper: TDD initially impacts the productivity of your team, because the team is busier writing test scripts — you cannot deliver the test script to your client; you have to deliver the software, and to deliver that software you need production code, not test scripts. So initially the team focuses more on the test script, and that impacts productivity. But after a certain amount of time, once the team gets more and more familiar with the approach — say by the second or third sprint — the team starts showing improved productivity. The next advantage claimed is good design: TDD gives you a good design. Although feature-driven development also helps us come across a good design — so a good design is really a common advantage of agile, rather than a TDD-specific one.

The evidence on the table matches the professor's picture. An empirical study of TDD teams found code that was roughly 60–90% better in defect density than non-TDD teams, at the cost of taking about 15–35% longer — precisely the trade the debate is about: fewer defects in exchange for more upfront time. And the upfront time is not constant: as the team gets used to writing the test first, the initial productivity dip shrinks, which is why the professor's rule of thumb is to judge TDD after the second or third cycle, not after the first.

4.8.6 Student questions and answers

The class raised a cluster of questions about what TDD is and is not. The core correction first, then the applications.

The distinction between approach and type of testing is the master correction of this section: the testing types are the what, and TDD is the how (or more precisely, the when — test before code).

The login-page exchange is a full mini-example of the red step: the user story defines the page (user ID, password button, login button, sign-up button), the test script encodes a rule ("the password should not contain all numerical digits"), the rule has no code behind it yet, so the test fails — and only then does production code get written. And the other two exchanges draw the boundary of TDD: it replaces the first, small test in the pipeline; the bigger testing cycles still run after the implementation code is done.

The white-box exchange is the natural boundary case: white box testing requires the production code as its input, so it is the one testing style that structurally cannot be written first — a reminder that TDD's "write it first" applies to tests that describe intended behavior, not to tests that inspect existing internals.

4.9 Feature-Driven Development

4.9.1 When to use FDD

FDD is feature-driven development — it is feature oriented; you work in features. FDD is best for organizations that would like to adopt agile principles but have a huge project: the project itself is very big and they still want to adhere to agile. The development team is bigger — more than 10, 20, near 40 engineers working on the same project — but they still want to follow agile. In that case the organization can opt for FDD: 40 engineers accommodated in an agile principle, with different members working on different features. Feature-driven development is the way to scale agile to large teams. Exam note: FDD is part of the syllabus.

4.9.2 The primary roles

FDD has many primary roles, precisely to accommodate the larger team size: project manager, chief architect, development manager, team lead, and domain expert — an expert in a particular domain. The class owner is the main role of FDD, a golden role, a star role, and it differs completely from extreme programming: in XP you have pair programming — two people collaborating on one single module — while in FDD the class owner is a single person who is responsible for one class. It is a one person, one module alignment: each class will have an expert available. The class owner has the responsibility to make changes much quicker, anytime it is needed, and it easily lends to the notion of code ownership — the class owner is the owner of that particular class code. It also assists FDD in scaling to larger teams, because you have one person available for the complete ownership of the feature. Then you have chief programmers (like your program manager and release manager, to manage the release cycle), a language guru (an expert in a particular technology), a build engineer (to perform your build process), a toolsmith (to create the tool chain and make configurations), and a system administrator. Real-world: different organizations give these roles different, fancier terminologies and names for their organizational structure — the role names are not standardized across the industry.

4.9.3 The five FDD processes

FDD follows five processes: develop an overall model, build a feature list, plan by feature, design by feature, and build by feature.

• Develop an overall model. The project requirement is big; the overall model gets ready first. You then extract the feature list from that model.
• Build the feature list. Once the overall model is there, you build the feature list.
• Plan by feature. Here you give the prioritization of a feature, you plan for a feature, and you find out who will be the class owner and what the feature-set owner arrangement is, and how the development plan will look — all of that is plan by feature, for one particular feature.
• Design by feature. The feature you want to deliver in that increment cycle is now designed in depth — you design that particular feature thoroughly.
• Build by feature. Once the design is done, you implement and deliver it.

4.9.4 TDD or FDD: what the project needs

When is TDD approachable? TDD is best suitable in scenarios where your team is aware of the complexity of the project they are going to work on — either they have an expert in understanding the project characteristics, what the project is. If it is a web development project and your team has been collaborating on web development projects for a long time, and they are all aware of the complexity of a web development project, then it is always good to opt for TDD, because you know what you are going to implement. FDD, by contrast, is the choice when the project is big and the team is large but agile is still wanted.

The one-line rule: pick TDD when the team understands the project's complexity, and FDD when the project is so big that agile needs to scale.

4.9.5 Student questions and wrap-up clarifications

4.10 Behavior-Driven Development

4.10.1 BDD in brief

BDD is behavior-driven development, and it belongs to the non-flow-based family of agile methods. The one concrete practice already established in the TDD discussion: in behavior-driven development, the team writes the acceptance test first — BDD is where the acceptance test is written before the implementation. Beyond that, this session only introduced BDD; the discussion of BDD (and of Scrum, which is also not part of the syllabus) was deferred to a later session. Exam note: BDD is part of the syllabus, so watch for it in the upcoming sessions.

What this session established is an introduction, not the full picture: BDD belongs to the non-flow-based family, it writes the acceptance test first, and the full treatment was deferred to a later session, along with Scrum. The exam-relevant fact to carry now is the position of BDD in the syllabus.

Exam Guidance Summary

• Exam note: the syllabus requires TDD, BDD, and FDD. TDD, BDD, and FDD are the agile methods to know for this course.
• Exam note: extreme programming (XP) is not part of the syllabus — it was covered only as an overview, because TDD's idea emerged from XP's pair programming concept.
• Exam note: Scrum is not part of the syllabus either; the Scrum slide was kept only for discussion.
• Exam note: a student asked about the transition phase question type for the exam; the question part was deferred to a dedicated discussion of last year's question paper in the seventh or eighth contact session. Expect that session to be the place where exam-style questions are taken up.
• Study advice: agile methods in depth belong to the agile software process course; resource planning (component versus feature teams) is covered in the product management or software project management course.
• Study advice: when revising the transition phase, remember the full checklist from the session: alpha and beta testing, canary testing, capacity testing, security testing, infrastructure readiness (hardware, operating system patch level, configurations such as Tomcat or JRE 7), and then the push to production.
• Study advice: for TDD, be ready to explain the red-green-refactor cycle, the test-first versus test-last difference, and the position that TDD is an approach, not a type of testing.
• Study advice: for the velocity question, be ready to reproduce the commitment rule — the points of the stories taken in an increment must not exceed the team capacity — and to recompute the capacity from the last increment's actual delivery.

Key Industry Applications

• Real-world: Amazon delivers every new change into production in a fraction of a second, while Facebook completes development and delivery of 10 to 20 features in about an hour — cited as the proof that delivery cadence must be organization-specific, not copied.
• Real-world: TVS makes promotion depend on training a successor who can take over your current responsibility six to seven months before the promotion cycle — an industrial example of breaking silos through forced knowledge sharing.
• Real-world: Puppet and Ansible are the configuration-management tools named for infrastructure as code and configuration as code on the operations side.
• Real-world: Tomcat and JRE 7 are cited as real application configurations that must be present in the transition-phase infrastructure.
• Real-world: Google Pay and PayTM are used as the UPI options added during the refactoring step of the TDD payment-gateway example.
• Real-world: the full-stack engineering certification program (BITS) is cited as a path to become a generalizing specialist for feature teams.
• Real-world: Site Reliability Engineers (SREs) mapped dedicated to projects, involved from setup and covering both infrastructure and application logic, form feature teams in some organizations.
• Real-world: 90% of the industry adheres to TDD by writing a unit test first, even though the approach itself allows any test to be written first.
• Real-world: Kent Beck's test-first writing is the reference for TDD; the quotes on cohesive, less coupled code are the canonical summary of the idea.