The Scrum development process addresses various technical and environmental factors that may evolve throughout a project. It is designed to help teams maintain their focus on software development while adapting to changing conditions [2] . Scrum is divided into three phases: pre-development, development, and post-development. The pre-development phase consists of two key components: planning and architecture/high-level design. During the planning stage, the team gathers system requirements and creates a list of features and modifications.

The architecture phase refines and evolves the design based on the backlog list. In the development phase, the team works in iterative cycles (sprints) to improve the system and introduce new functionalities. Each sprint typically includes tasks such as analysis, design, evolution, and delivery.

Sprints usually last between two weeks to one month. Typically, three to eight sprints are completed before the system is ready for release. However, there are some technology companies that release new or enhanced features in their software products every sprint. The post-development phase marks the conclusion of the development effort, during which no further modifications or features are added. Retrospective is also held at the end of the sprint to help all members share honest feedback on tasks, the project overall, and any challenges encountered. We then collaboratively brainstorm solutions to address these roadblocks, ensuring we’re better equipped for upcoming sprints.

Like Scrum, Extreme Programming (XP) breaks down project work into short development cycles known as “iterations” [3] . This approach allows Agile teams to quickly adapt to changing user requirements, even during the later stages of the product development lifecycle. Additionally, XP plays a significant role in enhancing product quality.

What distinguishes XP from other Agile methodologies is its strong emphasis on technical excellence specifically, producing high-quality code. Developers receive immediate feedback and continuously refine their code through practices like pair programming and both manual and automated testing. Project managers facilitate daily stand-up meetings to monitor progress and address obstacles. Meanwhile, product owners and stakeholders provide feedback based on acceptance tests and the product’s performance after each iteration.

These core practices of XP foster effective teamwork, encourage adherence to coding best practices, and help maintain high standards for code quality and overall deliverables.

Test-Driven Development (TDD) is a software development methodology where developers write automated tests before writing the actual code [4] . This approach begins with creating unit test cases that define the expected behavior of a feature, guiding the subsequent development of the code itself. It follows an iterative cycle that integrates programming, unit test creation, and continuous refactoring.

The TDD workflow is structured around a repetitive cycle known as Red-Green-Refactor:

TDD helps maintain a reliable and bug-free codebase by catching errors early in the development process. It also promotes better design practices, as writing tests first forces developers to think critically about the intended functionality and structure of the code.

Additionally, since tests are an integral part of the development process, TDD leads to higher code coverage. It simplifies future modifications or refactoring by ensuring existing features remain stable and thoroughly tested.

Rooted in the principles of the Agile Manifesto and Extreme Programming (XP), TDD emphasizes test-driven development as the foundation for writing effective, maintainable code. Developers create small, focused test cases based on their initial understanding of each feature. Code is written or modified only when a test fails, reducing redundancy and ensuring that every piece of code serves a validated purpose.

Defect-Driven Development (DDD) is a software development approach where the process is heavily influenced by defects found during testing or production. Instead of following a traditional feature-driven or test-driven approach, teams prioritize fixing defects as they emerge, leading to continuous refinement and improvement of the codebase [5] .

Key Characteristics of Defect-Driven Development:

Defect-Driven Development is often combined with Test-Driven Development (TDD) and Continuous Integration/Continuous Deployment (CI/CD) practices to create a balanced software quality approach.

Rushing to meet tight deadlines can compromise code quality and lead to technical debt. For example, frequent sprints in Agile may pressure QA team to deliver quickly without sufficient testing leading to a potential customer escalation. In several cases, it has been seen that QA team is bullied into giving their signoff.

Poor software quality is incredibly costly for companies, both in direct financial losses and indirect impacts. Here are some key stats and insights:

Lack of clear ownership can significantly hinder Agile development methodologies in several ways:

Security checks are sometimes overlooked to maintain rapid deployment cycles. In DevOps, pushing code without thorough vulnerability scans increases the risk of breaches or in the absence of a QA team for security testing could potentially ship products to customers leaving them vulnerable to serious risks like DoS (Denial of Service) and SQL injections thus crippling their day-to-day operations leading to huge financial losses, latest one being the CrowdStrike security patch mayhem in the year 2024 that brought US Airlines operations to a halt resulting in loss of billions of dollars.

The data-driven reality highlights that modern Agile methodologies often prioritize velocity over quality, leading to a lack of motivation for delivering high-quality products. While Agile excels in speed, it frequently overlooks the importance of robust testing and defect management. So, how can we overcome these challenges while maintaining agility and ensuring QA teams regain their significance? One possible solution is a new methodology—T3D (Test & Defect Driven Development)—designed to address these shortcomings. Let’s explore how it can enhance both quality and agility.

Let’s understand the process better with the help of an example. Say an agile team is planning to work on 3 user stories of varying complexities.

Post sprint planning the QA team should come up with a map and get it reviewed by the Product and Dev teams as shown below in Table 1 .

As developers write code and when believe they’ve logically concluded a function or a story they will begin with testing with 2 goals:

1) Acceptance criteria documented in the story is achieved.

2) The 16 defects raised above don’t appear to block or impact the story.

This improves the build quality that will be delivered to the QA team, there won’t be any surprises and the turnover and back-forth between Dev and QA will also reduce. As a result, Regression testing, Performance and Security evaluations would be faster.

In any iterative development process not all stories may be delivered to the QA team, there’s a possibility stories delivered earlier may develop defects due to code changes done for other stories, but the chances of this happening in T3D are very less due to the nature of tests (E2E & integration) written by QA for devs. However, if by chance Devs miss anything QA is there to provide the safety net.

Once all the 16 defects (plus additional that team would have discovered) are resolved and closed, the 16 test cases (6 E2E & 10 intg.) are now marked as “Passed”. If the team decides to defer any defects, then the corresponding test case remains in failed state until the defect is resolved as shown below in Table 2 .

During sprint review, everything gets reviewed, and decisions are made to release features and to defer some to upcoming releases. Next sprint same process is followed where the team works on new backlog items along with multi-sprint stories and defects that were deferred from previous sprints.