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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Introductions
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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]
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Process Improvement
“Improving the way we do things around here.”
Not “doing a process” for its own sake
Increasing our capability to deliver software
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Most development is chaotic
Code and fix
Short term decisions
Does not scale
Increasing debtQuality, design, integration, knowledge
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Some Development is Bureaucratic
ComplexMandated activitiesHigh overheadLong release cyclesInability to keep up with business needs
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Options for Process Improvement
“Heroic” ApproachRelies heavily on individual effortDifficult to plan, results unreliableHigh risk of failureHeavy human cost
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Options for Process Improvement
“Formal” MethodologiesDetailed, bureaucratic processEngineering/construction-style planning –predictive of activitiesExpensive, time-consuming to implementLimited success, not popular with teams
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Options for Process Improvement
“Agile” MethodologiesJust enough processAdaptive rather than predictivePeople-oriented focus to the processFaster and less-costly to implement
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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.”
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
What in the World is “Scrum?”
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Scrum is all about Common Sense.
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Project Complexity
Three dimensions of complexityDomainTechnologyPeopleJust about allprojectsthese daysare complex
Simple
Complicated
Anarchy
Complex
BasicExperienced
AdvancedR & D
Technology
StableUnderstood
ChangingDiscovering
Dom
ain
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Defined, Predictive Process Control
Predict and plan expected activitiesManagement by controlling activities per planChange is minimized and managed via change control
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Empirical Process Basics
VisibilityImportant aspects must be visibleRealistic and true
InspectionFrequent inspectionAbility to assess
AdaptationMonitor for out-of-band resultsQuick adjustments
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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?
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Context of Scrum
Business cycles define overall goalsProduct cycles define product releasesContext provides vision for developmentContext not specifically part of defined Scrum
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Core of Scrum
Within an iterationTeam determines how to build the incrementDaily inspection and adaptationCreative process exploited within the core
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Roles in a Scrum Project
ScrumMasterFacilitator and coach
Product OwnerManages product vision and ROI
Development TeamRealizes the product plans
External Roles
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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”
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
External Roles
External roles have minimal direct involvementProcess issues interface via ScrumMasterProduct issues interface via Product OwnerTeam is responsible for status and demonstrations
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Idea
Product Plans&
Strategies
Feature
Feature
Feature
Feature
Feature
Feature Sets&
FeaturesProduct Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog Item
Product Backlog ItemProduct Backlog
Sprint Backlog Item (Task)
Sprint Backlog Item (Task)
Sprint Backlog Item (Task)
Sprint Backlog Item (Task)
Sprint Backlog Item (Task)
Sprint Backlog Item (Task)
Sprint Backlog Item (Task)
Sprint Backlog Item (Task)
Sprint Backlog
Project ArtifactsSource Code
DocumentationTests
Database SchemaExecutables
Etc., Etc., Etc…
Potentially ShippableIncrement
of
Product
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Artifacts of a Scrum Project
Product BacklogOwned by Product OwnerCaptures product requirementsPrioritized by business value and riskSupports coarse-grained estimating and planning
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Product Backlog
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Artifacts of a Scrum Project
Sprint BacklogOwned by Development TeamCaptures team implementation strategySupports fine-grained tracking
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Sprint Backlog
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Artifacts of a Scrum Project
Product IncrementOwned by everyone“Complete” and potentially shippable systemThe ultimate measure of progress
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Scrum Process Flow
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Product Vision
Organization identifies overall project goalsOrganization devises overall product strategy to meet goalsOrganization defines investment and resource commitments
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Scrum Process Flow
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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)
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Scrum Process Flow
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Scrum Process Flow
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Engineering Practices
Standards – design, coding, “sane subsets”Source code managementEngineering and functional testingDesign improvement – refactoringFrequent integrationAutomated builds and configuration managementCollective code stewardshipCollaborative work environment
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Scrum Process Flow
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Sprint Review
Review Sprint goals, answer questionsStakeholders polled for commentsProduct Owner, stakeholders, Development Team discuss and make Product Backlog adjustmentsNext Sprint review scheduled
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Delivering Releases
Latest completed Sprint increment usedStabilization Sprints may be neededHold reviews with key users after release
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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.
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tracking and Reporting
Current statusProgress towards releasesChanges in plans and whyIssues and actions to improveBig Visible Charts and Project Dashboards
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tracking and Reporting
Product Backlog Tracking
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tracking and Reporting
Sprint Tracking
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tracking and Reporting
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tracking and Reporting
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tool Support for Scrum
Start simple and stay that wayFind tools that work with you
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tool Support
Simple spreadsheets and documents
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tool Support
Version One (www.VersionOne.net)
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tool Support
Rally (www.RallyDev.com)
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tool Support
ScrumWorks (www.ScrumWorks.com)
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
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