Scrum

1. Scrum Claudio Ochoa – Patricio Maller SEG UNSL – Iridis Group

2. Scrum philosophy “During a Scrum, the pack must work as a unit, not as 8 individuals. Everybody has a role to play. The important goal to bear in mind is that when you work well together as a unit, the whole is much greater than the sum of the parts.” The On-Line Rugby Coaching Manual Iridis Group - SEG

3. Scrum Authors • Ken Schwaber: developed and formalized Scrum process for systems development. • Jeff Sutherland: initial thoughts and practices prior to formalizing Scrum with Ken. • Mike Beedle: Scrum innovator and practitioner. Wrapped XP with Scrum Iridis Group - SEG

4. Scrum life cycle Iridis Group - SEG

5. How does Scrum work? • Small teams (< 10 people) • A series of Sprints (30 days) • Visible, usable increments • Time-boxed Iridis Group - SEG

6. Scrum feels different • Less time is spent trying to plan and define tasks • Less time is spent creating and reading management reports • More time is spent with the team understanding what really is happening and empirically responding. Iridis Group - SEG

7. Why Scrum? • Assumes complicated, unpredictable environment • Does not assume repeatable process • Contains elements our successful teams were already applying Iridis Group - SEG

8. Scrum roles • Scrum master • The team. Besides these roles, the following players are identified • Upper management • Customer • Product owner Iridis Group - SEG

9. What does the Scrum Master do? • Makes immediate decisions at Scrum meetings • Records impediments and resolves ASAP • Keeps the team focused and making progress • Tracks progress Iridis Group - SEG

10. The Scrum Master • Responsible for ensuring that Scrum values, practices and rules are enacted and enforced • Nexus between management and the team • Drives daily scrums comparing progress made vs. expected. • Ensures impediment are quickly removed and decisions are promptly made. Iridis Group - SEG

11. The Scrum Master cont. • The Scrum Master works with management and customer to identify and institute a product owner. • The Scrum Master and the management form Scrum teams • The Scrum Master, the Product owner and the Scrum team create a Product backlog Iridis Group - SEG

12. The Product Backlog • “The Product Backlog is an evolving prioritized queue of business and technical functionality that needs to be developed into a system” Ken Schwaber Iridis Group - SEG

13. The Product Backlog cont. • Requirements are listed in the Product Backlog • Lists features, functions, technologies, enhancements, bug fixes, etc to be applied to the product. • PB is initially incomplete, to get the first Sprint going they need to contain enough requirements to drive a 30-day Sprint. Iridis Group - SEG

14. Backlog originates from • Product marketing • Sales • Engineering • Customer support Iridis Group - SEG

15. Backlog characteristics • It’s sorted in order of priority • It also include issues, which may require resolution before one or more backlog items can be worked on. Issues are also prioritized • Requirements never stop changing...all you need is a product vision and enough top priority items on the backlog to begin one iteration Iridis Group - SEG

16. Requirements Emergence • Initially a small set of high-priority requirements is defined • Requirements emerge as the product emerge • Compare this approach vs. up-front requirements • Customer allocates budget for the initially foreseeable Product Backlog Iridis Group - SEG

17. Product Owner • ONLY the Product Owner is responsible for managing and controlling the Product Backlog. • The product owner is ONE person, not a committee • No one is allowed to tell the team to work from a different set of priorities. • All of the decisions the Product Owner makes are highly visible, reflected in prioritization of the backlog Iridis Group - SEG

18. Estimating Backlog Effort • Initial estimation is done collaboratively by developers, writers, quality staff, etc. • Estimating is an iterative process. • If the Product Owner can not get a clear believable estimation for a top priority item, this should be redefined • The Scrum team selects the amount of Backlog it can handle in a Sprint based on these estimates. Iridis Group - SEG

19. Scrum Teams • Self-organizing and fully autonomous • A team commits to turn a selected set of Backlog into a working product(Sprint goal) • The team can do whatever is necessary to achieve its goal. • It is only constrained by organizational conventions and standards. Iridis Group - SEG

20. Team dynamics • Scrum is structured to provide teams an environment within which they can do their best • Scrum is empirical and teams can reduce functionality and still meet goals. Iridis Group - SEG

21. Team size • The size of the team should be ±7 people. • If more than 8 people are available they can broken down in multiple teams (notice that there will still be ONE backlog), and their Scrum Masters will have to coordinate their work. Iridis Group - SEG

22. Teams composition • There are no roles on teams. • Teams self-organize to turn requirements into product functionality. • Avoid people refusing to code because “it doesn’t fit their job description” • However, a team can be composed of writers, testers, and quality guys with specific tasks assigned Iridis Group - SEG

23. Working environment • Open working environments • Silence is a bad sign • Use whiteboards • Working hours are set by the team Iridis Group - SEG

24. Sprint • Fixed period of time, usually 30 days • A team is let loose for the 30-day Sprint • The scope or nature of work being done can NOT be changed • No one is allowed to add more functionality • No one can tell the team how to proceed Iridis Group - SEG

25. What happens during a Sprint? • Scrum Meetings • Each team produces a visible, usable increment • Each increment builds on prior increments • Each team member buys into assignment Iridis Group - SEG

26. Sprint Rules • Total focus on the task at hand • NO interruptions to team • NO changes allowed from the outside • New work may be uncovered in the Sprint by the development team Iridis Group - SEG

27. Sprint Planning Meeting • Consists of two consecutive meetings • Team meets with Product Owner, management and users to decide functionality to be build in next Sprint. • Teem meeting to figure out how functionality is to be built into a product increment. • Inputs to the meeting: • Product backlog, latest increment, capabilities and past performance of the team Iridis Group - SEG

28. Sprint Backlog • The team determines work to be performed to reach Sprint Goal • Product Owner often attends • Compile a list of tasks (Sprint Backlog) having enough detail to take 4-16 hours to complete. • Team modifies Sprint Backlog throughout the Sprint, adding/removing tasks. Iridis Group - SEG

29. Daily Scrum Meeting • Short (15 -30 min) status meetings, facilitated by the Scrum Master • All team members attend • One activity – the Scrum Master asks 3 questions of each attendee Iridis Group - SEG

30. Format of the Daily Scrum • What have you completed since the last Scrum meeting? • What got in your way of completing this work? • What will you do between now and the next Scrum meeting? Iridis Group - SEG

31. Benefits of Daily Scrums • Improve communications • Eliminate other meetings • Identify and remove impediments • Improves everyone’s level of project knowledge Iridis Group - SEG

32. Scrum Master responsibilities • Keep the Daily Scrum short by enforcing the rules • Ensure that room is setup for the meeting • Setup conference calls for team members working remotely • Arrange chairs so people don’t get caught up in side conversations as they move chairs around Iridis Group - SEG

33. Meeting insights • Time and location of Daily Scrums should be constant • Managers can attend Daily Scrums, however only team members are allowed to speak (pigs and chickens rule) • A Daily Scrum is NOT a design session Iridis Group - SEG

34. Handling Impediments • The Scrum Master must record and remove impediments detected in Daily Scrums • If Scrum Master does not fully understand the impediment, he should meet with the team member after the meeting. • Team must report impediments every Daily Scrum until it gets resolved Iridis Group - SEG

35. Common impediments • Examples • Required to attend other meetings o training sessions • Asked by management to do something else • Unsure of design decision • Unsure how to use technology Iridis Group - SEG

36. Follow-up meetings • Any discussion needed other than the status provided in the Daily Scrum leads to a follow-up meeting • Examples • Design discussions • Requirements interpretation discussions • Sharing of information Iridis Group - SEG

37. 4 variables • Every product development project is constrained by four variables • Time • Cost (people + resources) • Quality • Functionality Iridis Group - SEG

38. Sprint Mechanics • A Sprint fixes 3 out of the 4 variables: • Time: always 30 days • Cost: salary of team + development environment • Quality: usually an organizational standard • The team has the authority to change functionality as long as it meets the Sprint goal Iridis Group - SEG

39. Mandatory tasks • During a Sprint, the team has 2 mandatory tasks: • Daily Scrum Meetings: must be promptly attended by ALL team members • Sprint Backlog: must be kept up-to-date. Team members must adjust the estimates as they work on the Backlog Iridis Group - SEG

40. Sprint cancellation • A Sprint should be cancelled if it no longer makes sense given the circumstances • Management can cancel a Sprint if the Sprint goal becomes obsolete. • Market conditions or technological requirements may change • Because of short duration of Sprints, it rarely makes sense to cancel it. Iridis Group - SEG

41. Sprint Cancellation cont • The team can also decide to cancel a Sprint • They may realize they can not achieve the Sprint goal • They may run into a major roadblock • Sprint termination consumes resources • A new Sprint Planning meeting must be conducted Iridis Group - SEG

42. Sprint Review • 4-hour informational meeting. • Team presents the product increment built during the Sprint to • Management • Customers • Users • Product Owner Iridis Group - SEG

43. Sprint Review cont • Surprises from the Sprint are reported • ANYTHING can be changed, work can be added, eliminated, re-prioritized • New estimates and team assignments are made for the next Sprint Iridis Group - SEG

44. Benefits of Scrum • Requirements change is managed • Market input is incorporated • Customers see on-time delivery of increments, which refines requirements • Relationship with customer and marketing develops, trust builds, knowledge grows Iridis Group - SEG

45. Implementing Scrum • Scrum encapsulates existing engineering practices • Scrum Master helps the team improve their engineering practices by • Causing the team to reevaluate and discard wasteful practices • Assessing, designing and adopting new practices Iridis Group - SEG

46. Xp@Scrum Iridis Group - SEG

47. Final Thought • “Scrum is not for everyone, but it is for those who need to wrestle working systems from the complexity of emerging requirements and unstable technology” Ken Schwaber Iridis Group - SEG

48. References: Books & Articles • Agile Software Development with Scrum. Ken Schwaber & Mike Beedle Iridis Group - SEG

49. References: Web http://www.controlchaos.com/Ken Schwaber’s site http://www.Xbreed.orgMike Beedle’s site http://www.agilealliance.com/articlesAgile Alliance’s site http://www.jeffsutherland.org/scrum/index.html http://www.lindarising.org -- click on Articles Iridis Group - SEG

50. Questions? • Claudio Ochoa • cochoa@nec.com.ar • Patricio Maller • patricio.maller@motorola.com Iridis Group - SEG