Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

CAI - Agile Scrum Development Presentation

•Download as PPT, PDF•
•
D
deyoepw

The document discusses problems with traditional software development approaches and proposes an agile approach using Scrum. It outlines key principles of Scrum including short iterative development cycles, daily stand-ups, prioritized backlogs and frequent deliveries of working software. Scrum roles of Product Owner, Scrum Master and cross-functional team are defined along with common Scrum artifacts, meetings and metrics used. Challenges of adopting Scrum at an organizational level are also covered.

1 of 41
An Agile Approach to Application Development using Scrum www.compaid.com www.itmpi.org
Agenda Introductions Problems With Traditional Development Approaches Agile Development Overview Scrum
Software Projects Continue To Struggle Project Success Rates as Reported in the 2009 Standish Chaos Study: 32%   Successful  (On Time, On Budget, Fully Functional) 44%   Challenged  (Late, Over Budget, And/Or Less than Promised Functionality) 24%   Failed  (Canceled or never used) These numbers indicate a downward trend in the success rates from the previous five studies.
Traditional Development Methods Based on a manufacturing model Result in customer frustration and lack of trust Often deliver bloated products
Manufacturing-Based Methodologies Early development methodologies borrowed heavily from manufacturing, which is repetitive with clearly defined outputs. The Waterfall methodology is based on: Starting with a clear and accurate specification (prevents rework by getting things right upfront) Perfecting a design specification before building (no changes to requirements at this point) Quick testing cycle with little rework needed Between 25% and 35% of requirements change on large projects (reported by Capers Jones) Valid change requests are often rejected in order to manage costs and protect delivery dates. Get it right!
Customer Frustration and Lack of Trust Delivering software late, without all required features, and with low quality, leads to a lack of trust from our customers Forces us to work in a contractual manner, rather than a more productive collaborative manner Sign-offs on all requirements needed before design work can start Fosters a spirit of blame avoidance Delay in sign-offs can significantly add to the project schedule
Software Bloat In many projects, the software eventually delivered ends up bloated with unused features 2009 Standish Chaos Study of software projects shows: 45% of features were never used 19% of features were rarely used
In Summary… Traditional approaches have been shown to be ineffective for many software development efforts, evidenced by: Resistance to changing requirements and priorities Unreliability (late delivery, low quality, high cost) Customer frustration and lack of trust Bloated products SO WHAT CAN WE DO ???
An Agile Approach to Projects Work as one team Work in short iterations Deliver working software each iteration Focus on business priorities Inspect and adapt
Popular Agile Methods Scrum Software developed in time-boxed iterations called Sprints (e.g., 30 days) Daily 15 minute Scrum meetings – daily team measurement Working software developed in each Sprint Prioritized product backlog drives Sprints Customizable/adaptable based on project characteristics Rational Unified Process (RUP) Process developed to complement Unified Modeling Language (UML), an industry-standard software modeling method. Iterative approach for object-oriented software development Multiple successive phases, consisting of iterations in duration from 2 weeks to several months Extreme Programming (XP) Test driven development Pair programming Continuous integration of code Lightweight documentation 1-2 week iterations
Rational Unified Process An Iterative Incremental Methodology Characteristics: Software is built in iterative and incremental phases. Use case centric, architecture driven. Cons: The time to delivery of a working, production ready system can be long. Iterations not time-boxed Customer is not an integral part of the development team. Pros: Some flexibility to accommodate change Delivery of software more frequent and visible to the business Early focus on architecture
Scrum
Scrum
Scrum Overview A lightweight approach for planning and executing iterative development projects Used at product companies and IT organizations since 1990 including Microsoft, Google, Honda, and Xerox Wraps existing engineering practices Delivers working business functionality every 30 days Encourages “building quality in” rather than “testing defects out” Extremely simple but very hard Scalable Scrum feels completely different!
Scrum Terminology Product Backlog – prioritized list of desired customer features Sprint – iterative development cycle with a duration of 2-4 weeks Sprint Backlog – the list of tasks that the Scrum team commits to complete in the current Sprint. Items on the Sprint Backlog are drawn from the Product Backlog
The Scrum Process
Scrum Principles Customer lists known requirements (to a high level), then prioritizes them. Frequently deliver time-boxed increments of high-value Working software . The Customer can release the software any time they want. The Customer can add, delete or reprioritize features at any time (“embrace change”) We protect schedule commitments, despite change. Stop at any time, and still use what has been built. time All features prioritized Product Backlog Working software each iteration Release Learn from the market Source: Vision Consulting, 2006 Promised Release Date
Scrum Roles Product Owner Scrum Team ScrumMaster
Role – Product Owner Critically important, must be trained in Scrum Should be a Business representative Develops and maintains the Product Backlog Prioritizes the Product Backlog Presents and explains Product Backlog to the team Empowered to make decisions for all customers and users Attends Sprint planning meeting and Sprint review meeting
Product Backlog List of functionality, technology, issues Emergent, prioritized, estimated Product Owner responsible for priority More detail on higher priority backlog Derived from Business Plan or Vision Statement, which sometimes have to be created with customer Each Product Backlog Item must include a definition of “Done” Test conditions identified Code complete Unit and Integration Tested Accepted by Product Owner
Example Product Backlog
Role – Scrum Team Self-organizing, highly collaborative Cross-functional Ideal Team Size = Seven plus or minus two Converts selected Product Backlog items into tasks on the Sprint Backlog Responsible for committing to work defined on Sprint Backlog Authorized to do whatever is needed to meet commitment Synchronizes at the Daily Scrum Meeting
Sprint Backlog Tasks to turn product backlog into working product functionality Tasks are estimated in hours, usually 1-16 Tasks with more than 16 hours are broken down later Team members sign up for tasks, they aren’t assigned Estimated work remaining is updated daily Any team member can add, delete, or change the Sprint Backlog Work for the Sprint emerges Update work remaining as more is known, as items are worked
Example Sprint Backlog
Role – Scrum Master Coach and Advocate Responsible for managing the process Sets up and conducts meetings Representative to management Representative to team
Scrum Meetings Sprint Planning Daily Scrum Sprint Review
Sprint Planning Meeting A full-day meeting that precedes each Sprint 1 st 4 hours - team selects Product Backlog Items and sets goal with Product Owner 2 nd 4 hours - team defines Sprint Backlog to build functionality Anyone can attend, but primary conversation and work is between team and Product Owner
Daily Scrum Daily 15 minute status meeting Same place and time every day Three questions What have you done since last meeting? What will you do before next meeting? What is in your way? Impediments discussed Decisions made
Sprint Review Meeting Duration = 4 hours Maximum 1 hour preparation Demo conducted on equipment where software was developed and tested Presented by team to Product Owner and customers/users Basis for planning next Sprint Must represent potentially shippable increment of product functionality (features are “done”)
Scrum Metrics Sprint Burndown Chart Product Burndown Chart Velocity Measure Sprint Results
The Burndown Chart Displays number of task units (typically hours) remaining Overall trend is important to monitor Daily fluctuations are acceptable and expected Actual Line should eventually reach 0 hours and should roughly follow Expected Line Across Iterations, a less granular measure is used that is tied to the deliverables, e.g., Story Points
Progress During An Iteration Sprint Burndown Chart
Progress Across Iterations Product Burndown Chart
Velocity Measure Velocity (last 3 iterations) Velocity (last 8 iterations)
Sprint Results
Scrum Is No Silver Bullet Extremely simple but very hard Many organizations are not used to releasing software so frequently Each iteration involves planning, requirements analysis, design, coding, and testing Highlights existing disfunctionality and bottlenecks within the organization that were previously hidden Scaling Scrum beyond an initial pilot project requires significant change management skill
Impediments To Using Agile Ability to change organizational thinking and culture Hard to break command and control management style Management changes from telling people what to do to leading and helping everyone do their best to achieve goals People aren’t resources, and managers aren’t bosses Requires dedicated participation from customers and end users Agile puts pressure on the product development organization to improve its engineering skills The phrase “That can’t be done here” really means it will be very difficult to do so
Critical Success Factors For Agile Adoption Complete commitment to Agile from the top-down Qualifying and selecting an appropriate pilot project Non-disruptive Relatively short in duration Staffing a team with enthusiastic, talented, self-managing people Identifying and training a dedicated Product Owner from the business Specifying a clear definition of “done” for Product Backlog Items
Benefits of Agile Development Accelerated time to market Ability to accommodate changing requirements and priorities Productivity is increased Staff morale is improved Product quality is improved Product features meet customer needs Value is generated early High probability of meeting fixed-date commitments
[email_address] WWW.COMPAID.COM Contact CAI for more information
Additional Information Links http://www.scrumalliance.org http://www.controlchaos.com http://www.mountaingoatsoftware.com http://www.xprogramming.com Books Agile Project Management with Scrum by Ken Schwaber Agile Estimating and Planning by Mike Cohn Agile Software Development with Scrum by Ken Schwaber, Mike Beedle

More Related Content

CAI - Agile Scrum Development Presentation

  • 1. An Agile Approach to Application Development using Scrum www.compaid.com www.itmpi.org
  • 2. Agenda Introductions Problems With Traditional Development Approaches Agile Development Overview Scrum
  • 3. Software Projects Continue To Struggle Project Success Rates as Reported in the 2009 Standish Chaos Study: 32%   Successful  (On Time, On Budget, Fully Functional) 44%   Challenged  (Late, Over Budget, And/Or Less than Promised Functionality) 24%   Failed  (Canceled or never used) These numbers indicate a downward trend in the success rates from the previous five studies.
  • 4. Traditional Development Methods Based on a manufacturing model Result in customer frustration and lack of trust Often deliver bloated products
  • 5. Manufacturing-Based Methodologies Early development methodologies borrowed heavily from manufacturing, which is repetitive with clearly defined outputs. The Waterfall methodology is based on: Starting with a clear and accurate specification (prevents rework by getting things right upfront) Perfecting a design specification before building (no changes to requirements at this point) Quick testing cycle with little rework needed Between 25% and 35% of requirements change on large projects (reported by Capers Jones) Valid change requests are often rejected in order to manage costs and protect delivery dates. Get it right!
  • 6. Customer Frustration and Lack of Trust Delivering software late, without all required features, and with low quality, leads to a lack of trust from our customers Forces us to work in a contractual manner, rather than a more productive collaborative manner Sign-offs on all requirements needed before design work can start Fosters a spirit of blame avoidance Delay in sign-offs can significantly add to the project schedule
  • 7. Software Bloat In many projects, the software eventually delivered ends up bloated with unused features 2009 Standish Chaos Study of software projects shows: 45% of features were never used 19% of features were rarely used
  • 8. In Summary… Traditional approaches have been shown to be ineffective for many software development efforts, evidenced by: Resistance to changing requirements and priorities Unreliability (late delivery, low quality, high cost) Customer frustration and lack of trust Bloated products SO WHAT CAN WE DO ???
  • 9. An Agile Approach to Projects Work as one team Work in short iterations Deliver working software each iteration Focus on business priorities Inspect and adapt
  • 10. Popular Agile Methods Scrum Software developed in time-boxed iterations called Sprints (e.g., 30 days) Daily 15 minute Scrum meetings – daily team measurement Working software developed in each Sprint Prioritized product backlog drives Sprints Customizable/adaptable based on project characteristics Rational Unified Process (RUP) Process developed to complement Unified Modeling Language (UML), an industry-standard software modeling method. Iterative approach for object-oriented software development Multiple successive phases, consisting of iterations in duration from 2 weeks to several months Extreme Programming (XP) Test driven development Pair programming Continuous integration of code Lightweight documentation 1-2 week iterations
  • 11. Rational Unified Process An Iterative Incremental Methodology Characteristics: Software is built in iterative and incremental phases. Use case centric, architecture driven. Cons: The time to delivery of a working, production ready system can be long. Iterations not time-boxed Customer is not an integral part of the development team. Pros: Some flexibility to accommodate change Delivery of software more frequent and visible to the business Early focus on architecture
  • 12. Scrum
  • 13. Scrum
  • 14. Scrum Overview A lightweight approach for planning and executing iterative development projects Used at product companies and IT organizations since 1990 including Microsoft, Google, Honda, and Xerox Wraps existing engineering practices Delivers working business functionality every 30 days Encourages “building quality in” rather than “testing defects out” Extremely simple but very hard Scalable Scrum feels completely different!
  • 15. Scrum Terminology Product Backlog – prioritized list of desired customer features Sprint – iterative development cycle with a duration of 2-4 weeks Sprint Backlog – the list of tasks that the Scrum team commits to complete in the current Sprint. Items on the Sprint Backlog are drawn from the Product Backlog
  • 17. Scrum Principles Customer lists known requirements (to a high level), then prioritizes them. Frequently deliver time-boxed increments of high-value Working software . The Customer can release the software any time they want. The Customer can add, delete or reprioritize features at any time (“embrace change”) We protect schedule commitments, despite change. Stop at any time, and still use what has been built. time All features prioritized Product Backlog Working software each iteration Release Learn from the market Source: Vision Consulting, 2006 Promised Release Date
  • 18. Scrum Roles Product Owner Scrum Team ScrumMaster
  • 19. Role – Product Owner Critically important, must be trained in Scrum Should be a Business representative Develops and maintains the Product Backlog Prioritizes the Product Backlog Presents and explains Product Backlog to the team Empowered to make decisions for all customers and users Attends Sprint planning meeting and Sprint review meeting
  • 20. Product Backlog List of functionality, technology, issues Emergent, prioritized, estimated Product Owner responsible for priority More detail on higher priority backlog Derived from Business Plan or Vision Statement, which sometimes have to be created with customer Each Product Backlog Item must include a definition of “Done” Test conditions identified Code complete Unit and Integration Tested Accepted by Product Owner
  • 22. Role – Scrum Team Self-organizing, highly collaborative Cross-functional Ideal Team Size = Seven plus or minus two Converts selected Product Backlog items into tasks on the Sprint Backlog Responsible for committing to work defined on Sprint Backlog Authorized to do whatever is needed to meet commitment Synchronizes at the Daily Scrum Meeting
  • 23. Sprint Backlog Tasks to turn product backlog into working product functionality Tasks are estimated in hours, usually 1-16 Tasks with more than 16 hours are broken down later Team members sign up for tasks, they aren’t assigned Estimated work remaining is updated daily Any team member can add, delete, or change the Sprint Backlog Work for the Sprint emerges Update work remaining as more is known, as items are worked
  • 25. Role – Scrum Master Coach and Advocate Responsible for managing the process Sets up and conducts meetings Representative to management Representative to team
  • 26. Scrum Meetings Sprint Planning Daily Scrum Sprint Review
  • 27. Sprint Planning Meeting A full-day meeting that precedes each Sprint 1 st 4 hours - team selects Product Backlog Items and sets goal with Product Owner 2 nd 4 hours - team defines Sprint Backlog to build functionality Anyone can attend, but primary conversation and work is between team and Product Owner
  • 28. Daily Scrum Daily 15 minute status meeting Same place and time every day Three questions What have you done since last meeting? What will you do before next meeting? What is in your way? Impediments discussed Decisions made
  • 29. Sprint Review Meeting Duration = 4 hours Maximum 1 hour preparation Demo conducted on equipment where software was developed and tested Presented by team to Product Owner and customers/users Basis for planning next Sprint Must represent potentially shippable increment of product functionality (features are “done”)
  • 30. Scrum Metrics Sprint Burndown Chart Product Burndown Chart Velocity Measure Sprint Results
  • 31. The Burndown Chart Displays number of task units (typically hours) remaining Overall trend is important to monitor Daily fluctuations are acceptable and expected Actual Line should eventually reach 0 hours and should roughly follow Expected Line Across Iterations, a less granular measure is used that is tied to the deliverables, e.g., Story Points
  • 32. Progress During An Iteration Sprint Burndown Chart
  • 33. Progress Across Iterations Product Burndown Chart
  • 34. Velocity Measure Velocity (last 3 iterations) Velocity (last 8 iterations)
  • 36. Scrum Is No Silver Bullet Extremely simple but very hard Many organizations are not used to releasing software so frequently Each iteration involves planning, requirements analysis, design, coding, and testing Highlights existing disfunctionality and bottlenecks within the organization that were previously hidden Scaling Scrum beyond an initial pilot project requires significant change management skill
  • 37. Impediments To Using Agile Ability to change organizational thinking and culture Hard to break command and control management style Management changes from telling people what to do to leading and helping everyone do their best to achieve goals People aren’t resources, and managers aren’t bosses Requires dedicated participation from customers and end users Agile puts pressure on the product development organization to improve its engineering skills The phrase “That can’t be done here” really means it will be very difficult to do so
  • 38. Critical Success Factors For Agile Adoption Complete commitment to Agile from the top-down Qualifying and selecting an appropriate pilot project Non-disruptive Relatively short in duration Staffing a team with enthusiastic, talented, self-managing people Identifying and training a dedicated Product Owner from the business Specifying a clear definition of “done” for Product Backlog Items
  • 39. Benefits of Agile Development Accelerated time to market Ability to accommodate changing requirements and priorities Productivity is increased Staff morale is improved Product quality is improved Product features meet customer needs Value is generated early High probability of meeting fixed-date commitments
  • 40. [email_address] WWW.COMPAID.COM Contact CAI for more information
  • 41. Additional Information Links http://www.scrumalliance.org http://www.controlchaos.com http://www.mountaingoatsoftware.com http://www.xprogramming.com Books Agile Project Management with Scrum by Ken Schwaber Agile Estimating and Planning by Mike Cohn Agile Software Development with Scrum by Ken Schwaber, Mike Beedle

Editor's Notes

  1. “ building quality in” rather than “testing defects out” - whole team ownership of quality, no longer a Quality Police mentality mind shift from testers owning quality to having a participatory role in defining and maintaining quality QA analysts become an integral part of the team, not a separate group in an adversarial relationship with the development team
  2. 03 - SAS & Vericenter: Handout Page Green Team Session #4: SAS, Offshoring, and Team Building
  3. Customers are first asked to provide a prioritized list of features, but not to detail them in a full-blown requirements specification. Next, working closely with the customer to draw out the details of the features, the team delivers small increments of well-engineered functionality every 30 days. Te customer and the team agree to each iteration’s features according to the customers prioritization and the team’s risk analysis. At any stage, the customer may ask the team to release the working software product so that they can start using it. The customer may change their prioritized requirements list while the team continues to deliver increments of working software from the top of the list.
  4. “ building quality in” rather than “testing defects out” - whole team ownership of quality, no longer a Quality Police mentality mind shift from testers owning quality to having a participatory role in defining and maintaining quality QA analysts become an integral part of the team, not a separate group in an adversarial relationship with the development team