Transcript Document

Scrum
• 3 Roles, 3 Ceremonies, 3 Artifacts, &
3 Best Practices
– Speaker: Dan Mezick
– Email: [email protected]
– Phone: 203-234-1404
– URL: NewTechUSA.com
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile ASAP- RoadMap
• PART1:
• Quick Overview of Scrum’s ideas
• PART2:
• Three Roles Defined
• Three Ceremonies Defined
• Three Best Practices Defined
• PART3:
• Scrum in Practice
• PART 4: Next Steps & Resources
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
PART1: Quick Overview of Agile & Scrum
• The term Agile is an umbrella
• xP, Scrum, Test Driven Development (TDD)
• Agile is Empirical and Adaptive
– “Iterative”
• Waterfall is Predictive
– Prediction is error prone; assumptions are
‘snapshots’ that can expire over time
• Agile is “planning, with ‘outs’.”
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
The Case for a New Approach
• Huge number of statistics on FAILED
PROJECTS
• Huge amounts of WASTE
• Systems are often NOT deployed to
production
• Users and software developers are polarized
• Software is almost always delivered late
• Research shows clearly that software
development IS NOT manufacturing
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile Software Development: What is It?
• The term Agile is an umbrella term
• It is xP: ExTreme programming (pairs)
• It is Scrum: A radical project management
method
• It is Test Driven Development (TDD)
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile Software Development: What is It?
• Agile is EMPIRICAL and ADAPTIVE
– Empirical: based on most recent experience
– Adaptive: responds to feedback
• Agile is ITERATIVE
– Iterative: Cuts processes and experience into
small, manageable chunks
• Agile is PLANNING– with “outs”
– A common misconception is that Agile’s lack of
prediction = “lack of planning”. This is WRONG.
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Empirical Process Overview
• Good for high-change, inherently unstable
environments
• Terminology comes from industrial
manufacturing theory
• Empirical approaches are adaptive.
– Frequent Measurement
– Dynamic (adaptive) response
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Empiricism: Planning vs. Prediction
• Empirical processes DO plan
– But empirical processes DO NOT predict
• KEY POINT: Planning is NOT prediction
– Prediction is not planning
• Prediction creates a “comforting illusion”
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Empirical Process vs. Defined Processes
• Teams have unique and complex human
chemistry
• Organizations have a unique history and
culture
• SOFTWARE IS COMPLEX. BUSINESS
SOFTWARE DEFINITIONS ARE OFTEN
VERY COMPLEX
• Complex tasks with unique 1-time objectives
are best solved empirically (adapting to
experiential feedback)
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Empirical Process vs. Defined Processes
• Empirical approach incorporates planning
but not prediction
– List all the likely tasks
– Prioritize some and define a first step
– Execute, and remain open to learning from
experience
• New tasks emerge, prioritize higher
• Others go lower in priority
– Summarize findings
• You have ability to pull plug quickly at low cost
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Defined Processes
• Defined approach incorporates planning AND
prediction
• Works for well-understood solutions
– Does not work so good for delivering software
• Assumes your product is a repeatable thing
– Example: manufacturing an automobile or part
• Same thing over and over
• You have no ability to pull plug quickly at low
cost
– “Stopping the production line” is expensive
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Defined Processes
• Defined approach incorporates planning AND
prediction
– List all the likely tasks
– Prioritize all, and define ALL of the steps, to the
Nth degree
• Define all predicted steps AND predicted detailed content
of each step
– Any experience is distorted to fit the plan
• New tasks emerge: ignore them (not part of spec)
• Others go or higher lower in priority: ignore (plan is fixed)
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Defined Processes
• Definition of length and breath of steps
becomes a goal.
• Assumes all predictions are 100% accurate
• Long delay in finding out what is working
• Huge changes in assumed environment as a function of
time.
• You have no ability to pull plug quickly at low
cost when using a Defined process such as
predictive ‘waterfall’ software development.
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Empirical vs. Defined Approach
• Defined approach pretends to define time and
cost parameters. Actually this is a prediction.
• Defined approach provides illusion that all
actors completely understand the problem.
• Defined approach provides illusion that all
actors completely understand the solution
space
• Defined approach tends to ignore new
information that is generated as the actors
focus on the work.
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Empirical vs. Defined Approach
• Empirical approach avoids prediction and
instead creates a ‘timebox’ for generating an
iteration of experience
– Using highly detailed measurement tools
• Empirical approach assumes the whole
problem cannot be understood up front
• Empirical approach assumes all actors learn
more about the solution as part of experience
• Empirical approach incorporates new
information as it becomes available
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile: Entrepreneurship Aspects
• Testing with small investment
• Probing for solutions
• Deferring irrevocable decisions till the last
responsible moment.
• Self-organizing teams
• Managing risk relative to reward at all times
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Empiricism & Adaptation: Summary
• Software development is not manufacturing
• Software development is about creating 1
and only 1 instance of the product
• Teams are unique
• Technology changes
• Businesses change (mergers, new products
etc)
• This is high-change, unstable setup that is
IDEAL for using Empirical, adaptive
approaches.
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile Development: What is It NOT?
• Agile is NOT WATERFALL
– Waterfall is Predictive
– Prediction can filter and distort reality
– Prediction is error prone
• When new information comes in, that new info
is often DISTORTED to fit the plan, rather than
adapting the plan to the new information.
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile Development: What is It NOT?
• Agile is NOT PREDICTION
– Managing to a predicted outcome has
several drawbacks
– Predicting time, money, effort works for
well-understood, repeatable and relatively
simple processes.
• Manufacturing is a defined process
• Software development is a complex process
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile Development: What is It?
•
•
•
•
Agile confronts reality and does not pretend
Agile radically redefines the Project Lead role.
Agile radically redefines the Development Team role.
Agile radically redefines the Product owner role.
– What is the #1 cause of software development project
failure?
• Agile confronts the reality of software development
– Coding business apps is easy
– Defining business apps is difficult.
• Why?
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
PART 2
Scrum’s
3 Roles,
3 Ceremonies and
3 Best Practices
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ROLES
• The actors in Scrum: Product Owner,
Scrum master, Team.
• Product Owner: Own and prioritizes the
Product Backlog
• Scrum Master: Facilitates the Scrum
process
– NOT a traditional Project Manager !!
• Team: Produces Increments of
Shippable Product Functionality
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ROLES
• The Product Owner:
– Defines and Prioritizes Features
• Owns the gathering of requirements
– Agrees to Iteration Ground Rules
• Set length of calendar time for Sprint
– (2,3,4 weeks typical)
• Does not interfere with Sprint (no scope creep)
• Can pull the plug at any time (has the power)
• Honors rules and the Scrum process during Sprints
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ROLES
• Scrum Master: A Boundary Manager
– Supports the Team
– Facilitates the Daily Scrum meeting. Asks each
developer:
•
•
•
•
What did you do yesterday?
What are you doing today?
What is in your way?
Listens and watches carefully during Scrum meeting
– Pays careful attention to non-verbal cues
– Removes Impediments in Way of Team
• Secures resources (monitors, rooms, etc)
– Communicates to Product Owner
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ROLES
• The Team:
– Participates in design
• To gain understanding of problem/solution
space
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ROLES
• The Team:
– Selects subset of prioritized Product
Backlog for Sprint commitment
• Estimates the effort
• Fills the timebox with work
• Commits to the work as a team
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ROLES
• The Team:
– Self organizes:
• Everyone commits to ALL TASKS necessary
during the Sprint
• Determines the nature of self-organization
– Teams select work for each Sprint
– Teams self-organize
– Teams have a ‘velocity’
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ROLES
• Team Velocity: How much work the
team can average per iteration, FOR
THAT TEAM
– Each time has a personality
– Each team is unique
– Teams ‘velocity’ becomes very predictable
over time
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE CEREMONIES
• Sprint Planning
• Daily Scrum
• Sprint Review (retrospective)
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE CEREMONIES
• Ceremony #1: Sprint Planning Meeting
– Product Owner reviews:
• Vision, Roadmap, Release Plan
– Team reviews:
• Estimates for each item on Backlog that is a
candidate for the Sprint
– Team pulls the work:
• From the Product Backlog onto the Sprint
Backlog
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE CEREMONIES
• Ceremony #2: The Daily Scrum
–
–
–
–
By and for the Team
Other may attend and NOT speak
Team members speak, others listen
Team stays on task with the 3 questions,
divergences are addressed offline outside of this
meeting
– Visibility, clear understanding on a day-by-ay basis
• Product owners know the score on a daily
basis
– Can pull the plug at ANY time
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE CEREMONIES
• Ceremony #3: Sprint Review Meeting
– Part 01: Product Demo
• Led by Product Owner
– Part 02: Sprint Retrospective
•
•
•
•
Led by Scrum Master
What worked?
What didn’t?
What adjustments can we make now?
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ARTIFACTS
• Artifact #1: Product Backlog
– A list of features, prioritized by business
value
– Each feature has an associated estimate,
provided by the ACTUAL team who will do
the work
– Backlog items come in from diverse
sources, including the Team
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ARTIFACTS
• Artifact #2: Sprint Backlog
– Topmost subset of the Product Backlog,
loaded onto the Sprint’s “timebox”
– Usually has more detail attached, including
planned hours and primary person
responsible to do the work during the
Sprint
– Is the list of work the Team is addressing
during the current Sprint
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ARTIFACTS
• Artifact #3: Burndown Chart
– Provides visibility into the Sprint
– Illustrates progress by the team
– Work on the Horizontal, Time on the
Vertical
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’s THREE ARTIFACTS
• Sample BurnDown Chart
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’ THREE BEST PRACTICES
• Best Practice #1: User Stories
– Plain-english requirements, written on
common 3X5 index cards
– Form: As [a type of user] I want to [perform
a specific action] such that [result]
– Example: “As a web user, I want to make a
reservation, such that I may secure my
lodging”
– Stories that are big are called EPICS
– Acceptance criteria goes on card back
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’ THREE BEST PRACTICES
• Best Practice #2: Planning Poker
– A way for the team to do estimates
– Each participant has cards numbered
1,2,3,5,8,13,21
– Values represent ‘story points’ of effort
– Players discuss feature, then throw down a
card together
– Differences are noted and discussed, then
process repeats till a concensus estimate
is formed
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’ THREE BEST PRACTICES
• Best Practice #3: Use of the Scrum
Board
– Scrum Board is a rows-and-columns
depictions of work-in-progress
– Items of work are rows, work status labels
are columns
– Work is addressed from top to bottom
– Work migrates from left to right on the
board
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’ THREE BEST PRACTICES
• Sample Use of the Scrum Board
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’ THREE BEST PRACTICES
• Sample Use of the Scrum Board
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Scrum’ THREE BEST PRACTICES
• Sample Use of the Scrum Board
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
PART 4: Applying Scrum
• Managing a Release is managing
tradeoffs in:
– Cost
– Date
– Quality
– Functionality
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile Software Development Best Practices
• Co-location of entire development team in
one lab
• Co-location or CLOSE proximity to Product
Owner
– Or delegate
• Engaged Product Owner or Delegate
– Team needs answers in 15 minutes
• Daily Scrum
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile Software Development Best Practices
• Daily build
– Implies a deep testing infrastructure
– Daily build encourages fast development
• Developers know it will be tested NOW
• Self-organizing Team
• Team involved in design stage
– Builds understanding of problem and perception of
the solution space
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Essential Web Sites
• AgileAlliance.org
– National organization of Agile leaders
• Agile2007.org (www.Agile2006.org)
– Annual conference
• controlchaos.com
– Scrum defined
• danube.com
– Scrumworks
• newtechusa.com/agile/blog
– My blog
• shmula.com/183/12-questions-with-marypoppendieck
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Mythical Man-Month By Fred Brooks
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
AgileSoftware by Schwaber & Beedle
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile Estimating by Mike Cohn
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Agile PM with Scrum by Schwaber
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Implementing Lean by Poppendieck
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
Thanks !
•
•
•
•
Speaker: Dan Mezick
Email: [email protected]
Phone: 203-234-1404
URL: NewTechUSA.com
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved