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. 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