Browse Courses

Working Agile

May 26, 2025 8 min read Agile Programming Docs IBM-DevOps Agile-Methodologies Agile-Workflow Mvp Tdd Bdd

This document explores five key practices of Agile methodology working in small batches, creating minimum viable products (MVPs), behavior-driven development (BDD), test-driven development (TDD), and pair programming. These practices enable teams to deliver value quickly, obtain fast feedback, and maintain high code quality.

On this page
Working Agile

This document explores five key practices of Agile methodology: working in small batches, creating minimum viable products (MVPs), behavior-driven development (BDD), test-driven development (TDD), and pair programming. These practices enable teams to deliver value quickly, obtain fast feedback, and maintain high code quality while ensuring both customer satisfaction and technical excellence.

Agile Working Practices

Working in an Agile fashion means adopting specific practices that enhance responsiveness, efficiency, and quality. The five key practices of Agile workflow are:

  1. Working in small batches
  2. Using minimum viable products (MVPs)
  3. Implementing behavior-driven development (BDD)
  4. Applying test-driven development (TDD)
  5. Utilizing pair programming

Each of these practices contributes to faster feedback cycles, better customer alignment, and higher quality outcomes.

Working in Small Batches

Working in small batches is a principle borrowed from lean manufacturing that focuses on completing small units of work end-to-end before moving to the next batch. This approach reduces waste and enables faster feedback.

The Problem with Large Batch Processing

Consider a scenario of mailing 1,000 brochures with the following steps:

  1. Fold brochures
  2. Insert into envelopes
  3. Seal envelopes
  4. Apply postage

When processing in large batches (e.g., 50 items at a time), with each step taking approximately 6 seconds per item:

StageTime per Batch (50 items)Cumulative TimeIssue Detection Point
Folding5 minutes5 minutesN/A
Inserting5 minutes10 minutesN/A
Sealing5 minutes15 minutesGlue issues detected here
Stamping5 minutes20 minutesN/A

In this approach, the first completed item is only available after 20 minutes, and any issues (such as missing glue or brochure typos) are discovered very late in the process.

The Benefits of Single-Piece Flow

With single-piece flow, each item goes through all steps before starting the next item:

ProcessTime for First Completed ItemIssue Detection Point
Complete workflow24 secondsAs early as 18-24 seconds

This approach delivers the first completed item in just 24 seconds, allowing immediate inspection and validation. Problems are discovered much earlier, minimizing waste and enabling quick adjustments.

Minimum Viable Product (MVP)

What an MVP Is Not

A common misconception is that an MVP is simply the first phase of a project or an early beta version. This delivery-focused interpretation misses the true purpose of MVPs.

The True Purpose of an MVP

An MVP is the minimal thing that can be done to prove a hypothesis and gain learning. It focuses on:

  • Testing assumptions
  • Obtaining customer feedback
  • Gaining insights for future development

After each MVP, the team decides whether to pivot (change direction) or persevere (continue on the current path) based on the feedback received.

MVP Example: Car Development

Traditional Approach (Iterative Development)MVP Approach (Learning-Focused)
Iteration 1: Deliver a wheelIteration 1: Deliver a skateboard (test color and basic mobility)
Iteration 2: Deliver chassisIteration 2: Deliver scooter (test steering)
Iteration 3: Deliver car body without steering wheelIteration 3: Deliver bicycle (test improved locomotion)
Final: Deliver complete car (coupe)Final: Deliver convertible (based on customer’s evolved preference)

The traditional approach delivers exactly what was initially requested, while the MVP approach delivers what the customer truly desires through continuous learning and adaptation. The customer’s experience with early MVPs often reshapes their understanding of what they actually want.

Minumem-Viable-Product

Behavior-Driven Development (BDD)

Behavior-driven development is an approach that describes the system from the outside in, focusing on user-observable behavior rather than internal implementation details.

Key Characteristics of BDD

  • Tests at the integration level
  • Focuses on the user interface and customer perspective
  • Uses a common syntax understandable by both developers and stakeholders

BDD Feature Scenarios Structure

BDD scenarios follow this pattern:

1Feature: [Feature name]
2As a [role]
3I need [function]
4So that [business value]
5
6Scenario: [Scenario name]
7Given [preconditions]
8When [event occurs]
9Then [observable outcome]

This “Gherkin” syntax provides a shared language between technical and non-technical stakeholders to describe and validate system behavior.

Test-Driven Development (TDD)

Unlike BDD, test-driven development tests the system from the inside out, focusing on the internal components and their functionality.

Key Characteristics of TDD

  • Tests at the unit level (individual modules)
  • Concerned with inputs and outputs of specific functions
  • Drives design by focusing on how code should behave

The TDD Workflow

TDD follows a “Red, Green, Refactor” cycle:

  1. Red: Write a failing test for the functionality you wish to implement
  2. Green: Write just enough code to make the test pass
  3. Refactor: Improve the code while keeping the tests passing

This approach ensures that code is testable by design and that all functionality is covered by tests.

Pair Programming

Pair programming involves two programmers working together on the same code, typically with one person writing code (the driver) while the other reviews and provides input (the navigator). They switch roles regularly, often every 20 minutes.

Benefits of Pair Programming

Despite the apparent doubling of resources, pair programming offers several advantages:

  1. Higher Code Quality: Two sets of eyes catch issues earlier, reducing bugs in production
  2. Knowledge Transfer: Senior developers can mentor juniors, and knowledge about the codebase spreads across the team
  3. Reduced Maintenance Costs: While initial development may seem more expensive, the reduction in bugs and improved maintainability reduce long-term costs

Effective Pair Combinations

Effective pairing can be achieved through various combinations:

  • Senior and junior developers (mentorship opportunity)
  • Code experts and newcomers (knowledge sharing)
  • Developers with complementary skills (broader problem-solving capacity)

Conclusion

Agile working practices focus on delivering value quickly while maintaining high quality. Working in small batches provides fast feedback and reduces waste. Minimum viable products help teams learn and adapt to customer needs. Behavior-driven development ensures the right features are built from a user perspective. Test-driven development ensures technical excellence and code quality. Finally, pair programming reduces defects and enhances team knowledge sharing. Together, these practices create a powerful framework for effective software development.

FAQ

Working in small batches enables faster feedback cycles by completing small units of work end-to-end before moving to the next batch. This approach allows teams to identify issues early, reduce waste, and make adjustments quickly, rather than discovering problems only after significant time and resources have been invested.

If a team focuses on delivery rather than learning when creating an MVP, they will likely build exactly what was initially requested but miss opportunities to discover what customers truly need. This approach often results in products that technically meet specifications but fail to satisfy actual user desires, as the team hasn’t incorporated feedback to evolve their understanding of requirements.

Creating a minimum viable product (MVP) should be prioritized first when validating a new user interface design. By developing just enough functionality to test the interface with real users, the team can gather feedback on usability, aesthetics, and effectiveness before investing in full implementation, allowing them to refine the design based on actual user experience rather than assumptions.

The statement that “TDD is primarily focused on validating the end-user experience” is incorrect regarding test-driven development. TDD actually tests the system from the inside out, focusing on unit-level testing of internal components rather than the user interface or overall system behavior from an end-user perspective. BDD, not TDD, is the practice that concentrates on user-observable behavior.

The concept that “detecting quality issues early minimizes waste and rework” can most likely be inferred from the comparison between single-piece flow and large batch processing. The example demonstrates how single-piece flow allows teams to identify problems (like envelope glue issues or typos) within seconds rather than after many minutes of work, preventing the waste of resources on defective items.

BDD and TDD complement each other by addressing quality from different perspectives. BDD ensures the right features are built by focusing on user-observable behavior and alignment with business requirements (“building the right thing”), while TDD ensures technical excellence by driving robust internal implementation (“building the thing right”). Together, they create comprehensive test coverage from both external and internal perspectives.

The primary reason for regularly switching roles in pair programming is to maintain engagement and mental freshness from both participants. This rotation prevents fatigue, ensures both programmers remain actively involved, and allows each person to contribute their strengths in different capacities. Additionally, it promotes knowledge sharing as each developer experiences the code from both perspectives.

Customer feedback should be evaluated first when deciding whether to pivot or persevere after an MVP release. Since the primary purpose of an MVP is to test hypotheses and gain learning, understanding how customers actually interact with and respond to the product provides the most valuable insights for determining the next direction. Technical considerations, while important, should be addressed after clarifying what customers truly need.

A true MVP is distinguished by its focus on learning rather than delivery. While the first phase of a project is primarily concerned with implementing a subset of features according to a predefined plan, an MVP is specifically designed to test hypotheses and gather feedback that will inform future development decisions. The MVP might not even resemble the final product if learning indicates a different direction would better serve user needs.

The “Red, Green, Refactor” cycle in TDD refers to the process of first writing a failing test (Red), then writing just enough code to make the test pass (Green), and finally improving the code while maintaining test compliance (Refactor). This methodical approach ensures all code is testable, functionality is fully covered by tests, and the implementation remains clean and maintainable.
Methodologies
Introduction to Scrum