XP and Scrum

1. XP and Scrum Tools and Practices for Making Your Organization Agile Cory Foy [foyc@cornetdesign.com | cornetdesign.com]

2. Agenda • Straws are flexible…? • Adopting Agile Practices • Examining Agile Practices • Applying the Practices • Summary

3. Straws Are Flexible?

4. Straws are Flexible?

5. Straws Are Flexible?

6. Straws are Flexible?

7. Agile Manifesto • Individuals and Interactions over Processes and Tools • Working Software over Comprehensive Documentation • Customer Collaboration over Contract Negotiation • Responding to Change over Following a Plan • Craftsmanship over Crap

8. The Missing Letter Theory

9. Retrospectives • Original Definition: A ritual held at the end of a project to learn from the experience and to plan changes for the next effort • In Practice: A chance to realign the team on core beliefs • Agile Retrospectives by Diana Larsen and Esther Derby

10. Retrospectives • Check-In • Focus On / Focus Off • Timeline • Color Code Dots • Patterns and Shifts • Learning Matrix • Start/Stop/Keep • Retrospective

11. Adopting Agile • Adoption Roles • Innovator [2.5%] • Early Adopter [13.5%] • Early Majority [34%] • Late Majority [34%] • Laggards [16%]

12. Adopting Agile • Dreyfus Model of Skills Acquisition • Novice - Needs to be told exactly what to do. Very little context to base decisions off of. • Advanced beginner - Has more context for decisions, but still needs rigid guidelines to follow. • Competent - Begins to question the reasoning behind the tasks, and can see longer term consequences. • Proficient - Still relies on rules, but able to separate what is most important. • Expert - Works mainly on intuition, except in circumstances where problems occur

13. Examining Practices: Scrum • Three Roles • Product Owner, ScrumMaster, self-organizing team • Three Ceremonies • Planning Meeting, Stand-Up, Review Meeting • Three Artifacts • Product Backlog, Sprint Backlog, Burndown Chart

14. Examining Practices: XP

15. Applying Practices: Trouble Spots • Planning and Estimation • Code Quality • Heroic Releases

16. Applying Practices: Planning • 20 Hour Story • Day 1 – 3 hours • Day 2 – 3 hours • Day 3 - 1 hour • Day 4 - 2 hours • Day 5 - 0 hours • Day 6 - 5 hours • Day 7 - 3 hours • Day 8 - 2 hours • Day 9 - 1 hour

17. Applying Practices: Planning • 20 hour story • 20 hours development / 9 days • 9 hours QA / 3 days • 1 hour Integration / 1 day • 30 hours of effort • 13 days of effort • Counting weekends – 17 days

18. Applying Practices: Planning • Story Points • Measure of difficulty • Relative to other stories • Uses Powers of 2 (1,2,4,8), or Fibonacci Scale (1,2,3,5,8) • How many stories you complete in an iteration is your velocity • Team uses Yesterday’s Weather to know what to sign up for

19. Applying Practices: Planning • Defining Done • Not just Code Complete • Some level of QA testing • Some level of Business Verification • Must be integrated with the code base

20. Applying Practices: Planning

21. Applying Practices: Planning

22. Applying Practices: Planning • Iterations • Timeboxed • Fixed Scope • Consistent Length • At end of iteration, features are potentially shippable

23. Applying Practices: Planning • Planning Game • Occurs once per iteration • Team commits to what they are going to complete • Customer is involved for team to ask questions

24. Applying Practices: Planning • Planning Poker • Used to estimate stories and tasks • Each team member has a set of cards • The story is discussed • Each team member selects their card and shows it at the same time • The two extremes discuss why • Redraw as necessary

25. Applying Practices: Planning • Other Tools and Artifacts • Index Cards • Big Visible Wall • Burndown Chart • Stand-Up Meeting

26. Applying Practices: Code Quality

27. Applying Practices: Code Quality • Test-Driven Development • No Production Code written without a failing test • Red-Green-Refactor • Write a failing test • Write just enough code to make it pass • Refactor Duplication • Tools • JUnit, NUnit, xUnit.NET, MbUnit, Visual Studio, etc

28. Applying Practices: Code Quality • Test-Driven Development • Demonstration

29. Applying Practices: Code Quality • Pair Programming • Two Minds are better than one • Does *not* cut productivity in half – actually shown to increase it • Ping Pong Coding • One person writes a failing test • The other makes it pass, and writes the next failing test

30. Applying Practices: Code Quality

31. Applying Practices: Code Quality • Customer Tests • Written in language customers can understand • Functional / Integration Level Tests • Gives an example for the developers • Tools • FIT/Fitnesse • DSLs

32. Applying Practices: Code Quality • Customer Tests • Demonstration of Fitnesse

33. Applying Practices: Code Quality • Continuous Integration • “But it works on my machine!”

34. Applying Practices: Code Quality • Continuous Integration • Combination of Process and Tools • Check in frequently (at least once a day) • On each check in, the code is checked out on a clean machine and built • A set of automated tests are run (smoke tests)

35. Applying Practices: Code Quality • Continuous Integration • Nightly or weekly a full set of regression tests could be run • Problems are detected very rapidly • Tools • CruiseControl/CruiseControl.NET • Team Foundation Server • Ant/NAnt/Maven/MSBuild • One Click to Build your Software

36. Applying Practices: Code Quality • Other Tools • Onsite Customer • Stand-Ups (tricky!) • Code/Technical Debt Cards • Code Reviews

37. Applying Practices: Heroic Releases

38. Applying Practices: Heroic Releases

39. Applying Practices: Heroic Releases

40. Applying Practices: Heroic Releases • Heroic Releases are not a normal part of software development • Even if it only happens at the end • Sustainable Pace

41. Applying Practices: Heroic Releases • How do we overcome this? • Communication! • Define Done • Estimated Backlog / Velocities • Stand-Up Meetings • Involvement of Business

42. Applying Practices: Heroic Releases • Define Done • Come to a shared understanding of what it means to complete a story • Should have most everything you would need to ship the story • Potentially Shippable Feature

43. Applying Practices: Heroic Releases • Estimated Backlog / Velocities • By having a fully estimated backlog, business decisions can be made to prioritize the items on business value • By having velocity estimates, the focus shifts to delivering value • Beware of comparing the velocity of different teams – or of individuals.

44. Applying Practices: Heroic Releases • Stand-Up Meetings • Not Just Standing Up! • Purpose • Share Commitment • Communicate Daily Status, Progress and Plans • Identify Obstacles • Set Direction and Focus • Build a Team

45. Applying Practices: Heroic Releases • Stand-Up Meetings • Three Questions • Yesterday | Today | Obstacles • Fourth Question • How confident do you feel we are going to succeed? • Focus on the Backlog (or not)

46. Applying Practices: Heroic Releases • Stand-Up Meetings • When do we hold them? • Morning? (Start the Day) • Mid-Morning? (Don’t Start the Day) • Afternoon? (End the Day) • Who Should Attend? • Keeping the Energy Level Up • Stand Up, 15 Minutes, Signal the End, Take it Offline

47. Applying Practices: Heroic Releases • Stand-Up Meetings only work if you’ve overcome some team dysfunctions • Absence of Trust • Fear of Conflict • Lack of Commitment • Avoidance of Accountability • Inattention to Results

48. Applying Practices: Heroic Releases • Involvement of Business • The priorities should be decided by the business • The team works during the planning game to commit to the highest priority, most valuable items • The business has to stay involved in verifying the stories

49. Applying Practices: Other Factors • Sustainable Pace • Also called 40-hour week, Energized Work • What about overtime?

50. Applying Practices: Other Factors • Whole Team / Collective Ownership • We’re all in this together • Courage as a team