A Comprehensive Guide to Agile Methods, Scrum, and Extreme Programming
Software products must be brought to market quickly, making rapid software development and delivery essential. Virtually all software products are now developed using an agile approach that focuses on delivering functionality quickly, responding to changing product specifications, and minimizing development overheads.
Focus on delivering functional software incrementally and frequently to provide immediate business value.
Embrace changing requirements and specifications throughout the development process.
Reduce bureaucracy and documentation that doesn't directly contribute to software development.
Emphasize team collaboration, customer involvement, and continuous communication.
The most influential work that changed software development culture was the development of Extreme Programming (XP). The Agile Manifesto, created in 2001, formalized these principles and established agile methodologies as a mainstream approach to software development.
Extreme Programming (XP) is an agile software development methodology coined by Kent Beck in 1998. The name comes from the approach of pushing recognized good practices, such as iterative development, to "extreme" levels. XP introduced revolutionary development techniques geared toward rapid, incremental software development, change, and delivery.
User stories guide development with no grand upfront plan
Frequent delivery of minimal useful functionality
Write tests before writing code
Integrate and test code frequently
Continuously improve code structure
Anyone can change any code anywhere
Two programmers work together at one workstation
Work at a pace that can be sustained indefinitely
Customer representative is part of the team
Design for current requirements only
There is no 'grand plan' for the system. Requirements are established through discussions with a customer representative who is part of the XP team. User requirements are expressed as user stories or scenarios that describe what needs to be implemented in each increment.
Most CriticalThe minimal useful set of functionality that provides business value is developed first. Releases are frequent and incrementally add functionality to previous releases, ensuring continuous value delivery.
High ImpactInstead of writing code then tests, developers write tests first. This approach helps clarify what the code should actually do and ensures comprehensive test coverage from the beginning.
Quality FocusAs soon as work on a task is complete, it is integrated into the whole system and a new version is created. All unit tests from all developers run automatically and must succeed before the new version is accepted.
AutomationRefactoring means improving the structure, readability, efficiency, and security of a program without changing its functionality. All developers are expected to refactor code as soon as potential improvements are found, keeping the code simple and maintainable.
Continuous ImprovementContext: The patient record must be open for input. Click on the medication field and select either 'current medication', 'new medication', or 'formulary'.
Scenario 1 - Current Medication: If you select 'current medication', you will be asked to check the dose. If you wish to change the dose, enter the new dose then confirm the prescription.
Scenario 2 - New Medication: If you choose 'new medication', the system assumes you know which medication you wish to prescribe. Type the first few letters of the drug name. You will see a list of possible drugs starting with these letters. Choose the required medication, verify your selection is correct, enter the dose, then confirm the prescription.
Scenario 3 - Formulary: If you choose 'formulary', you will be presented with a search box for the approved formulary. Search for the drug required then select it. Verify the medication you have selected is correct, enter the dose, then confirm the prescription.
Safety Check: In all cases, the system will check that the dose is within the approved range and will ask you to change it if it is outside the range of recommended doses.
Final Confirmation: After you have confirmed the prescription, it will be displayed for checking. Either click 'OK' or 'Change'. If you click 'OK', your prescription will be recorded on the audit database. If you click 'Change', you reenter the 'Prescribing medication' process.
Implement functionality to modify the dosage of an already prescribed medication
Develop the interface and logic for searching and selecting from the approved formulary
Dose checking is a safety precaution to check that the doctor has not prescribed a dangerously small or large dose. Using the formulary id for the generic drug name, lookup the formulary and retrieve the recommended maximum and minimum dose. Check the prescribed dose against the minimum and maximum. If outside the range, issue an error message saying that the dose is too high or too low. If within the range, enable the 'Confirm' button.
Example of a unit test written before implementation code
Input:
Tests:
Output:
OK or error message indicating that the dose is outside the safe range
Unlike conventional wisdom in software engineering that advocates designing for change, XP maintains that anticipating changes is not worthwhile as changes cannot be reliably anticipated. Instead, XP emphasizes keeping code simple through continuous refactoring, making it easier to adapt when actual changes occur.
Scrum is an agile method that focuses on managing iterative development rather than specific agile practices. It provides a framework for organizing and managing work, allowing teams to choose their own technical practices. Scrum is particularly effective for projects where plans always change and long-term plans are unreliable.
Outline planning phase where general objectives are established and software architecture is designed
Series of sprints where each cycle develops an increment of the system
Wraps up the project, completes documentation, and assesses lessons learned
Identifies product features and requirements, prioritizes the product backlog, and ensures the project meets critical business needs. Can be a customer, product manager, or stakeholder representative.
Ensures the Scrum process is followed and guides the team in effective use of Scrum. Responsible for interfacing with the company and ensuring the team is not diverted by outside interference.
Self-organizing group of software developers (typically 5-9 people) responsible for developing the software and essential project documents. The team manages itself and creates "Done" increments.
| Term | Definition |
|---|---|
| Sprint | A development iteration, usually 2-4 weeks long, during which a potentially shippable product increment is created |
| Product Backlog | A prioritized list of 'to do' items including features, requirements, user stories, and other tasks that need to be addressed |
| Sprint Backlog | The set of Product Backlog items selected for the Sprint, plus a plan for delivering the product increment |
| Daily Scrum | A 15-minute daily meeting where the team reviews progress and plans work for the next 24 hours |
| Potentially Shippable Product Increment | The software delivered from a sprint that is in a finished state requiring no further work to incorporate into the final product |
| Velocity | An estimate of how much product backlog effort a team can cover in a single sprint, used for planning and measuring improvement |
The product backlog is a living document that lists everything needed to complete the product. Items include product features, user requests, development activities, and engineering improvements. The backlog should always be prioritized with the highest-priority items at the top.
High-level ideas and feature descriptions that are tentative and may radically change or may not be included in the final product.
Items the team has agreed are important and should be implemented. There is a reasonably clear definition, but more work is needed to understand and refine the item.
The PBI has enough detail for the team to estimate effort and implement. Dependencies on other items have been identified.
New PBIs are added based on stakeholder needs and team discoveries
PBIs are broken down into smaller, more detailed items
Team estimates effort required for each PBI
Product Owner orders items by business value and dependencies
Team selects highest-priority items from product backlog and creates sprint backlog
Team implements sprint backlog items with daily scrum meetings every 24 hours
Demonstrate new functionality to stakeholders
Team reflects on process and identifies improvements
A 15-minute daily standup meeting where team members respond to three basic questions:
This meeting helps maintain team alignment, identify blockers quickly, and promote accountability.
Each sprint should produce a potentially shippable product increment. This means the developed software should be complete, tested, and ready to deploy without requiring additional work. While this ideal is not always achievable in practice, it remains the target standard.
Responsibility: Product Owner
Responsibility: Scrum Master
While Scrum developers envisioned the Scrum Master as a coach rather than a traditional project manager, in practice, many organizations require someone to handle project management responsibilities. The Scrum Master often takes on these duties as they have the best knowledge of work progress and team dynamics.
A self-organizing team is a development team that organizes the work to be done by discussion and agreement amongst team members rather than being directed by a manager. Teams make their own decisions about how to accomplish sprint goals, work distribution, and technical approaches.
Timeboxing is the practice of setting fixed time periods for activities. In Scrum, sprints are typically 2-4 weeks long and never extended. This creates urgency, forces prioritization, and ensures regular delivery of working software.
Code is integrated into the main codebase multiple times per day. Automated builds and tests run with each integration to catch problems early.
High PriorityAutomated tests run continuously throughout development. New code is not accepted unless all tests pass, maintaining quality standards.
Quality GateSoftware is always in a deployable state. Teams can release to production at any time with confidence.
Advanced PracticeTeams estimate work using relative sizing (story points) rather than hours. Velocity measures how many story points a team completes per sprint, helping predict future capacity and improve planning accuracy over time.
| Story Points | Complexity Level | Typical Duration |
|---|---|---|
| 1-2 | Simple, well-understood | Few hours to 1 day |
| 3-5 | Moderate complexity | 1-3 days |
| 8-13 | Complex, some unknowns | 3-5 days |
| 21+ | Very complex, needs breakdown | Too large - should be split |
Software development methodologies exist on a continuum from highly predictive (traditional waterfall) to highly adaptive (agile). Understanding where different approaches fall on this spectrum helps teams choose the right methodology for their context.
| Aspect | Predictive (Waterfall) | Iterative | Incremental | Agile |
|---|---|---|---|---|
| Planning | Extensive upfront | Moderate upfront | Rolling wave | Just-in-time |
| Requirements | All defined upfront | Refined each iteration | Prioritized tranches | Evolving continuously |
| Delivery Frequency | Single release at end | Periodic milestones | Regular increments | Continuous delivery |
| Change Approach | Controlled, documented | Managed per iteration | Planned increments | Embraced continuously |
| Team Structure | Hierarchical roles | Defined roles | Mixed roles | Self-organizing |
| Customer Involvement | Beginning and end | Periodic reviews | Increment reviews | Continuous collaboration |
| Documentation | Comprehensive | Moderate | Lighter | Minimal, just sufficient |
| Best For | Stable requirements, regulated environments | Refinement needed but scope known | Partial delivery valuable | Uncertain requirements, rapid change |
Low →→→ High
Predictive methods work best with low change, while agile methods thrive with high change rates.
Low →→→ High
Agile methods deliver value frequently, while predictive methods deliver once at project completion.
Agile methods are based around iterative development and the minimization of overheads during the development process. They prioritize working software, customer collaboration, and responding to change over following rigid plans.
Extreme programming (XP) is an influential agile method that introduced revolutionary practices now considered mainstream:
These practices have become standard in modern software development regardless of whether teams explicitly follow XP.
Scrum is an agile method that focuses on agile planning and management rather than prescribing specific engineering practices:
Can be used in any agile process to manage and prioritize work items, regardless of whether full Scrum is adopted.
Fixed-duration sprints create predictability and force regular delivery, applicable to any iterative approach.
Empowering teams to make decisions improves engagement and outcomes in any development context.
Delivering working software frequently provides value early and enables continuous feedback.
Success with agile methods requires commitment from the entire organization, not just the development team. It demands cultural changes, management support, and a willingness to continuously learn and adapt. Start small, learn from experience, and gradually expand agile practices as the organization becomes more comfortable with the approach.