1 / 50

Scrum

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

Sophia
Download Presentation

Scrum

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related