Agile Software Development Overview

Agile Software Development

• Rapid development and delivery are crucial for modern software systems
• Stable software requirements are often impractical, especially in fast-changing environments
• Software must evolve quickly to reflect changing business needs
• Plan-driven approaches are suitable for safety-critical systems requiring in-depth analysis
• Agile development methods are better suited for business systems needing rapid adaptation
• Agile methods prioritize iterative development for quicker delivery of useful software
• Key characteristic of agile approaches :
  • Interleaved processes (specification, design, and implementation occur simultaneously) with minimal detailed documentation. User requirements are outlined rather than fully detailed.
  • Incremental development: Software is developed in increments with continuous input from end-users and stakeholders to adapt to changing needs.
  • Extensive tool support: Automated testing, configuration management, integration, and user interface production tools aid rapid development.

Agile Methods

• Agile methods are a form of incremental development
• Software is released in small, frequent updates (typically every two or three weeks)
• Close customer involvement is emphasized for rapid feedback and adaptation to changing requirements
• Formal documentation is minimized, favoring informal communication and meetings
• Design and implementation are central activities, with other activities integrated into these core processes
• Agile methods contrast with plan-driven approaches, which follow distinct stages with specific outputs to plan subsequent activities

Agile Methods (Differences between Plan-Driven and Agile)

• Plan-Driven Approaches: Iterations occur within individual stages (requirements, design, implementation), guided by formal documents
• Agile Approaches: Iterations happen across activities, with requirements and design developed concurrently. Agile methods prioritize flexibility and may code first, but are not necessarily exclusively code-focused
• Agile processes can incorporate design documentation and planned activities with some iterations dedicated to creating system models and documentation

Agile Methods (History and Applicability)

• In the 1980s and 1990s, software development focused more on extensive planning, formal quality assurance, and rigorous processes (particularly for large-scale/complex projects).
• However, with smaller/medium-sized business systems, this plan-driven approach had high overhead and less time spent on actual development and testing. This inefficiency led to the emergence of Agile methods in the late 1990s
• Agile methods are effective for product development (especially small-to-medium sized software) and developing custom systems (where customers are involved closely and external constraints are minimal)
  • These methods facilitate a flexible and collaborative environment

Agile Manifesto

• Values individuals and interactions over processes and tools
• Value working software over comprehensive documentation
• Value customer collaboration over contract negotiation
• Value responding to change over following a plan
• Key principles to achieve efficient software development:
  • Prioritizes delivery of working software quickly, adaptable to changing requirements and minimizing process bureaucracy and documentation
  • Focuses on practical, incremental development rather than extensive upfront planning
  • Balancing formal and informal aspects for efficient software delivery

Principles of Agile Methods

• Customer Involvement: Customers are involved throughout the development process, prioritizing and guiding requirements.
• Embrace Change: The system should be designed to easily accommodate changes in requirements.
• Incremental Delivery: Software is developed in increments, with the customer specifying each increment.
• Maintain Simplicity: Focus on simplicity in both the software development and the overall process, proactively eliminating complexity
• People, not Processes: Exploit the skills of the development team, allowing them freedom to work in ways best suited to their skills without rigid processes.

Agile Methods Applicability

• Suitable for product development, especially for companies developing small-to-medium sized software products
• Agile methods are highly appropriate for custom system development that involve active customer involvement in the development process

Problems with Agile Methods

• Customer Engagement: Keeping customers engaged throughout the project is often challenging.
• Team Suitability: Team members may struggle with the involvement demanded by agile practices
• Prioritization of Changes: Prioritizing changes across differing stakeholder needs can be complex
• Maintaining Simplicity: Teams may face difficulty consistently maintaining simple designs throughout iterations
• Contractual Issues: Challenges in handling flexible approach of Agile with traditional fixed-scope contracts.

Technical, Human, and Organizational Issues

• Requirement Detail: Detailed specifications and design are crucial if starting implementation first.
• Feedback and Delivery: Agile is best if rapid customer feedback and incremental delivery is feasible
• System Size: Agile is generally more suitable for smaller, co-located teams while a more traditional plan-driven approach is often better for larger teams with extensive needs
• System Type: For particularly complex systems (e.g., real-time systems), plan-driven approach may be more appropriate since analysis needs comprehensive planning.
• System Lifetime: For long-lifetime systems more detailed documentation for future support may be required.
• Technology: Agile methods often rely on tools to manage evolving designs
• Team Organization: Distributed or outsourced teams may require detailed documents.
• Cultural Issues: Traditional engineering cultures may prefer plan-based methods
• Team Skills: Agile methods often demand higher skill levels (compared to plan-based approaches)
• Regulation: Systems subject to external regulations (e.g., safety-critical systems) typically require detailed documentation

Extreme Programming (XP)

• Perhaps the best-known and widely used agile method
• Focuses on customer satisfaction, flexibility, and rapid iteration.
• Iterative Development:
  • Frequent Builds: New versions are built frequently.
  • Regular Deliveries: Increments are delivered often, allowing for feedback.
  • Rigorous Testing: All tests run for every build. A build is accepted only if all tests pass

XP and Agile Principles

• Incremental Development: Small, frequent releases of the system based on user feedback.
• Customer Involvement: Full-time customer engagement throughout the development
• People and Team Dynamics:
  • Pair Programming: Two developers work together at one station
  • Collective Ownership: Shared responsibility for codebase
  • Avoiding Long Hours: Sustainable work patterns to prevent burnout
• Support for Change: Frequent releases enable adjustments to evolving customer requirements
• Maintaining Simplicity: Ongoing improvements to the codebase through refactoring

XP and Agile Principles (Continued)

• Key Practices: Collective Ownership, Continuous Integration, Incremental Planning, On-site Customer, Pair Programming, Refactoring, Simple Design, Small Releases, Sustainable Pace, Test-First development.
  • The use of these practices aligns with core principles underpinning agile processes

Extreme Programming Release Cycle

• Select user stories for the release
• Break down stories into tasks
• Plan the release
• Develop/integrate/test software
• Release software
• Evaluate the system

Extreme Programming Practices

• Collective Ownership: All team members share responsibility, with no 'islands of expertise'
• Continuous Integration: New code is integrated into the whole system as soon as it's complete; all unit tests must pass after integration
• Incremental Planning: Requirements are documented on 'story cards.' Stories for a release are prioritized, then broken down into sub-tasks. Tasks are planned based on the available time.
• On-site Customer: A customer representative is involved full time, delivering system requirements to the team immediately and participating in decisions.
• Other practices include Pair Programming, Refactoring, Simple Design, Small Releases, and Sustainable Pace, Test-first development

Requirements Scenarios (XP)

• Customer Involvement: Customers are closely involved in making decisions about requirements to ensure alignment with user needs.
• User Stories: Requirements are expressed as short descriptions of user interactions with the system, creating a collaborative understanding of the project goal.
• Story Cards & Task Breakdown: User stories are written on cards and broken down into smaller implementation tasks which are used for scheduling and cost estimation
• Prioritization and Scheduling: Customers prioritize the user stories, and the team uses task estimates to plan and set deadlines for the development

Prescribing Medication Story Example

• Kate (a doctor) can prescribe medication using different options available within the system to check and confirm the dose according to the approval range. The system records the prescribed medication .

Test Case Description for Dose Checking

• Input: Dose (in mg) and daily frequency
• Tests: Correct inputs for single dose and frequency, testing for high/low doses, and range checks for combinations of dose and frequency
• Output: Error message if the dose is outside the range, 'OK' message if within range.

Test Automation

• Writing tests as executable components before implementing a task, simulating input and verifying outputs against specifications
• A consistent set of tests are available for quick execution after adding new functionality
• Automated test frameworks (e.g., JUnit) facilitate the creation and execution of tests

XP Testing Difficulties

• Programmers' Preferences: Developers may prefer coding over testing, leading to incomplete or insufficient testing.
• Complex Tests: Testing complex features (like user interfaces) poses challenges, particularly to accurately address display logic and inter-screen workflows
• Test Coverage: Ensures the entirety of all aspects within the system are covered in tests (this may be challenging given numerous tests).

Pair Programming

• Two programmers cooperate at one workstation to improve code clarity, quality, and teamwork.
• Dynamic Pairs:Team members are paired up regularly to encourage collaboration between team members
• Encourages Refactoring: Review of code by both programmers promotes code improvement and ongoing refactoring across the team.
• Productivity:Pair programming is often comparable to independent coding and sometimes more productive.
• Knowledge Sharing: Sharing knowledge and improving team collaboration between members

Advantages of Pair Programming

• Collective Ownership: Shared code responsibility among team members to promote a collaborative approach for problem-solving.
• Informal Review: Code is informally reviewed by both programmers which improves code quality
• Support for Refactoring: Enhancements to the code created by one pair are available for the whole team, which encourages broader participation and acceptance of continuous improvement

Scrum

• A general agile method focused on managing iterative development

Scrum Phases

• Initial Phase: Establishing project objectives and foundational software design
• Sprint Cycles: Developing and delivering increments of the system through iterative cycles
• Project Closure Phase: Finalizing the project by completing documentation, preparing user manuals, and assessing lessons learned.

Scrum Roles

• Product Owner: Defines features, prioritizes backlog and ensures features deliver business value
• Scrum Master: Facilitates team adherence to Scrum and removes impediments
• Development Team: A cross-functional group of professionals that are self-managing and focuses on delivering potentially shippable product increments (within Sprints)

Scrum Artifacts

• Product Backlog: Prioritized list of features, enhancements, and fixes. Evolves based on requirements
• Sprint Backlog: A subset of Product Backlog items selected for completion in a Sprint
• Increment: Sum of completed Product Backlog items in a Sprint plus the previous Sprints

Scrum Events

• Sprint: Timeboxed iteration (typically lasting 2-4 weeks), resulting in potentially shippable increment of work at the end of each sprint
• Sprint Planning: Team plans the work for the upcoming sprint.
• Daily Scrum: Daily 15-minute meeting for team to track progress, discuss roadblocks, and adapt plans
• Sprint Review: Team reviews the completed work of a sprint with stakeholders.
• Sprint Retrospective: Team reflects on the Sprint process

The Sprint Cycle

• The Sprint cycle outlines the steps taken during a time-boxed sprint to complete items on a prioritized backlog.
• It consists of steps including: planning, design, and development; testing, reviewing, and preparing the output for the next sprint.

The Sprint Cycle (Continued)

• Duration: Sprint duration (usually 2-4 weeks) results in the release of a system similar to the XP development process.
• Planning: The project team works with the customer to select and plan the features to be implemented during the sprint.
• Development: The team organizes and works on the development process without external distraction and with the help of the Scrum Master
• Review: Completed work is presented to stakeholders, allowing feedback to improve future sprints.

Teamwork in Scrum

• Scrum Master: Facilitates team daily meetings, tracks the backlog, communicates with stakeholders.
• Daily Meetings: Regular 15-minute meetings to track progress, discuss issues, and adjust plans.

Scrum Benefits

• Manageable Chunks: Breaking down the product into smaller components
• Adaptability to Change: Allows for easy adjustments to requirements
• Improved Communication: Enhanced visibility for the whole team to all aspects
• Customer Engagement: Frequent product delivery and feedback ensures the project remains aligned to needs
• Trust and Culture: Creates positive development environment

Scaling Agile Methods

• Scaling Agile involves adapting agile approaches for larger and more complex projects
• Successful for small projects: Agile methods work well in small-to-medium sized with co-located teams due to its enhanced communication aspects.
• Challenges of Scaling: Handling larger projects with potentially distributed teams, requires greater coordination, communication, and attention to detail. Agile scaling often needs modification to processes and practices to ensure effective collaboration.
• Communication Considerations: Communication may become a more critical concern when working with larger teams or distributed teams

Large Systems Development

• Multiple Teams and Locations: Large systems are often spread across teams/locations with potentially different time zones
• Brownfield Systems: Large systems often interact with existing systems, which makes it harder to implement flexibility;
• System Configuration: Large systems often heavily rely on configuration and potentially constrained by external regulation requirements,
• Extended Development Time: Changes in personnel may result in extended development times in large systems
• Diverse Stakeholders: Managing various stakeholder needs and interests for large systems can be very complex

Scaling Out and Scaling Up

• Scaling Up (Focus): Using Agile methods for large software systems involving larger teams.
• Scaling Out (Focus): Implementing Agile practices organization-wide.
• Fundamentals (Essentials for Scale): Keeping process flexible, prioritizing quick releases, ensuring constant integration, and maintaining robust communication.

Scaling Up to Large Systems

• Up-Front Design and Documentation: Essential for large systems to ensure complete design and system documentation upfront.
• Cross-team Communication: Effective mechanisms are crucial for communication among different teams.
• System Builds/Releases: Continuous integration of the entire system is essential to effectively administer large systems development.

Scaling Out to Large Companies

• Project Managers' Reluctance: Managers not well-versed in agile methodologies might be reluctant.
• Standards Compatibility: Ensuring compatibility with existing procedures and standards in large organizations, which might clash with agile methodologies.
• Skill Variability: Varying skill levels of team members across an organization can be difficult.
• Cultural Resistance: Resistance to agile methods by organizations with long-standing traditional systems engineering processes.

This quiz explores the principles and practices of Agile Software Development. Participants will learn about the iterative process, rapid delivery, and the importance of adapting to changing business needs. Discover how Agile methods differ from traditional plan-driven approaches and understand the role of user involvement in software evolution.