3 Roles, 3 Ceremonies, 3 Artifacts, &: 3 Best Practices

Scrum
3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best Practices

Speaker: Dan Mezick Email: info@newtechusa.com Phone: 203-234-1404 URL: NewTechUSA.com
Copyright 2002: All rights reserved
http://www.NewTechUSA.com
Agile ASAP- RoadMap PART1:

Quick Overview of Scrums ideas
PART2:
Three Roles Defined Three Ceremonies Defined Three Best Practices Defined
PART3:
Scrum in Practice
PART 4: Next Steps & Resources

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.
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
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)
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 Agiles lack of prediction = lack of planning. This is WRONG.
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
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
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)
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
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
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)
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.
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.
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
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
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.
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.
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
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?
PART 2
Scrums 3 Roles, 3 Ceremonies and 3 Best Practices
Scrums 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

Scrums 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
Scrums 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

Scrums THREE ROLES
The Team:
Participates in design
To gain understanding of problem/solution space
Scrums 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
Scrums 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
Scrums 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
Scrums THREE CEREMONIES Sprint Planning Daily Scrum Sprint Review (retrospective)
Scrums 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
Scrums 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
Scrums 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 didnt? What adjustments can we make now?
Scrums 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
Scrums THREE ARTIFACTS Artifact #2: Sprint Backlog

Topmost subset of the Product Backlog, loaded onto the Sprints 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
Scrums THREE ARTIFACTS Artifact #3: Burndown Chart

Provides visibility into the Sprint Illustrates progress by the team Work on the Horizontal, Time on the Vertical
Scrums THREE ARTIFACTS Sample BurnDown Chart
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
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
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
Scrum THREE BEST PRACTICES Sample Use of the Scrum Board
PART 4: Applying Scrum Managing a Release is managing tradeoffs in:

Cost Date Quality Functionality
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
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
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
Mythical Man-Month By Fred Brooks
AgileSoftware by Schwaber & Beedle
Agile Estimating by Mike Cohn
Agile PM with Scrum by Schwaber
Implementing Lean by Poppendieck
Thanks !
Speaker: Dan Mezick Email: info@newtechusa.com Phone: 203-234-1404 URL: NewTechUSA.com

3 Roles, 3 Ceremonies, 3 Artifacts, &: 3 Best Practices

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3 Roles, 3 Ceremonies, 3 Artifacts, &: 3 Best Practices

Uploaded by

Copyright:

Available Formats

Scrum

3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best Practices

Copyright 2002: All rights reserved

Agile ASAP- RoadMap PART1:

PART 4: Next Steps & Resources

Agile is planning, with outs.

Copyright 2002: All rights reserved

Copyright 2002: All rights reserved

Copyright 2002: All rights reserved

Agile Software Development: What is It? Agile is EMPIRICAL and ADAPTIVE

Agile is PLANNING with outs

Copyright 2002: All rights reserved

Copyright 2002: All rights reserved

Empiricism: Planning vs. Prediction

Empirical processes DO plan

KEY POINT: Planning is NOT prediction

Copyright 2002: All rights reserved

Copyright 2002: All rights reserved

Copyright 2002: All rights reserved

Assumes your product is a repeatable thing

You have no ability to pull plug quickly at low cost

Copyright 2002: All rights reserved

Defined Processes Defined approach incorporates planning AND prediction

Any experience is distorted to fit the plan

Copyright 2002: All rights reserved

Defined Processes Definition of length and breath of steps becomes a goal.

Copyright 2002: All rights reserved

Copyright 2002: All rights reserved

Copyright 2002: All rights reserved

Copyright 2002: All rights reserved

Agile Development: What is It NOT?

Agile is NOT WATERFALL

Copyright 2002: All rights reserved

Agile Development: What is It NOT?

Agile is NOT PREDICTION

Copyright 2002: All rights reserved

Agile Development: What is It?

Agile confronts the reality of software development

Copyright 2002: All rights reserved

Scrums 3 Roles, 3 Ceremonies and 3 Best Practices

Copyright 2002: All rights reserved

Scrums THREE ROLES

Team: Produces Increments of Shippable Product Functionality

Scrums THREE ROLES The Product Owner:

Agrees to Iteration Ground Rules

Copyright 2002: All rights reserved

Scrums THREE ROLES Scrum Master: A Boundary Manager

Removes Impediments in Way of Team

Communicates to Product Owner

Copyright 2002: All rights reserved

Scrums THREE ROLES

Copyright 2002: All rights reserved

Scrums THREE ROLES

Copyright 2002: All rights reserved

Scrums THREE ROLES

Copyright 2002: All rights reserved

Scrums THREE ROLES

Copyright 2002: All rights reserved

Copyright 2002: All rights reserved

Scrums THREE CEREMONIES Ceremony #1: Sprint Planning Meeting

Team pulls the work:

Copyright 2002: All rights reserved