Browse Courses

Agile Methodologies

May 26, 2025 7 min read Agile DevOps Programming Docs IBM-DevOps Agile-Methodologies Xp Kanban Waterfall

This document explores various software development methodologies, contrasting the traditional Waterfall approach with Agile methodologies such as Extreme Programming (XP) and Kanban. It examines the limitations of the sequential Waterfall model and highlights how iterative, feedback-driven approaches address these challenges.

On this page
Agile Methodologies

This document explores various software development methodologies, contrasting the traditional Waterfall approach with Agile methodologies such as Extreme Programming (XP) and Kanban. It examines the limitations of the sequential Waterfall model and highlights how iterative, feedback-driven approaches address these challenges through continuous improvement, team collaboration, and adaptive planning.

Traditional Waterfall Development

The Waterfall approach to software development is a sequential, linear process where each phase must be completed before the next begins. The methodology follows a strict progression through distinct phases:

PhaseDescriptionKey Activities
RequirementsInitial phase where customer needs are documentedGathering and documenting all requirements
DesignArchitects plan the entire system architectureCreating system designs based on requirements
CodingDevelopers implement the designWriting code to implement the design
IntegrationCombining separately developed componentsAssembling modules into a complete system
TestingVerifying the system works correctlyFinding and reporting bugs for fixing
DeploymentReleasing the software to productionDelivering the final product to operations

Each phase has specific entrance and exit criteria that must be met before moving to the next phase. This structured approach resembles a waterfall, where progress flows downward through each stage.

Problems with the Waterfall Approach

The Waterfall methodology presents several significant challenges in software development:

  1. No Provision for Change: Once a phase is complete, revisiting it is difficult and expensive.

  2. Late Validation: The software isn’t tested as a whole until late in the process, after significant investment.

  3. Sequential Handoffs: Each step ends when the next begins, creating opportunities for information loss.

  4. Costly Late-Stage Errors: Mistakes found in testing that require design changes are extremely expensive to fix.

  5. Long Lead Times: The time from initial requirements to delivery can be extensive.

  6. Team Isolation: Teams work in silos, unaware of how their work impacts other phases.

  7. Operations Disconnect: The operations team, responsible for running the software in production, often has the least knowledge about how it works.

Extreme Programming (XP)

Extreme Programming (XP) was introduced in 1996 by Kent Beck as an iterative approach to software development. It features nested feedback loops of different timeframes:

Feedback LoopTimeframeActivities
Release PlanningMonthsPlanning major feature releases
Iteration PlanningWeeksPlanning short development cycles
Acceptance TestsDaysVerifying features meet requirements
Stand-up MeetingsDailyCoordinating team activities
Pair NegotiationHoursCollaborative problem-solving
Unit TestingMinutesTesting individual components
Pair ProgrammingContinuousReal-time code review and collaboration

This structure creates increasingly tighter loops of work and feedback, allowing teams to be responsive to change and continuously improve software quality. XP is widely recognized as one of the first Agile methodologies.

XP Values

Extreme Programming is built on five core values:

  1. Simplicity: Develop only what is needed without over-engineering. Focus on the minimal viable solution that meets requirements.

  2. Communication: Ensure everyone on the team is aware of what others are doing through constant interaction and information sharing.

  3. Feedback: Maintain short feedback loops at all levels to quickly validate work and make adjustments.

  4. Respect: Value every team member’s contributions equally, treating all suggestions with consideration regardless of role.

  5. Courage: Be honest about capabilities and estimates without padding timelines or hiding difficulties.

Kanban

Kanban originated in Japanese manufacturing systems—the term literally means billboard sign. It was developed by J. Visual Kanban in 1954 and later popularized by Toyota in Japan. It is a visual tool that helps teams visualize the workflow, limit work in progress, and continuously improve the flow of work through the system. Kanban was designed to manage continuous flow on the manufacturing floor using cards or notes that travel with the product through each production stage.

Core Principles of Kanban

Kanban is guided by several fundamental principles:

  1. Visualize the Workflow: Make all work visible through tools like Kanban boards. If work can't be seen, it can't be managed effectively.

  2. Limit Work in Progress (WIP): Restrict the amount of concurrent work to prevent bottlenecks and ensure focus on completing tasks rather than starting new ones.

  3. Manage and Enhance Flow: Continuously monitor and improve the movement of work through the system to increase efficiency.

  4. Make Policies Explicit: Ensure everyone understands how the process works and what constitutes “done” for each task.

  5. Continuously Improve: Regularly review and refine processes to achieve better outcomes over time.

Kanban’s focus on visualizing workflows, limiting work in progress, and continuous improvement has been widely adopted in Agile software development practices.

Conclusion

Software development methodologies have evolved from the rigid, sequential Waterfall approach to more adaptive, iterative frameworks like Extreme Programming and Kanban. While Waterfall offers structure and predictability, it struggles with responding to change and often reveals problems too late in the development cycle. In contrast, Agile methodologies emphasize frequent feedback, team collaboration, and continuous improvement, enabling teams to deliver higher quality software that better meets customer needs in rapidly changing environments.

FAQ

The Waterfall methodology is named after the way progress flows downward through sequential phases, with each phase needing to be completed before the next begins. Just as water in a waterfall flows in one direction and cannot easily flow back up, it’s difficult to revisit earlier phases once they are completed in this methodology.

If a critical design flaw is discovered during the testing phase in a Waterfall project, the most likely outcome is expensive and time-consuming rework. Since the design phase was completed long before testing began, developers would need to “swim up the waterfall” to revisit and modify the design, potentially invalidating much of the coding work already completed.

In a scenario where customer requirements frequently change, an Agile methodology like Extreme Programming (XP) would be most appropriate. XP’s nested feedback loops allow for constant adaptation to changing requirements, unlike the Waterfall approach which has no provision for change once a phase is complete.

The statement that “Kanban requires fixed-length iterations like Scrum” is incorrect. Kanban is a continuous flow system that does not require fixed-length iterations. Instead, it focuses on visualizing workflow, limiting work in progress, and continuous improvement without timeboxed sprints.

The concept that “over-engineering and adding features not explicitly requested by customers creates waste and maintenance burden” can most likely be inferred from the XP value of Simplicity. This value emphasizes doing only what is needed and not more, avoiding unnecessary complexity that doesn’t add customer value.

Extreme Programming addresses team isolation through its emphasis on communication as a core value and practices like pair programming, daily stand-ups, and whole-team collaboration. These practices ensure team members are aware of each other’s work and the impact it has on the overall project, creating a shared understanding instead of siloed knowledge.

When implementing Kanban, visualizing the workflow should be prioritized first. Before you can improve the process or limit work in progress, you need to make the current work visible and understand how it flows through the system. As the principle states, “if you can’t see the work, you can’t manage the work.”

Quarterly retrospectives are NOT a feedback loop timeframe in Extreme Programming. XP includes feedback loops at various timeframes such as months (release planning), weeks (iteration planning), days (acceptance tests), daily (stand-up meetings), hours (pair negotiation), minutes (unit testing), and seconds (pair programming), but does not specifically incorporate quarterly retrospectives.

The XP value of “Courage” primarily relates to honesty in estimations and capabilities. It emphasizes being truthful about what the team can accomplish without padding estimates or making unrealistic commitments, even when under pressure to do so.

Limiting Work in Progress in Kanban focuses teams on completing tasks rather than starting new ones, which leads to faster delivery of individual features, reduced context switching, and quicker identification of bottlenecks in the development process. This principle recognizes that delivering 100% of one feature is more valuable than delivering 50% of two features.
Agile Principles
Agile Workflow