Agile Software Development An Alternate Approach Umar K. Munroe MSCS Candidate Union College 1/9/2004

Topics of Discussion Why an alternate approach Why an alternate approach Overview of Agile Software Development Overview of Agile Software Development Agile Processes Agile Processes Limitations of Existing Agile Processes Limitations of Existing Agile Processes Adoption & Future in Industry Adoption & Future in Industry

Why an alternate software development approach? Traditional Approaches  Slow & Rigid Traditional Approaches  Slow & Rigid Highly structured Highly structured Detailed process scripts Detailed process scripts Required Artifacts (i.e. documents) Required Artifacts (i.e. documents)

Why an alternate software development approach? Internet & mobile technology increase demand for software development to Internet & mobile technology increase demand for software development to to be faster to be faster more responsive to change more responsive to change Traditional methods aren’t exactly working well Traditional methods aren’t exactly working well 13,522 IT projects (Standish Group, 2002) 13,522 IT projects (Standish Group, 2002) 34% on-time, on-budget, sufficient functionality 34% on-time, on-budget, sufficient functionality 51% late, over-budget, less functionality 51% late, over-budget, less functionality 15% fail 15% fail

Agile Software Development Quick development Quick development Responsive to changing requirements Responsive to changing requirements Simple, straightforward process Simple, straightforward process Frequent customer involvement and feedback Frequent customer involvement and feedback Guide development Guide development Iterative, incremental development Iterative, incremental development Provides flexibility, responsiveness Provides flexibility, responsiveness

Agile Alliance In 2001, software industry experts formed the Agile Alliance In 2001, software industry experts formed the Agile Alliance Goals: Goals: Outline values and principles of agile software development Outline values and principles of agile software development Promote agile software development in industry Promote agile software development in industry

Agile Manifesto

Value #1: Individuals and interactions over process and tools “A good process will not save the project from failure if the team doesn’t have strong players, but a bad process can make even the strongest of players ineffective.” Robert C. Martin “A good process will not save the project from failure if the team doesn’t have strong players, but a bad process can make even the strongest of players ineffective.” Robert C. Martin people and their relationships most important to a successful project people and their relationships most important to a successful project

Value #1: Individuals and interactions over process and tools Team Team motivated motivated good programmers (not necessarily most talented) good programmers (not necessarily most talented) excellent communication skills excellent communication skills Tools and environment built around team, not vice versa Tools and environment built around team, not vice versa

Value #2: Working software over comprehensive documentation Documentation produced only when necessary Documentation produced only when necessary Short – one or two dozen pages at most Short – one or two dozen pages at most Less time Less time Salient – describing the overall design rationale and only high level structures in the system Salient – describing the overall design rationale and only high level structures in the system Details likely to change Details likely to change Primary goal is working software Primary goal is working software Demonstrated to customer frequently Demonstrated to customer frequently Measure of progress Measure of progress

Value #3: Customer collaboration over contract negotiation "A contract that specifies the requirements, schedule, and cost of a project is fundamentally flawed." Robert C. Martin "A contract that specifies the requirements, schedule, and cost of a project is fundamentally flawed." Robert C. Martin Contracts govern the working relationship between developers and customer Contracts govern the working relationship between developers and customer Customer is intimately involved Customer is intimately involved Guide development Guide development

Value #4: Responding to change over following the plan Change is expected Change is expected Planning Strategy (iterative) Planning Strategy (iterative) a detailed plan over the next 2 weeks a detailed plan over the next 2 weeks a very rough plan for the next 3 months a very rough plan for the next 3 months an extremely crude plan beyond 3 months an extremely crude plan beyond 3 months Minimize time wasted planning too far into the future Minimize time wasted planning too far into the future

Agile Development: 12 Principles 1)Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 2)Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage 3)Deliver working software frequently, from a couple of weeks to a couple of months, with a preference of a shorter time scale 4)Business people and developers must work together daily throughout the project

Agile Development: 12 Principles 5)Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6)The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7)Working software is the primary measure of progress 8)Agile process promote sustainable development. The sponsors, developers, and user should be able to maintain a constant pace indefinitely.

Agile Development: 12 Principles 9)Continuous attention to technical excellence and good design enhances agility. 10)Simplicity – the art of maximizing the amount of work not done – is essential 11)The best architectures, requirements, and designs emerge from self organizing teams 12)At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Agile Processes Typically, Typically, Less structured Less structured Practices and rules Practices and rules Selected Agile Processes Selected Agile Processes eXtreme Programming (XP) eXtreme Programming (XP) Scrum Scrum Dynamic Systems Development Method (DSDM) Dynamic Systems Development Method (DSDM)

eXtreme Programming (XP) Most famous and documented agile process Most famous and documented agile process Rules & practices Rules & practices Developed by Kent Beck mid 1990’s Developed by Kent Beck mid 1990’s More info: More info:

XP: Concepts/Practices Customer Team Member Customer Team Member Highly accessible (on-site) Highly accessible (on-site) User Stories over detailed requirements User Stories over detailed requirements Describe functionality Describe functionality Reduces unnecessary upfront restrictions Reduces unnecessary upfront restrictions Simple Design Simple Design Quick, easy, sufficient Quick, easy, sufficient

XP: Concepts/Practices Test Driven Development Test Driven Development Tests written first, code written to make tests pass Tests written first, code written to make tests pass Automated Automated Acceptance Tests Acceptance Tests Verify user stories Verify user stories Written before implementation Written before implementation Short Cycles Short Cycles 2-3 month releases 2-3 month releases 2 week Iterations 2 week Iterations

XP: Concepts/Practices Pair Programming (2 people, 1 computer) Pair Programming (2 people, 1 computer) Generate production code Generate production code Transfer Knowledge Transfer Knowledge Better Quality  Faster development Better Quality  Faster development Collective Ownership Collective Ownership Team knowledgeable in all aspects of project Team knowledgeable in all aspects of project Open Workspace Open Workspace Easy access for conversation Easy access for conversation Limits team size(<10 people) Limits team size(<10 people)

XP: Concepts/Practices Continuous Integration Continuous Integration Refactoring Refactoring tiny transformations to improve the structure of the code without changing its behavior tiny transformations to improve the structure of the code without changing its behavior continuous continuous Metaphor Metaphor Provides “big picture” of the system Provides “big picture” of the system

XP: Concepts/Practices Sustainable Pace Sustainable Pace 40 hr week 40 hr week Planning Game Planning Game Plan made at the start of each iteration and release Plan made at the start of each iteration and release Customer decides which user stories to implement next Customer decides which user stories to implement next

XP: Project Lifecycle

Scrum Management approach using existing processes and practices Management approach using existing processes and practices empirical approach based in control systems theory empirical approach based in control systems theory Developed (mid 90’s) & maintained by Advanced Development Methods (ADM, Inc) Developed (mid 90’s) & maintained by Advanced Development Methods (ADM, Inc) Training and certification available Training and certification available

Scrum: Key Concepts/Practices Product Backlog Product Backlog Defines everything needed in the final product Defines everything needed in the final product Goals, Resources Goals, Resources Constantly updated Constantly updated Sprint (Cycles) Sprint (Cycles) ~30 days ~30 days Production of an executable product increment Production of an executable product increment Requirements relatively frozen during Sprint Requirements relatively frozen during Sprint

Scrum: Key Concepts/Practices Sprint Planning Meeting Sprint Planning Meeting Goals and functionality of sprint Goals and functionality of sprint Decide an implementation approach Decide an implementation approach Sprint Backlog Sprint Backlog Items specific to the Sprint from the Product Backlog Items specific to the Sprint from the Product Backlog Small teams (5 to 9 people) Small teams (5 to 9 people)

Scrum: Key Concepts/Practices Daily Scrum Meeting Daily Scrum Meeting ~15 minutes ~15 minutes 3 questions addressed by each team member 3 questions addressed by each team member What did you do since the last meeting? What did you do since the last meeting? Any obstacles or issues? Any obstacles or issues? What will you do before the next meeting? What will you do before the next meeting? Sprint Review Meeting Sprint Review Meeting Demonstrate implemented functionality Demonstrate implemented functionality Make decisions as to the next sprint Make decisions as to the next sprint

Scrum: Sprint Lifecycle

Feature Driven Development (FDD) Focuses on the design and implementation Focuses on the design and implementation Well defined process Well defined process Detailed Process Scripts Detailed Process Scripts ocessesA4.pdf ocessesA4.pdf ocessesA4.pdf ocessesA4.pdf Utilizes best practices found to be effective in industry Utilizes best practices found to be effective in industry Developed by Peter Coad, Jeff De Luca, And Stephen Palmer in the late 1990’s, early 2000’s Developed by Peter Coad, Jeff De Luca, And Stephen Palmer in the late 1990’s, early 2000’s

FDD: Key Concepts/Practices Features Features functionality having direct value to customer functionality having direct value to customer Implementable in 2 weeks or less Implementable in 2 weeks or less Domain Object Modeling Domain Object Modeling Exploration and analysis of project domain Exploration and analysis of project domain Results in a framework where features are added Results in a framework where features are added Object Oriented Design Object Oriented Design Individual Code Ownership Individual Code Ownership Unit Tests and Inspections Unit Tests and Inspections

FDD: Key Concepts/Practices Iterations by feature(s) Iterations by feature(s) 2 weeks 2 weeks Regular Builds Regular Builds Configuration Management Configuration Management Progress Reporting Progress Reporting

FDD: Process Five Phase Process Five Phase Process 1: Develop the Overall Model 1: Develop the Overall Model Mini-teams of 3 or less develop models for the entire project Mini-teams of 3 or less develop models for the entire project Teams reassemble and decide a best model Teams reassemble and decide a best model Participation of Customer paramount Participation of Customer paramount 2: Build a Features List 2: Build a Features List Break down project into 2 week implementable features Break down project into 2 week implementable features 3: Plan By Feature 3: Plan By Feature Plan features to be implemented based on dependencies, required resources, and complexity Plan features to be implemented based on dependencies, required resources, and complexity

FDD: Process 4: Design By Feature 4: Design By Feature Teams identified for one or more features Teams identified for one or more features Teams produce design for assigned features Teams produce design for assigned features Sequence Diagrams Sequence Diagrams Skeleton Classes with method signatures Skeleton Classes with method signatures 5: Build By Feature 5: Build By Feature Implement by class package for feature Implement by class package for feature Start with supporting classes Start with supporting classes Code is written, unit tested, & inspected Code is written, unit tested, & inspected Promoted to build of system Promoted to build of system

Dynamic Systems Development Method (DSDM) framework developed in the early 1990's for rapid application development (RAD) framework developed in the early 1990's for rapid application development (RAD) Driving Principle: Driving Principle: Time and Resources are fixed Time and Resources are fixed Functionality is flexible Functionality is flexible Very popular in Europe Very popular in Europe Maintained by the DSDM Consortium Maintained by the DSDM Consortium

DSDM: Key Concepts/Practices MoSCoW Prioritization MoSCoW Prioritization Must Haves  critical to success Must Haves  critical to success o Should Haves  important but not critical Should Haves  important but not critical Could Haves  nice to have Could Haves  nice to have o Won't Have  will not be implemented Won't Have  will not be implemented

DSDM: Key Concepts/Practices TimeBoxing TimeBoxing Project end date is fixed Project end date is fixed Schedule broken into fixed 2-6 week blocks of time (time box) Schedule broken into fixed 2-6 week blocks of time (time box) Assigned requirements of varying priorities Assigned requirements of varying priorities Complete highest priority within the time box Complete highest priority within the time box

DSDM: Key Concepts/Practices Prototyping Prototyping Demonstrate business process Demonstrate business process Evaluate user interaction Evaluate user interaction Determine Performance/Capability Determine Performance/Capability Demonstrate proof of concept Demonstrate proof of concept

DSDM: Lifecycle Feasibility Study Feasibility Study Is DSDM appropriate? Is DSDM appropriate? Outline Plan Outline Plan Business Study Business Study Analyze requirements Analyze requirements Recommended technical approach Recommended technical approach Plan potential prototypes Plan potential prototypes

DSDM: Lifecycle Functional Model Iteration Functional Model Iteration Build on requirements Build on requirements Prototype functionality Prototype functionality Design and Build Iteration Design and Build Iteration Prototype design Prototype design Refine prototypes into production Refine prototypes into production Implementation Implementation Transition from development to operation Transition from development to operation Provide Training Provide Training

DSDM: Lifecycle

Other Agile Processes Feature Driven Development (FDD) Feature Driven Development (FDD) Framework with features Framework with features Crystal Methodologies Crystal Methodologies Processes based on size and criticality Processes based on size and criticality Adaptive Systems Development (ASD) Adaptive Systems Development (ASD) Large, complex systems Large, complex systems

Limitations of Existing Agile Processes Limited support for large & distributed development teams Limited support for large & distributed development teams Communication breakdowns Communication breakdowns Limited support for code reusability Limited support for code reusability Project specific Project specific Limited support for large, complex software Limited support for large, complex software May require significant up front design and planning May require significant up front design and planning Incremental delivery may not be valuable Incremental delivery may not be valuable Unproven Unproven

Agile Adoption Adoption is slow but appears increasing Adoption is slow but appears increasing In March 2002, the Giga Group estimated In March 2002, the Giga Group estimated ~10% of corporate IT groups are using agile processes ~10% of corporate IT groups are using agile processes 2/3 are exploring use for future projects 2/3 are exploring use for future projects

Future of Agile Software Development Processes still evolving Processes still evolving i.e.) XP with Scrum Won’t eliminate traditional approaches Won’t eliminate traditional approaches Traditional approaches still valuable Traditional approaches still valuable Here to stay? The new standard? Here to stay? The new standard? Only time will tell… Only time will tell…

Summary: Agile Software Development Quick and Responsive development Quick and Responsive development Iterative, incremental Iterative, incremental Ample Customer Involvement Ample Customer Involvement Different Processes available Different Processes available Alternative to Traditional Methods Alternative to Traditional Methods

Questions / Comments ?