Http:// © Copyright 2002: All rights reserved Scrum 3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best...

http://www.NewTechUSA.com© Copyright 2002: All rights reserved

Scrum

• 3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best Practices3 Best Practices– Speaker: Speaker: Dan Mezick– Email: Email: [email protected]– Phone:Phone: 203-234-1404 203-234-1404– URL:URL: NewTechUSA.com


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


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 Agile’s 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

Scrum’s

3 Roles,

3 Ceremonies and

3 Best Practices


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



• 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



• 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



• The Team:– Participates in design

• To gain understanding of problem/solution space



• 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



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



• 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


Scrum’s THREE CEREMONIES

• Sprint Planning

• Daily Scrum

• Sprint Review (retrospective)



• 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



• 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



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


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



• 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



• Artifact #3: Burndown Chart– Provides visibility into the Sprint– Illustrates progress by the team– Work on the Horizontal, Time on the

Vertical



• 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



• 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



• 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



• 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-mary-poppendieck

http://www.agile2006.org/


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: Speaker: Dan Mezick

• Email: Email: [email protected]

• Phone:Phone: 203-234-1404 203-234-1404

• URL:URL: NewTechUSA.com

Http:// © Copyright 2002: All rights reserved Scrum 3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best...

Documents

Transcript of Http:// © Copyright 2002: All rights reserved Scrum 3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best...