Product Development with Scrum - Agile Logic · Product Development with Scrum XP San Diego January...

transcript

Product Development with Scrum

XP San DiegoJanuary 6, 2005

By Paul Hodgetts, Agile Logic www.AgileLogic.com

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: phodgetts@agilelogic.com

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

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

Product Plans&

Strategies

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

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

Progress Reporting – Burn-Up ChartFeature Completion

100.00

Iteration End Dates

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

Product Development with Scrum - Agile Logic · Product Development with Scrum XP San Diego January...

Documents