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

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

4
Scrum life cycle
5
How does Scrum work?

• Small teams (lt 10 people)
• A series of Sprints (30 days)
• Visible, usable increments
• Time-boxed

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.

7
Why Scrum?

• Assumes complicated, unpredictable environment
• Does not assume repeatable process
• Contains elements our successful teams were
  already applying

8
Scrum roles

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

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

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.

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

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

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.

14
Backlog originates from

• Product marketing
• Sales
• Engineering
• Customer support

15
Backlog characteristics

• Its 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

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

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

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.

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.

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.

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.

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 doesnt
  fit their job description
• However, a team can be composed of writers,
  testers, and quality guys with specific tasks
  assigned

23
Working environment

• Open working environments
• Silence is a bad sign
• Use whiteboards
• Working hours are set by the team

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

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

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

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

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.

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

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?

31
Benefits of Daily Scrums

• Improve communications
• Eliminate other meetings
• Identify and remove impediments
• Improves everyones level of project knowledge

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 dont get caught up in
  side conversations as they move chairs around

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

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

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

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

37
4 variables

• Every product development project is constrained
  by four variables
• Time
• Cost (people resources)
• Quality
• Functionality

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

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

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.

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

42
Sprint Review

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

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

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

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

46
Xp_at_Scrum
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

48
References Books Articles

• Agile Software Development with Scrum. Ken
  Schwaber Mike Beedle

49
References Web

• http//www.controlchaos.com/ Ken Schwabers site
• http//www.Xbreed.org Mike Beedles site
• http//www.agilealliance.com/articles Agile
  Alliances site
• http//www.jeffsutherland.org/scrum/index.html
• http//www.lindarising.org -- click on Articles

50
Questions?

• Claudio Ochoa
• cochoa_at_nec.com.ar
• Patricio Maller
• patricio.maller_at_motorola.com