Your SlideShare is downloading. ×
CAI - Agile Scrum Development Presentation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

CAI - Agile Scrum Development Presentation

1,366
views

Published on


0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,366
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • “ 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
  • 03 - SAS & Vericenter: Handout Page Green Team Session #4: SAS, Offshoring, and Team Building
  • 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.
  • “ 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
  • Transcript

    • 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
    • 16. The Scrum Process
    • 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
    • 21. Example Product Backlog
    • 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
    • 24. Example Sprint Backlog
    • 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)
    • 35. Sprint Results
    • 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