Post on 31-Jan-2018
Agile Planning, Tracking and Project ManagementBoot Camp
XP Agile Universe ConferenceCalgary, Alberta, Canada
August 15, 2004
2
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Your Instructor
Paul HodgettsFounder and CEO of Agile LogicTeam coach, trainer, consultant, developer21 years overall, 4½ years agile experienceContributing author (Extreme Programming Perspectives)
Presenter at conferences (ADC, XPAU, JavaOne)
Agile Alliance Program DirectorMember of CSUF agile advisory boardContact info: www.agilelogic.com phodgetts@agilelogic.com
3
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Why Is Agile Project Management Hot?
4
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
This Tutorial
Looks at agile development from a project manager’s perspectiveInformation useful to understanding how to do project management for an agile projectExercises to help gain a feel for some of the concepts and practices
5
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Plan
Agile Project Management ConceptsThe Agile Project CommunityThree Views of an Agile Project“Managing” the Project
6
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Agile Project Management Concepts
What Is Agility?What Benefits Are We Trying to Gain from an Agile Approach?What Makes Agile Project Management Different?The Agile Process Landscape
7
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
What Is an “Agile” Process?
According to the Merriam-Webster on-line dictionary “agile” means:
“1: marked by ready ability to move with quick easy grace;”“2: having a quick resourceful and adaptable character.”
In agile software development, “agile” tends to mean “the ability to respond to change.”
8
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Change in Projects
Changes in Requirements and PrioritiesChanges from Technology and ToolsChanges from PeopleChanges from the Inherent Complexity of Software
9
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Changes in Requirements and Priorities
Stakeholders learn from the solutionLearn what their true needs areLearn how to better communicate their needs
Business environment and conditions changeBusiness processes are re-engineered
10
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Changes from Technology and Tools
We are often learning new things on the flyActual capabilities may vary from expectationsCombinations create compatibility issuesNew versions are released
11
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Changes from People
Team composition changes over timeTeam interactions are complexIndividual behavior can be unpredictable
12
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Changes from the Inherent Complexity of Software
Network of dependencies is very largeSolutions need recursive feedback and validationDifficult to predict activities and dependencies
13
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Agile Project Management Concepts
What Is Agility?What Benefits Are We Trying to Gain from an Agile Approach?What Makes Agile Project Management Different?The Agile Process Landscape
14
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
What Are We Trying to Gain With an Agile Process?
Respond to change and leverage learningDeliver the highest business value (ROI)Decrease time-to-deliveryIncrease productivity and efficiencyProduce better quality solutionsCreate a more fulfilling development culture
15
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Agile Project Management Concepts
What Is Agility?What Benefits Are We Trying to Gain from an Agile Approach?What Makes Agile Project Management Different?The Agile Process Landscape
16
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
What’s Really Different About Managing an Agile Process?
Iterative and incrementalParallel and concurrent, not phasedPlanned around deliverables, not activitiesDynamic project balancing via scope adjustmentsHeavy emphasis on collaborationManagement by facilitation
17
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Iterative and Incremental
IterativeRepeatedly executing nested process cyclesIterations provide synchronizing pointsIterations provide feedback points
IncrementalSystem is built in progressive stagesIterations add features and refinementsEach increment is a working system
18
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Phased vs. Concurrent Activities
Phased ApproachGathers similar activity types togetherPreference towards serial completionUltimate in phased approach is waterfall
Concurrent and ParallelActivities occur opportunisticallyActivities of all types happening at same timePartial completion considered the norm
19
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
“Predictive” Planning
Creation of comprehensive activity-based plansExecution of defined activities to follow planManagement by controlling activities to conform to plan
20
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
“Agile” Planning
Creation of prioritized set of deliverablesOpportunistic execution of activities to create deliverablesManagement via feedback and adaptation
21
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The “Classic Trio” of Software Development
ResourcesTimeScopeMust be in balance for a healthy project
Time Resources
Scope
22
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Resource Variable
Staffing is usually the least effective variable to adjust.
Staffing increases have long lead times.Increased intensity has diminishing returns.Team culture requires some degree of stability.
Tools and technology can provide benefits.Effective tools provide continuing benefits.Front-end costs need to be carefully amortized.The wrong tools and technology increase friction.
23
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Time Variable
Can be the most painful variable to adjustEarly commitments are usually date-based.Target dates are often the most important objective.Within a date boundary, there’s only so much time.
24
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Scope Variable
Can be the most effective variable to adjustCan adjust scope breadth – what’s included.Can adjust scope depth – refinement.Partial scope can often generate immediate returns.It is often preferable to reach a date with partial scope completely finished, rather than complete scope partially finished.
25
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Project Balance in an Agile Process
Sustainable resource managementStable teamsSteady paceFavor high ROI tools and technology
Fixed time managementTime-boxed development cycles
Adaptive scope managementFeedback-based scope adjustments
26
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
“Heroic” vs. “Collaborative”
Heroic development emphasizes individualsActivities assigned to individualsProject results heavily dependent on individual performanceIncreases “keyhole” risks
Collaborative development emphasizes teamsTeams self-organize activities to meet goalsTeams leverage diverse skillsTeams mitigate keyhole risks
27
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Management by Facilitation
Command and Control StrategyDecisions made by central authoritiesActivities delegatedManager controls activities
Facilitation and Empowerment StrategyDecisions made by those with the most infoActivities acceptedTeam self-manages and adaptsOrganization ensures supportive environment
28
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Agile Project Management Concepts
What Is Agility?What Benefits Are We Trying to Gain from an Agile Approach?What Makes Agile Project Management Different?The Agile Process Landscape
29
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The World of Agile Processes
Extreme Programming (XP)Feature-Driven Development (FDD)DSDM (Dynamic System Development Method)
ScrumCrystal Family of Processes, e.g. Crystal ClearLean Software DevelopmentAdaptive Software Development (ASD)Others: Agile UP/RUP, Evo, Win-Win Spiral
30
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 value in the items on the right, we value the items on the left more.”
31
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Plan
Agile Project Management ConceptsThe Agile Project CommunityThree Views of an Agile Project“Managing” the Project
32
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Project Community
The “Business” or “Customer” or “Product Owner” roleThe “Developer” roleThe “Manager” roleEmphasis on a “Whole Team” approach
While each role represents certain interests and is perhaps assigned accountability for certain aspects of the project, the team as a whole maintains interest in and responsibility for the overall project.
33
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Business / Customer Role
Brings to the table:Understanding of the business and product needsSpecific definitions of features (requirements, scope)PrioritiesThe ability to accept the product
Speaks as a single voice to teamIs likely to be multiple stakeholder typesIs likely to have a multiplicity of stakeholdersStakeholders may be represented by proxies
34
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Business / Customer Role
Potential members:Product ManagersMarketing, SalesBusiness AnalystsQuality Assurance (acceptance testing)End Users, Their ManagersBusiness/System OperationsOthers when acting as a stakeholder
35
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Developer Role
Brings to the table:Ability to create and communicate solutionsCost estimations and explaining trade-offsDelivering usable functionality that meets requirements and priorities
Ideal is a group of wide-ranging generalistsLikely to consist of specialists to some degree“Generalizing specialists” preferred
36
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Developer Role
Potential members:ProgrammersArchitects and DesignersTechnical LeadsInterface Architects/UI DesignersDatabase Designers and DBAsOperations and Network Designers
37
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Manager Role
Brings to the table:Defines overall organizational goalsInterfaces with organizational entities (status)Environmental support (facilities, equipment)Cultural support (organizational values)Personnel administration (reviews, hiring, etc.)Business administration (budgets, etc.)
38
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Manager Role
Potential members:Owners, ShareholdersBoard of DirectorsExecutive ManagementProject ManagementTechnical Management, Administrative ManagementProcess (Quality and Process Engineering)
39
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Plan
Agile Project Management ConceptsThe Agile Project CommunityThree Views of an Agile Project“Managing” the Project
40
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Three Views of an Agile Project
Work ProductsCyclesTimeline of Events
41
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Work Product Structure of Agile Development
Incremental Building BlocksBusiness ObjectivesProjects and ProductsFeature SetsSagas and StoriesTechnical Work Units (Tasks)Technical Integrations
Traceability through the Deliverables
42
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Cycles of Agile Development
Project CycleRelease CycleIteration CycleTask CycleEpisode Cycle
Forward-Driving ActivitiesResolution IncreasesFeedback through the Cycles
43
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Cycles of Agile Development
Charter Preparation Release Release Release Wrap Up
Planning Iteration Iteration Iteration Delivery Retrospect
Planning Task Task Task Build & Test Retrospect
Pull Task Episode Episode Episode Story Test Retrospect
Pair Up TDD TDD TDD Integrate Retrospect
Write Test Write Code Refactor
1 to 6 months
1 week to 1 month
½ to 2 days
15 minutes to 2 hours
5 to 30 minutes
44
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Project Cycle
CharteringPreparationRelease Delivery…
45
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Chartering the Project
Elements of a CharterDefines the overall missionDefines specific, testable goals – “business stories”Defines schedule constraintsDefines available resources and limitsDefines the project community, roles and accountability
46
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Developing Product Strategies
Not a formulaic operation – requires some leg workBased on product development best practices
Market researchCompetitive analysisCustomer feedback
47
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Exercise
Congo.com is a new on-line retailer of technical books. They need to establish themselves against the other river.Write a charter for Congo’s new project.
What strategies could they use to break into the market?How can we express those as business stories?Constraints, resources, team at your discretion.
48
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Developing Feature Sets
Canonical XP is incremental and just-in-timeNeed a car… A convertible… A red one… With under 15,000 miles…We tend to ask for the highest values parts first
But some forces favor more up-front workHighest value nuggets not obviousLarger plans required for fundingContracts specify “fixed” scope
49
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Exercise
Given Congo’s charter and strategy, develop a list of candidate feature sets and features that would implement the charter and strategy.
50
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Preparing Requirements
Use best practices – use casesBut don’t over-do it
Cockburn’s lighter-weight formatConstantine’s essential use cases
Overall use cases useful for generating a shared mental modelFill in detail as incrementally as possible
51
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Use Cases vs. User Stories
A story is not a use case, a use case is not a storyA use case defines functional requirements in totalDefines breadth and depth of system behaviorAdditional non-functional requirements often neededA story defines a piece of system capability to be implementedStories as change requests – add, modify or remove capability
52
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Generating Stories from Use Cases
The overall set of use cases is the quiltThe stories are the patches that are incrementally sewn together to fill it inStory scope – what use case(s) are being asked for?Story breadth – what use case scenarios are being asked for?Story depth – what level of completion is being asked for?
53
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Example of Uses Cases and Stories
Overall set of use cases for shopping cart system:
Customer Views CatalogCustomer Adds Book to Shopping CartCustomer Checks Out OrderWarehouse Clerk Enters New Shipment ReceivedCustomer Service Rep Checks Shipping Status
54
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Example of Uses Cases and Stories
Single Use Case in More Detail:Customer Checks Out Order, Card Accepted, Card Type X
Step 1Step 2…Calculate DiscountCalculate TaxAuthorize PaymentMore Steps…
Customer Checks Out Order, Card Denied, Card Type XCustomer Checks Out Order, Card Accepted, Card Type Y
55
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Example of Uses Cases and Stories
Example of a story that maps to use case:“Implement the Customer Checkout use case. Handle only the card accepted, card type X scenario. Don’t worry about sales tax or discount calculations at this point.”
56
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Example of Uses Cases and Stories
Example of a cross-cutting story“Implement sales tax calculations. Sales tax calculations are needed in these use cases: Review Shopping Cart, User Checkout, Admin Review Order. Handle only a single fixed sales tax rate at this point – don’t worry about state tax tables.”
57
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Why Would We Go Though All This?
Good stories are the essential building blocks of release plansIncrease the value of the software
Scope the highest priority stories to the core business value
“Minimal Marketable Feature” – MMFEarly delivery of MMFs
Accelerates break-even on the projectIncreases the Net Present Value (NPV) of the project
58
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Release Cycle
Release PlanningDelivering Iterations…Release DeliveryRelease Retrospective
59
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Release Planning
Presenting StoriesEstimating StoriesEstimating VelocityStory Selection and PrioritizationCreate the Plan
60
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Presenting Stories
Stories are discussed and understood (analysis)Developers determine overall technical approach (architecture and design)
61
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Estimating Stories
For a release plan, goal is to relatively quickly sort the stories into groupings of coarser-grained sizes.We’re not trying to calculate effort to any degree of precision.
62
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Story Estimate Sizes
Story estimates are probabilitiesChoose estimate “bucket” sizes, e.g. 1, 2, 3, 5, 8Small stories implement the “small batch size” principalSmaller stories allow more of the team capacity to be usedSmaller stories have less chance of catastrophic overrunsSuggest limiting max size to one-half an iteration
63
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Estimating Stories using Relative Estimates
Choose an “average” sized storyAssign a mid-range value to itCompare each remaining story against itAssign a relative value to eachCan break team away from being too precise
64
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Estimating Stories using Ideal Days
Developers determine uninterrupted time to completeCan lead to issues due to perceived precisionWhose ideal day is it?If team systemically over- or under-estimates, ideal day estimates can turn into relative estimatesCan give the team a reference point
65
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Estimating Issues
Estimates require:Sufficient level of definitionAbility to understand technical issues
Encourage team to talk through the issuesNot enough level of definition
Table the storyHave the customer bring it back when ready
Insufficient understandingTable the storySpin off an investigative task to address (spike)
66
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Estimating Velocity
When using relative estimates, just have to guess on the first one and then employ feedbackWhen using ideal days, take number of developers X iteration length X an overhead factor (usually .4 to .8)Optionally, take number of work streams (pairs) X iteration length X a lower overhead factor
67
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Create the Plan
Story selection and prioritizationHighest value stories favoredRelease objectives and themes considered
Choose a target release dateMay be contingent on a minimal scope delivery
Arrange stories into probable iterationsBased on prioritization
68
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Sample (and Simple) Release Plan
69
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Release Re-estimation
Customer refines the product strategyBusiness needs may changeStories added or modifiedTeam learns about non-systemic over- or under-estimation, e.g. on all rules engine workTry to schedule on an iteration boundary
70
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Iteration Cycle
Iteration PlanningDelivering Tasks…Iteration DeliveryIteration Retrospective
71
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Iteration Planning
Estimating velocityPresenting StoriesTask BreakdownsTask Estimating, or NotTask Sign-Ups, or Not
72
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Estimating velocity
The first iteration uses the release planning velocitySubsequent iterations use a “yesterday’s” weather velocity
Could be exactly the same as last iterationCould be a moving average (3 or 5)Could be modified based on known factors (vacations, etc.)
Always make sure the team can commit to the velocity
73
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Presenting Stories
Stories selected may deviate from original release plan
Actual progress may be differentMay need to consider specialized resources
Stories are discussed in greater detail (analysis)Developers determine mid-level technical approach (design)
74
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Task Breakdowns
Developers create a task list for each storyTasks are technical tasksVertical slices preferred over horizontal slicesSometimes technologies and specialties drive tasks
75
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Task Estimating, or Not
Some teams also estimate tasks in ideal hoursCan provide feedback on accuracy of story estimates
76
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Task Sign-Ups, or Not
Some teams sign up for tasks at planning timeMaintains developer and estimate relationshipGo around the team, each developer signs up for a task and places their estimate on it
Others pull tasks on an as-needed basisAllows resources to more opportunistically work on tasksEstimates can be collective or at pull time
77
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Sample Iteration Plan
78
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Iteration Recovery
Iteration stability buffers the team against too much changeShort iterations enable the buffer to remain intactSometimes the set of stories for the iteration must changeGather the team for a short planning discussionIf possible, adjust the iteration plan and continueIf necessary, abort the iteration and start a new one
79
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Task Cycle
Pulling a TaskA free developer chooses next available taskConsideration for prioritiesTask-level dependencies likely
Delivering Episodes…Task Delivery
Tested and integrated
Story DeliveryStory passes customer acceptance tests
Task Retrospective
80
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Episode Cycle
Getting ReadyPair ProgrammingVerify understanding (analysis)Determine detailed technical approach (design)
Fine-Grained DevelopmentTest-Driven Development
IntegrationChanges must pass testsChanges added to the shared artifacts
Episode Retrospective
81
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Exercise
The provided table of stories represents the raw materials for release and iteration plans.Consider only priority and size. How would you arrange them to produce the “best”overall plan?Now consider feature sets. Any changes?Now consider dependencies. What changed?Now consider specializations. What changed?
82
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Timeline of Agile Development
Release EventsIteration EventsReleases and Iterations synchronized to timeDaily EventsTasks and Episodes not synchronized to time
83
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Release Events
Project chartered and approvedStories ready for release planningReady to start iterationsAll acceptance tests pass for the releaseRelease deployed to end users
84
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Iteration Events
Time box beginsReady to start task developmentSystem is built and new stories pass acceptance testsIteration time box ends
85
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Daily Events
Basic Stand-Up Protocol – Status, Plans, NeedsDynamic Daily Task PlanningTips for Running Effective Stand-Up Meetings
86
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
The Plan
Agile Project Management ConceptsThe Agile Project CommunityThree Views of an Agile Project“Managing” the Project
87
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
“Managing” the Project
Project management shifts to:Gathering informationFacilitating communicationPointing things out
Feedback and MetricsTracking and ReportingDiagnosing
88
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Feedback and Metrics
Objective feedbackData gatheredCurrent state of artifacts
Subjective feedbackRetrospective commentsWhat’s not said
89
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Some Essential Metrics
Amount of work for the release/iterationMeasured in count of story estimates
Amount of work completedMeasured in count of story estimatesMake sure the story is really complete
VelocityMeasure in story points per iteration
90
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Other Useful Metrics
Estimate accuracyComparison of actuals to estimatesCorrelations to feature type, technology, etc.
Actual cost of featuresDeveloper time to produce story points
QualityDefects found at various testing points
Progress towards business objectivesPortion of feature sets and strategies completed
91
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Other Useful Metrics
Metrics to encourage specific practicesMeasuring number of unit tests over time
Code size and qualityMeasuring number of things over timeMeasuring complexity/dependencies over time
Value stream for features sets and featuresHow long before value is realized?What happens to it along the way?
92
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Tracking
Leverage the process flow for tracking pointsCompletion of cycles, key events
Collect data in small incrementsAvoid recreating history
Use lightweight mechanismsCollect raw dataOffload compiling data from the team
Use retrospectives for subjective information
93
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Reporting
Leverage the natural project artifacts for reporting
Plans and tracking dataReformat for outside consumption if needed
Keep reports simple and directVisual reporting – charts and graphs
Make reporting accessible and unavoidableBig Visible ChartsProject Dashboard
94
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Sample Burn-Up Chart
Feature 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
95
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Diagnosing a Project
Leverage retrospectivesFocus on meaningful issues
Look for unexpected or large variancesCorrelate improvements to ability to deliver
Strive for continuous improvementTarget something, however small, each iterationKind of like refactoring the process
96
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Retrospectives
Retrospectives ask:What went well, what didn’t?What things do we want to keep doing?What things do we want to change?
Capture retrospective resultsSummarize and keep visible to the team
Create targets for actionEach retrospective, follow up on prior targets
97
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Completion Criteria
We want to ensure we are really completeAcceptance tests must passResulting artifacts meet “goodness” criteriaThe system is fully built and integrated
Partial completion produces “debt”Often hidden work that still needs to be donePayoff of principal will add stories/tasksOften debt carries interest that affects velocity
Watch for signs of debt in your project
98
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Other “Process Smells”
Chronically missed estimatesDeferred activities, not ready to move forwardArtifacts that no one consumesArtifacts that sit around too longExtras in feature implementationsInability to focus on task at handIdle people looking for work or waitingFriction, extra effort
99
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
More “Official” Things
Agile processes can be sufficiently “disciplined”and “defined”May need additional formality and ceremonyAgile cycles can be wrapped in Six SigmaAgile teams could be at least CMM level 3PMI/PMBOK does not seem agile-compatible
PMI emphasizes activity plan conformanceAgile emphasizes work state managementPMBOK adopting iterative/incremental?
100
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Retrospective
101
Copyright © 2004, Agile Logic, Inc. All Rights Reserved
Thank You for Attending!Enjoy the Conference!