Working on a Scrum Team

1. Working on a Scrum Team

2. According to the 2006 report, 35 percent of software projects started in 2006 completed on time and on budget. "The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward." article Making the case for Agile – What we’ve been doing isn’t working • On time • On budget • With all planned features Success Source: Chaos Report from Standish Group (2001).

3. And what is delivered isn’t always used Percent of Software Features Used Source: The Standish Group (2002).

4. Best known Agile methodologies • Scrum • XP – Extreme Programming • DSDM – Dynamic Systems Development Method • Crystal • FDD – Feature Driven Development

5. Collaborative, whole team • Collaboration on activities • Communication-centric • Cross-functional • Co-location

6. Common shared vision and goals • Vision flows into the team • Clear focusing goals • Emphasis on delivering intent • Allow space for creative problem solving

7. Iterative and incremental • Time boxed development cycles • Process activities parallel and concurrent • Activities applied to smaller work units • Frequent delivery of completed product • New product increments built on existing working product • Product kept continually up to standards

8. Agile and adaptive control • Incremental planning practices • Heavy emphasis on feedback and visibility • Frequent adaptation towards iteration goals • Continuous reflection and improvement • Self-organizing, peer teams • Distributed, local, direct decision making

9. Emphasis on being lean • Traveling light • Deliverables developed based on concrete need • Elimination of hand-off artifacts • Removal of waste in the process • Preference towards simplicity • Emergent development tactics

10. We have come to value: Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan

11. Scrum “The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.” Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986.

12. Scrum origins • Wicked Problems, Righteous Solutions by DeGrace and Stahl, 1990. • First mention of Scrum in a software context • Jeff Sutherland • Initial Scrums at Easel Corp in 1993 • IDX and 600 people doing Scrum • Not just for trivial projects • FDA-approved, life-critical software for x-rays and MRIs • Ken Schwaber • ADM • Initial definitions of Scrum at OOPSLA 96 with Jeff Sutherland

13. Scrum has been used in… Independent Software Vendors (ISVs) Offshore development Small to medium-sized startups Internal development Fortune 100 companies Contract development

14. Characteristics • One of the agile processes • Self-organizing teams • Product progresses in a series of month-long sprints • Requirements are captured as items in a list of product backlog • No specific engineering practices prescribed • Uses generative rules to create an agile environment for delivering projects • Proven scalability

15. The waterfall process What are the problems you see with the waterfall approach? What are some ways organizations deal with them? How would you solve them?

16. Overview 24 hours Daily Scrum Meeting Backlog tasks expanded by team 2-4 weeks Sprint Backlog Potentially Shippable Product Increment Product Backlog As prioritized by Product Owner

17. Why do this? • With Scrum, you can • Remove risks early • Cancel projects earlier that aren’t going to succeed • Change priorities without penalty between sprints • Realize benefits sooner by releasing earlier • Increase the ROI of a project • Increase productivity at least 2x in the first year; much more thereafter • Only deliver what’s truly needed

18. Scrum roles ScrumMaster Product Owner The Team

19. Product delivery Deliver customer value Employ iterative feature delivery Champion technical excellence Leadership-Collaboration Build adaptive teams Simplify Encourage exploration Six guiding principles Source: Agile Project Management by Jim Highsmith.

20. Product delivery principles 1–2 • Ensure that a potentially shippable product is delivered each sprint • Keep the focus on delivering features, not completing tasks Employ iterative feature delivery • Support the product owner by working on the highest-valued features first Deliver customer value

21. Product delivery principle 3 • Products need to deliver value today and tomorrow • So we need to focus on adaptability and quality • Don’t become a champion of just the schedule Champion technical excellence

22. Championing technical excellence • You want code you’re so proud of that you hang it on your mom’s fridge • Keep the emphasis on writing code well and the speed will come When something is done well, it’s only a matter of time until it is done quickly.

23. Build adaptive teams • Teams need the mindset and skills to respond to change • In an uncertain environment, we need to explore rather than conform to a plan Encourage exploration Simplify • Do what is barely sufficient Leadership/collaboration principles

24. Additional responsibilities • Responsible for enforcing the values and practices of the process and the team • Remove impediments from the team • Remove barriers between team and others • Educate outside groups about how the team is working • Improve the lives of team members • Improve productivity in any way possible

25. Keep an eye out for problems • Most organizations release software every 6–12 months • When we compress this cycle to 2-4 weeks, it puts stress in new places • The ScrumMaster watches for these stress points

26. Scrum roles ScrumMaster Product Owner The Team

27. The product owner • Represents (or is) the user or customer for the project • One voice, even if not one person • Typically a Product Manager, someone from Marketing, or similar • Main responsibility is knowing what to build and in what sequence • Conveys expectations by participating in test planning

28. Product owner responsibilities • Establish the vision • Calls for releases • Decides when to call for an official release of a potentially shippable product increment • Can shift a release forward or backward to maximize ROI based on new knowledge • Manage the return on investment (ROI) • Establishes baseline target ROI • Measures project against this baseline • Prioritizes product backlog to maximize ROI

29. Establishing a shared vision • Teams do best when they have a “clear, elevating goal” and “unified commitment”† • It’s the product owner’s job to focus the team and find this clear, elevating goal Sources: †Teamwork by Carl Larson and Frank LaFasto and ‡Agile Project Management by Jim Highsmith.

30. A unified vision • Does everyone on your current project share a unified vision? • How can you establish a vision?

31. Scrum roles ScrumMaster Product Owner The Team

32. The Scrum team • Typically 5-10 people • Cross-functional • QA, Programmers, UI Designers, etc. • Members should be full-time • May be exceptions (e.g., Sys Admin, etc.) • Teams are self-organizing • Ideally no titles but rarely possible • Membership can change only between sprints

33. Analysis Coding Testing Teams are cross-functional • This is not a cross-functional team: Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Analysis Coding Testing Analysis Coding Testing • This is Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Analysis Analysis Analysis Coding Coding Coding Testing Testing Testing

34. Team commitment • The team picks the work they’ll do in a sprint • Which items • How many • The team commits to completing what they select • It’s a team commitment, not a set of individual commitments • Has authority to do whatever is needed to meet this commitment

35. Developing the right software • Improves return on investment • Solves problems with product owner involvement • Reduces project politics