Agile Software Development Introduction

Introduction to Agile Software Development

• Rapid development and delivery are crucial for software systems, due to fast-changing business needs
• Agile methods suit business systems needing rapid adaptability due to their focus on iterative development
• Plan-driven approaches remain appropriate for software types requiring thorough analysis, such as safety-critical systems

Key Characteristics of Agile Approaches

• Interleaved processes mean specification, design, and implementation occur simultaneously with minimal detailed documentation
• User requirements are outlined rather than fully detailed in interleaved processes
• Incremental development involves developing software in increments, adapting to changing needs with feedback from end-users and stakeholders
• Agile development processes have extensive tool support for automated testing, configuration management, integration, and user interface production

Agile Methods Overview

• Agile methods use incremental development with frequent software releases, typically every 2-3 weeks
• Emphasis is placed on customer involvement for rapid feedback and adaptability to changing requirements
• Agile development minimizes formal documentation, favoring informal communication over structured meetings and written documents
• In agile methodologies design and implementation are central, and integrated with requirements elicitation and testing

Agile vs Plan-Driven Approaches

• Plan-driven approaches iterate within individual stages using formal documents to guide transitions
• Formal requirements specification document directs design and implementation phases in plan-driven approaches
• Agile approaches iterate across activities, with requirements and design developed concurrently
• Agile methods prioritize flexibility and may focus on coding, but aren't exclusively code-focused
• Agile processes can include design documentation and planned activities, dedicating iterations to creating system models and documentation

Historical Context of Agile Methods

• Software development in the 1980s/early 1990s focused on extensive planning, quality assurance, and processes, particularly for large-scale projects
• These approaches worked well for complex, long-term projects with dispersed teams
• Applying this approach to smaller business systems led to excessive overhead
• Inefficiency highlighted the need for flexible methods, resulting in the emergence of agile methods in the late 1990s

Agile Manifesto Values

• Agile values individuals and interactions over processes and tools
• They value working software over comprehensive documentation
• They value customer collaboration over contract negotiation
• They value responding to change over following a plan

Agile Manifesto Principles

• Prioritizes delivering working software quickly and adapting to changing requirements
• Agile minimizes process bureaucracy and documentation, focusing on practical, incremental development
• Emphasizes valuing individuals and interactions over processes and tools
• Prioritizes working software over comprehensive documentation
• Encourages customer collaboration over strict contract negotiation
• Supports adapting to change rather than rigidly following a plan
• Agile favors a flexible and responsive approach to software development

Principles of Agile Methods and Descriptions

• Customer Involvement: Customers should be closely involved throughout the development process
• Their involvement provides and prioritizes new system requirements, alongside evaluating iterations of the system
• Embrace Change: System requirements are expected to change, designing the system to accommodate
• Incremental Delivery: Software is developed in increments, with the customer specifying the requirements to be included
• Maintain Simplicity: Focus on simplicity in both the software and the development process; actively work to eliminate complexity
• People, Not Process: Development team skills should be recognized and exploited, developing their own working methods without prescriptive processes

Agile Method Applicability

• Agile methods are effective in two main areas: product development and system development
• Agile approaches are standard practice for software companies creating small to medium-sized products for sale
• Agile methods are well suited in organizational contexts where customers are actively involved and there are minimal external constraints
• Agile practices are widely used for commercial product development and internal system projects due to their flexibility and collaborative nature

Problems with Agile Methods

• Maintaining consistent customer engagement and interest throughout the development process can be challenging
• Continuous customer involvement is crucial, given that not all have the time or commitment to stay engaged
• Team Suitability: Agile methods require intense involvement and collaboration
• Team members who are not accustomed to or comfortable with this level of engagement may struggle
• Prioritizing Changes: Prioritizing changes can be complex when multiple stakeholders are involved
• Differing priorities and needs can make aligning on what changes should be implemented difficult
• Maintaining Simplicity: Agile methods emphasize simplicity, needing ongoing refinement in processes and designs
• Contractual Issues: Agile approaches can face challenges with contracts, especially with iterative development
• Traditional contracts often assume a fixed scope, agile’s flexible nature can complicate contract management/scope definition

Technical, Human, and Organizational Issues

• Most projects include both plan-driven and agile elements
• Choice depends on factors like detail requirements, feedback, system size, and system type
• Detailed Requirements: Plan-driven needed when specification and design are crucial before implementation
• Feedback and Delivery: Agile works when incremental software delivery and customer feedback is feasible
• System Size: Agile is best for small, co-located teams, while plan-driven may work best for larger systems with extensive teams
• System Type: Plan-driven needed for complex systems with critical requirements needing extensive analysis

Additional Technical, Human, & Organizational Issues

• System Lifetime: Detailed design documentation may be needed for future support
• Technology: Agile relies on tools for managing evolving designs
• Team Organization: Design documents may be needed for distributed or outsourced teams to coordinate
• Cultural Issues: Plan-based methods are favored in traditional engineering cultures
• Team Skills: Agile may demand higher skill levels compared to plan-based approaches
• Regulation: Detailed documentation is typically required in systems subject to external regulation

Extreme Programming (XP)

• XP is a widely used agile methodology introduced by Kent Beck in the late 1990s
• XP enhances customer satisfaction, flexibility, and rapid iteration.
• Frequent Builds: New software versions can be built several times a day for rapid adjustments and improvements
• Regular Deliveries: Increments are delivered to customers every two weeks for frequent feedback and alignment
• Rigorous Testing: All tests must run and pass for every build, assuring high quality and reliability

Extreme Programming and Agile Principles

• XP aligns closely with agile principles
• XP supports incremental development by delivering small, frequent system releases
• This strategy provides constant user feedback and adaption
• XP requires full-time customer engagement
• Encourages team dynamics and productivity through Pair Programming

Collective Ownership, Change, and Simplicity in XP

• Collective Ownership: All team members share responsibility, allowing changes whilst encouraging a sense of shared ownership
• Avoiding Long Hours: XP advocates for sustainable work practices; emphasis on workload management
• Support for Change: Regular system releases facilitate adaptability by delivering incremental updates
• Maintaining Simplicity: Refactoring and simplification of the codebase for a clean, efficient and maintainable software

Refactoring Defined

• XP argues against designing for change, because preparing for anticipated changes can prove unnecessary
• XP argues for improving code structure and readability, with constant refactoring
• Refactoring makes incremental improvements: reorganizing class hierarchies and consolidating code
• Refactoring prevents software structure degradation but can be difficult due to pressure, and significant architectural changes

Key Tenets of XP Testing

• Extreme Programming integrates automated testing into core development, to address formal testing processes
• Testing is automated and crucial, progressing only with successful tests
• Testing is central to XP, and tests occur after every change
• XP testing features test-first development, and incremental tests from scenarios
• It also uses user involvement, and automation for new releases to component tests

XP Test-First Development

• Requirements are clarified when tests are written before code
• Tests are written as automated executable programs that include a check of execution
• Testing framework, such as Junit, facilitates the writing and execution of tests
• All tests run automatically to ensure that new functionality has not introduced errors
• All testing benefits greatly from customer involvement, but customers may be able to fully engage in the testing process

Test Automation

• Test automation involves writing tests as executable components before a task is implemented
• Tests are designed to be independent, simulate input submission, and verify outputs
• JUnit (test framework) facilitates the test creation
• Set of tests is always available. Run the tests immediately after adding new functionality to identify new issues introduced by code

XP Testing Difficulties

• Developers typically prefer coding over testing; this means developers may take shortcuts
• Writing incremental testing can be hard; especially for user interfaces with display logic & workflows
• Assessing the test completeness can be hard
• It’s challenging to ensure a set of tests covers all software aspects as needed

Dynamic Pairs and Impacts in Pair Programming

• Using dynamic pairs ensures all programming benefits from code improvements, via team collaboration
• Collective code review supports refactoring
• Pair programming shows comparable productivity
• Sharing code ensures no reliance on individual team members

Pair Programming Advantages

• Group shares responsibility for the code, to avoid accountability for individuals
• Each line of codes is examined
• Facilitates refactoring for the team, because improvements lead to ongoing code enhancements

Scrum Introduction

• General agile method focuses on managing iterative development
• Scrum focuses on iterative development, not specific practices
• Establishment of objectives, then activities to create a design for the software occurs, ending with project closure

Three Scrum Phases

• 1st Initial Phase: Establish Objectives & Design the Architeture with OUTLINED Activities
• 2nd Sprint Cycles: Each Sprint builds/refines a product by developing and iteratively delivering, with Review/Reflection activities
• 3rd Project Closure Phase: Finalizing the necessary documentation includes preparing frames/manuals, assessing future projects

Scrum Methodology: Key Roles and Responsibilities

• Product Owner: Defines and prioritizes backlog features, to ensure maximum business value
• Scrum Master: Facilitates processes, removes obstacles, and ensures good communication
• Development Team: Cross-functional group delivers shippable increments as self-organizing, working to manage their work

Scrum Terminology: Artifacts Explained

• Product Backlog: Managed by a Product owner, prioritized, with evolving requirements
• Sprint Backlog: Subset of a product backlog, completed, created by the development team
• Increment: Completed Sprint Backlog items & Previous Sprints, but usable

Scrum Defined

• Specific product backlog times usually completed from two to four weeks, but a potentially shippable product increment is delivered at the iteration and sprint
• At the start, meeting has a team where plans are delivered. Accomplishments, plans, and delivered for the sprint
• Daily Alignment (15 minutes), identifying impediments (short meeting) with synchronize, progress
• Feedback Sprint (stakeholders meeting), progress and adjustments for assessment to review that all the completed work
• The spring retrospective (team reflects process in it’s spring review) which identifies what's going well or not so to improve current sprints

Sprint Cycle

• Sprints are typically 2 to 4 weeks long, and result in a system release similar to XP
• Team collaborates to pick features for the Sprint
• Team shields from external distractions
• Communication is managed through the Scrum Master
• Completed work is reviewed and presented to stakeholders.

Teamwork in Scrum: Roles and Responsibilities

• Scrum Master: facilitates daily meetings, tracking the backlog, recording decisions, measuring progress and communicates with stakeholders
• Daily Meetings: The team shares progress updates, discusses issues, and plans for the next day; to all team members can adjust when necessary to ensure good communication

Scrum Frameworks and Advantages

• The framework provides smaller products for smaller prices
• To adapt to changes, is an improved communication to provide higher understanding
• Customers engagement see products with new releases as culture and trust between all of the team members

Agile Scaling: Key Points

• Scaling Agile involves handling complex projects with multiple teams and locations
• Success in smaller teams; communication and collaboration
• Agile's communications will be strained, adjustments will be needed
• Communication will be more challenging
• Changes require modifications and communication across locations and teams

Complexities in Large Systems Development

• Systems often involve multiple teams and locations spread across various time zones
• Requirements can be rigid by external systems
• Systems involve configuration instead of development
• Over time, long development create changes to the team
• Diverse Stakeholders are ineffective in the development method

Scaling for Agile success

• Scaling out and scaling up are approaches to applying Agile in larger environments
• Scaling up involves adapting the practices to manage; focusing the scaling to develop large systems
• Scaling out involves implementing an agile method

Top-Down Strategy: Key Elements in Agile Approaches

• FlexiblePlanning adapts what changes and needed; test driven needs tests before coding/functionality for better communication

Scaling towards the top system

• Up-Front for changes, not needed in documentation
• System builds the releases; codes need team communication systems and electronic meetings
• Coding is insufficient from continuous integration code changes. Need regular system builds and changes

Implementation resistance from project managers- standardization for diverse skill sets

• Reluctance from Project Managers is caused via project managers that are unfamiliar, causing hesitancy and perceived risks
• Compatibility occurs from conflicts; if organizations have a high standard
• Skill Variability depends on skill levels amongst the employees
• Historical processes can create resistance