Product Development with Scrum - Agile Logic · Product Development with Scrum ... Feature-Driven Development ... Source: Adapted from Agile Software Development with Scrum by Ken

Product Development with Scrum

XP San DiegoJanuary 6, 2005

By Paul Hodgetts, Agile Logic www.AgileLogic.com

Copyright © 2004, Agile Logic, Inc. All Rights Reserved

Introductions


Solutions for Delivering Your Projects:Agile Process Adoption SolutionsCoaching, Consulting, Mentoring ServicesTraining in Agile Processes, Software Development and Enterprise TechnologiesTurn-Key Software Development

Fullerton, CA, basedFounded 2001 by industry veteransContact info: www.agilelogic.com (866) 64-AGILE


Paul Hodgetts

Team coach, trainer, consultant, developerFounder and CEO of Agile Logic22 years overall, 5 years agile experienceCertified ScrumMaster TrainerInnovator in Agile business and project managementAuthor (Extreme Programming Perspectives)

Presenter at conferences (ADC, XPAU, JavaOne)

Agile Alliance Program DirectorMember of CSUF agile advisory boardContact info: [email protected]


Process Improvement

“Improving the way we do things around here.”

Not “doing a process” for its own sake

Increasing our capability to deliver software


Most development is chaotic

Code and fix

Short term decisions

Does not scale

Increasing debtQuality, design, integration, knowledge


Some Development is Bureaucratic

ComplexMandated activitiesHigh overheadLong release cyclesInability to keep up with business needs


Options for Process Improvement

“Heroic” ApproachRelies heavily on individual effortDifficult to plan, results unreliableHigh risk of failureHeavy human cost



“Formal” MethodologiesDetailed, bureaucratic processEngineering/construction-style planning –predictive of activitiesExpensive, time-consuming to implementLimited success, not popular with teams



“Agile” MethodologiesJust enough processAdaptive rather than predictivePeople-oriented focus to the processFaster and less-costly to implement


What Exactly Is an “Agile” Process?

Focus on adaptability and responsivenessBuilt around core strategies:

Iterative and Incremental Development (IID)Adaptive project managementCollaborative, “whole team” approachCommon shared vision and goals

Constructed from “best practices”:Emphasis on simplicity, lightness, communication, self-directed teams, quality and technical excellence


The World of Agile Processes

ScrumExtreme Programming (XP)Feature-Driven Development (FDD)DSDM (Dynamic System Development Method)Crystal Family of Processes, e.g. Crystal ClearLean Software DevelopmentAdaptive Software Development (ASD)Others: MSF Agile, Agile UP/RUP, Evo, Win-Win Spiral


The Agile Alliance

2001 – representatives from agile processes meet in Snowbird, Utah.Agreed on a “manifesto” of values and principles:

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

“That is, while there is value in the items on the right, we value the items on the left more.”


What in the World is “Scrum?”


Why Scrum?

Develops software in incremental stepsRequires delivery of completed softwareWorks with your instincts and expertiseFocuses combined power of teamIncorporates learning and adaptationEasy to learnFacilitates incremental adoptionScrum is low risk to implement


Scrum is all about Common Sense.


The Zen of Scrum

Scrum is simpleSmall number of practicesPractices are straightforward

Scrum is hardRequires involvement and common senseRequires constant inspection and adaptation to project realities

Scrum is subtlePractices are synergisticHigher-level benefits emerge


Scrum History

1993 – Ken Schwaber at ADM developed cycle framework1994 – Jeff Sutherland at Easel defined ScrumKen and Jeff work together to refine Scrum1996 – IDX scales Scrum to ~6001996 – Scrum published at OOPSLA2000 – XP practices used within Scrum framework2003 – ScrumMaster certifications


Scrum Projects

Scrum has been used on 1,000s of projectsTypes of applications:

Financial, FDA life-critical, government, shrink-wrap, enterprise workflow, biotech, embedded real-time, internet e-business

Some well-known organizations:Primavera, Yahoo!, PayPal, Nike


Project Complexity

Three dimensions of complexityDomainTechnologyPeopleJust about allprojectsthese daysare complex

Simple

Complicated

Anarchy

Complex

BasicExperienced

AdvancedR & D

Technology

StableUnderstood

ChangingDiscovering

Dom

ain


Defined, Predictive Process Control

Predict and plan expected activitiesManagement by controlling activities per planChange is minimized and managed via change control


Why Empirical Process Control?

Ad Hoc control works for low precision problemsDefined control can bring precision into playComplex problems are not predictable,change is commonDefined control breaks down under unpredictabilityEmpirical control manages complexity


Empirical Process Basics

VisibilityImportant aspects must be visibleRealistic and true

InspectionFrequent inspectionAbility to assess

AdaptationMonitor for out-of-band resultsQuick adjustments


Pair Dialogue – Empirical vs. Defined

Pair up with someone different, turn to each other and share short answers to the following:

What are the problems you see with the predictive, defined approach?How does your project team deal with them now?What might be a better way to solve them?


Source: Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

Product Release Cycle(1 to 3 sprints…)

Sprint Cycle(30 days)

Daily Development Cycle

Business Planning Cycle(quarterly, yearly…)

The Scrum Process Structure


The Context of Scrum

Business cycles define overall goalsProduct cycles define product releasesContext provides vision for developmentContext not specifically part of defined Scrum


The Framework of Scrum

Iterative, incremental frameworkEach iteration driven by product needsTeam selects target functionality for incrementIterations have a fixed timeboxEach iteration produces completed product incrementsTwo nested cycles – Sprint and Daily


The Core of Scrum

Within an iterationTeam determines how to build the incrementDaily inspection and adaptationCreative process exploited within the core


The “Whole Team”

Business Team

StakeholdersEnd Users

ManagementOwners/B.O.D.

Marketing/salesCustomer Support

Training

Product OwnerProduct ManagerBusiness Analyst

Development Team

ProgrammersArchitects & Designers

Technical LeadsQA / Testers

IA / UI DesignersDatabase Designers / DBAs

Technical WritersNetwork EngineersHardware Designers

ScrumMasterAdministrative

Process


The Roles in a Scrum Project

ScrumMasterFacilitator and coach

Product OwnerManages product vision and ROI

Development TeamRealizes the product plans

External Roles


ScrumMaster

Knows Scrum philosophy and practicesWorks to ensure team stays on-processFacilitates work of Product Owner and Development TeamProtects the team from impedimentsPersonal commitment to the team– the “sheepdog”


Product Owner

Represents the interests of the stakeholdersCollaborates daily with the Development TeamCommunicates product requirementsPrioritizes requirements based on business value and riskUses “sushi” technique to stage completed business valueInspects increments


Development Team

Cross-functional team builds and completes incrementsTeam estimates cost and communicates trade-offsTeam mutually commits to Sprint backlogTeam self-organizes and self-manages tasksTeam is responsible for standards and practices


External Roles

External roles have minimal direct involvementProcess issues interface via ScrumMasterProduct issues interface via Product OwnerTeam is responsible for status and demonstrations


Idea

Product Plans&

Strategies

Feature

Feature

Feature

Feature

Feature

Feature Sets&

FeaturesProduct Backlog Item

Product Backlog Item





Product Backlog ItemProduct Backlog

Sprint Backlog Item (Task)








Sprint Backlog

Project ArtifactsSource Code

DocumentationTests

Database SchemaExecutables

Etc., Etc., Etc…

Potentially ShippableIncrement

of

Product


Artifacts of a Scrum Project

Product BacklogOwned by Product OwnerCaptures product requirementsPrioritized by business value and riskSupports coarse-grained estimating and planning


Product Backlog



Sprint BacklogOwned by Development TeamCaptures team implementation strategySupports fine-grained tracking


Sprint Backlog



Product IncrementOwned by everyone“Complete” and potentially shippable systemThe ultimate measure of progress


Scrum Process Flow


Product Vision

Organization identifies overall project goalsOrganization devises overall product strategy to meet goalsOrganization defines investment and resource commitments


Scrum Process Flow


Develop Product Backlog

Product Owner plans and defines features setsProduct Owner builds feature definitionsProduct Owner identifies Product Backlog items(Development Team estimates Product Backlog)(Product Owner prioritizes Product Backlog)


Scrum Process Flow


Sprint Planning

ScrumMaster, Product Owner, Development TeamTypically about one day in durationProduct Owner arrives with prepared Product BacklogTwo parts – Select Backlog for Sprint, Sprint Backlog Planning


Select Backlog for Sprint

Typically about a half-day in durationProduct Owner and Development Team discuss Product Backlog itemsProduct Owner and Development Team choose target Backlog items for Sprint

Team agrees on “theme” for SprintProduct Owner prioritizes on importanceDevelopment Team estimates and commits


Sprint Backlog Planning

Typically about a half-day in durationDevelopment Team explores each Sprint Backlog item in more detailDevelopment Team devises strategies for building Sprint Backlog ItemsDevelopment Team builds Sprint Backlog

Tasks, task estimatesDevelopment team determines implementation planInitial task assignmentsSufficient to gain mutual commitment and start Sprint


Scrum Process Flow


Daily Scrum

First thing in the day, all team members required to attendTypically about 15 minutes in durationRound robin, each team member answers three core questions:

What did I accomplished over the past day?What will commit to working on today?What does the team need to know about?

Obstacles preventing progress?Need to collaborate with others?Important discoveries and learning?

Additional conversations arranged for after the meetingNon-team members may observe, but not participate


Sprint

Team can seek outside advice, help, information, supportNo direct advice, instructions, commentary, direction from outside the teamProduct Backlog for Sprint remains stable during SprintTeam works on and completes Backlog itemsDevelopment Team adjusts strategies and tasks as neededTeam updates Sprint Backlog tracking during the Sprint


Engineering Practices

Standards – design, coding, “sane subsets”Source code managementEngineering and functional testingDesign improvement – refactoringFrequent integrationAutomated builds and configuration managementCollective code stewardshipCollaborative work environment


What Does “Complete” Mean?

Code is written and compilesCode is unit testedCode adheres to standards, is clean and refactoredCode is checked-in and buildsBacklog item is functional testedSystem is regression testedInstallation and deployment is readyDocumentation, training is ready


Scrum Process Flow


Sprint Review

Typically about a half-day in duration, minimal preparationDevelopment Team presents completed increment to Product Owner and stakeholdersIncomplete Backlog items are not presentedSystem should be deployed on a QA server


Sprint Review

Review Sprint goals, answer questionsStakeholders polled for commentsProduct Owner, stakeholders, Development Team discuss and make Product Backlog adjustmentsNext Sprint review scheduled


Sprint Retrospective

Typically less than a half-day in durationScumMaster, Development Team, Product Owner onlyEach team member answers two questions:

What went well during the Sprint?What could be improved for the next Sprint?SAMOLO – Same As, More Of, Less Of

ScrumMaster records answers and summarizesTeam prioritizes improvement issuesTeam creates Sprint Backlog action items for next Sprint


Delivering Releases

Latest completed Sprint increment usedStabilization Sprints may be neededHold reviews with key users after release


References and ResourcesAgile Software Development with Scrum

By Ken Schwaber and Mike Beedle

Agile Project Management with ScrumBy Ken Schwaber

Ken Schwaber’s Scrum Sitewww.ControlChaos.com

Mike Cohn’s Scrum Sitewww.MountainGoatSoftware.com/scrum

Scrum Development Discussion Listgroups.yahoo.com/group/scrumdevelopment/(Lots of other great Yahoo! groups.)

The Agile Alliance Sitewww.AgileAlliance.org

Agile Logic’s Resources Sitewww.AgileLogic.com/resources.html


What’s Next?

Project Initiation PlanPresent project vision, goals, timelinesDefine Product Backlog for at least three monthsTeach Sprint planningBrainstorm about overcoming impedimentsBrainstorm about Product Backlog for next Sprint –team commitsTeam defines Sprint BacklogTeach daily Scrum, Sprint review, Sprint signature, and managementDiscuss engineering tools and practices


ScrumMaster Responsibilities

Removing the barriers between development and the customer so the customer directly drives development;Teaching the customer how to maximize ROI and meet their objectives through Scrum;Improving the lives of the development team by facilitating creativity and empowerment;Improving the productivity of the development team in any way possible; and,Improving the engineering practices and tools so each increment of functionality is potentially shippable.


Tracking and Reporting

Current statusProgress towards releasesChanges in plans and whyIssues and actions to improveBig Visible Charts and Project Dashboards



Product Backlog Tracking



Sprint Tracking



Progress Reporting – Burn-Down Chart

Progress

752 762664 619

304 264180

104200

100200300400500600700800900

5/3/20025/5/20025/7/20025/9/20025/11/2

0025/13/2

0025/15/2

0025/17/2

0025/19/2

0025/21/2

0025/23/2

0025/25/2

0025/27/2

0025/29/2

0025/31/2

002

Date

Rem

aini

ng E

ffort

in H

ours



Progress Reporting – Burn-Up ChartFeature Completion

0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

100.00

(star

t)

03/30

/04

04/06

/04

04/13

/04

04/20

/04

04/27

/04

05/04

/04

05/11

/04

05/18

/04

05/25

/04

06/01

/04

06/08

/04

06/15

/04

06/22

/04

Iteration End Dates

Feat

ure

Poin

ts

Drug TestingRelease 3xRelease 3B+Release 3AMoving Ave. VelocityAverage VelocityPlanned VelocityCompleted


Tool Support for Scrum

Start simple and stay that wayFind tools that work with you


Tool Support

Simple spreadsheets and documents


Tool Support

Version One (www.VersionOne.net)


Tool Support

Rally (www.RallyDev.com)


Tool Support

ScrumWorks (www.ScrumWorks.com)


What to Expect?

Initial progress will likely be slower than anticipatedThe process will quickly reveal constraintsTeam will take time to learn how to self-organizeYou will want to tell the team how to solve problemsYou will need encourage visibility and transparencyTeam may have difficulties focusing on daily plan


Typical “Process Smells”

Loss of rhythmToo much involvement from external rolesTeam members missing in actionPersistent unpredictability or fluctuationsScrumMaster is assigning workScrumMaster is focus of Daily ScrumUnhealthy specialization or ownership

Documents

Product Development with Scrum - Agile Logic · Product Development with Scrum ... Feature-Driven Development ... Source: Adapted from Agile Software Development with Scrum by Ken