Scrum: An Experiential Workshop

MJ Half‐day Tutorial 6/3/2013 8:30 AM

"Scrum: An Experiential Workshop"

Presented by:

Mitch Lacey Mitch Lacey & Associates, Inc.

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com

Mitch Lacey Mitch Lacey & Associates, Inc.

Over the past fifteen years, Mitch Lacey has managed numerous plan-driven and agile projects. At Microsoft, Mitch honed his agile skills, successfully releasing core enterprise services for Windows Live, and transitioned from program manager to Agile Coach, helping others transition to agile practices. At Ascentium Corporation he became the Agile Practice Manager, coaching customers on agile practices and adoption worldwide. As a Certified Scrum Trainer and a registered Project Management Professional, Mitch shares his experience in project and client management through Certified ScrumMaster courses, agile coaching engagements, conference presentations, and his writings, including his new book The Scrum Field Guide: Practical Advice for Your First Year.

SQE Agile West 2013 Reference Material

1Copyright 2007‐2013 Mitch Lacey ([email protected]). No reproduction without written authorization.

Understanding Scrum: An Experiential Workshop

Reference Material

Mitch LaceySQE Agile West 2013

Las Vegas

PLEASE NOTE

These slides are for REFERENCE ONLY!

We will not be using/covering the slides.




About Mitch Lacey

• Author: The Scrum Field Guide• 15+ years of project management experience• Agile 2012 Conference Chair, Dallas Texas• Former Agile Alliance Board Member• Former Scrum Alliance Board Member• Project Management Professional (PMP) • Certified Scrum Trainer (CST)


Mitch Lacey Contact Info

• Twitter: mglacey• Linked In: http://www.linkedin.com/in/mitchlacey• Email: [email protected]• Phone: +1 206 228 3544


LinkedInvcard



The Scrum Framework


The Scrum Team


Product owner

ScrumMaster

Core team (development team)



The ScrumMaster


Provides Leadership

Servant Leader

Protects the Team

Manages Social Risk

Team Facing

Roles in Scrum: ScrumMaster

• Goal: Build & Maintain a Healthy Team• Responsibilities

– Removes impediments / clears blocking issues– Protects the team from randomization– Is the team’s Scrum expert (exacts values and principles)– Defines and reports on Team productivity– Manages Daily Scrum– Coordinates Team time requests (e.g. Product Owner

meeting requests)




The Product Owner


Provides Direction

Owns the ROI

Owns the Budget

Manages Feature Risk

Customer Facing

The Product Owner

Goal: Business & Customer Advocacy and Product (or service) GuidanceResponsibilities

– Optimizes the business value of the work– Represents and Manages Stakeholder interests– Owns the Product Backlog (requirements list)– Establishes, nurtures and communicates the

product vision– Monitors the project against its ROI goals and

investment vision– Makes decisions about when to create an

official release




Committed


Develops High

Priority Features

Estimates the Work

Cross Functional

Manages Technical

Risk

Self Managing

CollectiveOwnership

Roles in Scrum: The Core Team

• Goal: Execute on the Vision and Product Backlog – Accomplishes the Sprint Goal

• Responsibilities– Self Managing / Organizing

• Makes its own commitments• Manages its own work • Manages itself to its commitments

– Develops the highest-priority features on the Product Backlog

– Cross functional




Roles in Scrum: The Team – What they Do

• Plan the work / own and update the estimates• Place value on following a plan but value

responding to change more (values)• Rely on the Product Owner for product

clarification questions (feature risk)• Authority and empowerment (does what’s

needed to achieve the goal)• Rely on the ScrumMaster to help clear

blocking issues (social risk)• Commit to the Sprint


Roles in Scrum: The Team – How Big?

• Six is ideal– As little as three and as big as eight

• Co-located• Scrum scales by adding teams, not growing

team size




Team Consultant Model


Roles in Scrum: The Team - Agreement and Support

• Teams are cross functional• Team members need to support each other• ScrumMaster drives the team to consensus• Fist of Five Technique:

– 5 = 100% support– 4 = Good idea, wish it was mine – 3 = I can live with and support this– 2 = I would like to think about this more– 1 = I am against this and will fight moving in this

direction




Ideal Team Size


Source: Putnam, Lawrence H. and Myers, Ware. Familiar Metrics Management: Small is Beautiful Once Again. IT Metrics Strategies IV:8:12‐16, Cutter Information Corp., August 1998

491 medium sized projects with 35k‐95k SLOC


Source: Putnam, Lawrence H. and Myers, Ware. Familiar Metrics Management: Small is Beautiful Once Again. IT Metrics Strategies IV:8:12‐16, Cutter Information Corp., August 1998

491 medium sized projects with 35k‐95k SLOC

“A distinct difference in the person-months needed to do a comparable amount of work begins to show up when group size exceeds eight people.”




The Product

Backlog

Levels of Planning: Being “Done” Example


Task

Examples:1. Installation

Package Updated2. > 70% Code

Coverage Story

Sprint

Prod

Examples:1. Architectural

Diagrams Updated2. Automated User

Tests PassingExamples:1. SQL Optimization

and Tuning2. Data Security

Roles Updated

Examples:1. Stress Testing2. User Training

Completed

Examples:1. Failover Testing2. Release Readiness

Review




Definition of Done Exercise

Build your own definition of done!1 – in the book2 – on this webpage:http://www.mitchlacey.com/intro-to-agile/scrum/definition-of-done




Product Backlog: What is it?

• Ordered, prioritized list of features and work• High level estimates (story points)

– Preferred: Story points: 1,2,3,5,8,13– Alternatives

• Exponential: 10, 20, 40, 80• T-shirt sizing: XS, S, M ,L, XL

• Items added at any time• Owned and prioritized by the Product Owner• Should reflect the vision (why the project exists and its

desire end state)


Product Backlog Prioritization


11

22

33

44

Up Next – more detail

Too far out – little detail

Highest PriorityWork on it now – lots of detail

Work that is 3‐5 sprints out – Some detail



User Stories

• As a <user> I can/want <action> so that <result>

• As an administrator, I can look up this month’s patient report and am able to see who is over the user defined threshold

• Have business value• Are easily identifiable by the Product Owner, customers

and the team• Rely on the 3 C’s

– Card– Conversation– Confirmation


INVEST in Your Product Backlog

• Independent– Dependencies lead to problems estimating and prioritizing– Can ideally select one item to work on without pulling in 18 others

• Negotiable– Product backlog items are not contracts– Leave or imply some flexibility

• Valuable– To users or customers, usually not to developers– Try rewriting developer-oriented backlog items to reflect value to users or

customers• Estimable

– Because plans are based on user stories, we need to be able to estimate them

• Small– Complex backlog items are intrinsically large– Compound backlog items are multiple items in one

• Testable– Make backlog items testable by having acceptance tests


1 Bill Wake 2003



Make it DEEP

• Detailed Appropriately.– Stories coming up should be understood– Stories that will not be developed for awhile should be described

with less detail

• Estimated.– More precise at the top– Less at the bottom

• Emergent.– Stories grow and change. The more you learn, the more you

tweak

• Prioritized.– Valuable stories at the top, less so down the list


Product Backlog Grooming

• The team should spend 5%-15% of Sprint time (1-6h) in reviewing the Product Backlog and estimating it for each Sprint (s)

• Similar to a specification only never out of date• Continuously prioritized and updated• Anyone can add to the product backlog





Planning

Levels of Planning




Levels of Planning: Being “Done”

• What is Done?– How do you know when your project is done?– How do your customers and stakeholders know?– How do you communicate it?


Levels of Planning: Sprint Planning Meeting 1

• Scale duration depending on Sprint Duration– 1mo Sprint = 4h– 2w Sprint = 2h

• Defines what the team will build• Product Owner states what the

business wants (high value, high risk)

• Agrees on the goal of the sprint• When Team has enough

information, or time has ended, Planning Meeting 2 begins


Vision

Product(s)

Releases

Sprint

Day



Levels of Planning: Sprint Planning Meeting 2

• Scale duration depending on Sprint Duration– 1mo Sprint = 4h– 2w Sprint = 2h

• Defines how the team will build the stories

• Tasks are small (2-14h)• Team owns Sprint Backlog

(builds, estimates, updates)• Team signs up for work,

collectively commits to the work• Attended by the Team (Product

Owner optional)SQE Agile West 2013 Reference Material

Vision

Product(s)

Releases

Sprint

Day

Sample Sprint Backlog




The Sprint Backlog

• Is the output of the planning meeting• Is used for the team to manage themselves and their

work during the sprint• Creates transparency between all Scrum team members


Download my Sprint Excel Sheet


http://www.mitchlacey.com/resources/sprint‐excel‐templates



Levels of Planning: Daily Scrum Meeting

• Occurs Daily• Team members answer three questions:

• What did you work on since the last meeting?• What will you work on today?• What impediments / blocking issues do you have?• (optional) What is your confidence that we will achieve the sprint goal?

• Timeboxed to 15m• Same time/place daily• No deep dive problem solving

(deal with that after)


The Sprint: Reporting Progress - Burndown




The Sprint: Reporting Progress - Burndown


Release Burndowns

• Use the same sprint burndown but instead of days, use it for sprints

• Should be updated after every sprint• Useful to allow the Product Owner to see the overall

release plan progress




Sprint Review Meeting

• Occurs on the last day of the Sprint• Allows stakeholders to review the work done and provide

guidance on what to do next• One hour per week of sprint (e.g. two week sprint is two

hour meeting)• The team drives the meeting• Everyone attends• Can impact the upcoming Sprint planning sessions

– Reprioritize the backlog– Change high level estimates of work– Team composition may change


What do we Review in the Review Meeting?

• Review the Sprint Goal• Review the commitments made by the team• Review work accomplished• Review the work that was not accomplished• Review the decision made• Demo the work• Summarize• Asks




Retrospective

• Occurs on the last day of the Sprint• One hour per week of sprint (e.g. two week sprint is two

hour meeting)• Allows the team to inspect itself to learn about & change

behavior as needed• Facilitated by ScrumMaster• ScrumMaster and the Team prioritize the improvements• The sprint ends when the timebox expires,

typically after the retrospective


Getting Started with Scrum

• Get a senior Sponsor in the company• Get a champion to drive the effort• Agree on who will play the roles• Set a date to “start scrumming” and prep the team to that

date• Build a prioritized Product Backlog and estimate it• Build the team and clear blocking issues (like not being co-

located)• Build a Sprint Backlog and start working• Use Burndowns• Conduct a demo and review• Inspect and Adapt• Repeat!




Cadence

• Set a cadence and keep it• Put all meetings in calendars on day 1• Keep your daily Scrum on track• Use planning• Work to potentially shippable code• Always demo at the end

• CELEBRATE SUCCESS AT EVERY SPRINT!


Getting People on Board with Scrum

• Be patient• Use the local network – get testimonials• Provide articles and books• Show incremental benefits• Get external speakers to talk to

management and teams• Ensure risk will not be penalized




Be Warned

• Most projects deliver every 6-18 months.• Scrum reduces this through inspect and adapt• Things will be stressful• Fight the urge to be lazy• Stay disciplined


What Causes Scrum to Fail?

• Making changes out of the gate• Thinking that “this can’t work in our company”• Not having an honest retrospective and doing

something about it• Bad ScrumMasters• Falling into old habits• Lacking authority and being empowered• Business culture does not support Scrum




Scrum Resources• My contact

– http://www.mitchlacey.com– http://twitter.com/mglacey

• My book, The Scrum Field Guide• Jeff Sutherland Scrum Papers

– The Scrum Papers (jeffsutherland.com/scrum/ScrumPapers.pdf)

• Mike Cohn & Mountain Goat Software– http://www.mountaingoatsoftware.com/scrum

• Scrum Alliance– http://www.scrumalliance.org


Offshoring – Making it Work

• About 3 time zones away seems to work• Phone/shared desktop pair-programming is essential

– Set management expectations that pairs will be based on work, not proximity

• Use technology!– Push to talk cell phones so every team member can talk anywhere any time– Use teleconferencing for all “formal” meetings like standups– Use VNC– Get webcams

• Face time matters, travel often.• Travel any time there are communication difficulties• Travel any time you feel trust is breaking down between the

locations• Do absolutely anything you can do to build a one-team culture• Do absolutely nothing to build the perception fragmented teams




Offshoring – Making it Work Part 2

• Have a project / team coordinator– The coordinator has the responsibility of relaying the backlog to

the offshore team and tracking progress.

• Have in-person kick-off meetings with the entire worldwide team

• Bring offshore people to the central office on a rotational basis to build team cohesion

• Have offshore teams take on as much independent work as possible, a whole feature set possibly


Offshoring – Impediments to Manage

• Time zone differences• Culture and values• Inexperienced teams• Face-to-face communication• Language barriers• Trust• Building a common development environment and

codebase• Stronger Command & Control tradition in Asia• Offshore turn-over• Recruiting the right offshore workers




When to Offshore

• Don’t Offshore:– First releases of complex and high-technology-risk projects– If your onshore development process is not in place (”CMMI

level 3”)• Process = the daily work in the teams• Process ≠ the corporate process guidelines

• Don’t Agile Offshore:– If you don’t have any onshore Agile experiences


Scrum: An Experiential Workshop

Technology

Transcript of Scrum: An Experiential Workshop