Agile
Project Management
Introductions
Roy Schilling
Agile Coach/Trainer
CSM, CSPO, CSP, PMI-ACP
30+ years in IT
10+ years practicing Agile
Session Approaches
Approaches to learning in this session:
Cell phones on silent
One conversation at a time
The goal is understanding vs. slide coverage
Use Backlog for future discussions
Session Objectives
Present Agile benefits
Provide a solid understanding of Agile
principles and practices
Present methods for planning, tracking
Exercise:
Distribution
2 Minutes
Agile/Lean Knowledge
1 Awareness – heard of it, read about it.
2 Limited – dabbled in it, used some of the techniques.
3 1-2 years of experience with some practices and principles.
4 3+ years of experience with some practices and principles.
5 5+ years of experience with practices and principles.
Burning Questions
10 Minutes
In Each Group
• Introduce yourselves, if you haven’t already
• Develop questions about Agile that your group would like to have answered before the end of the course
• Write each question on a post-it - 1 question per note
• Each group read their top question
Why Agile?
9% 10% 11% 14% 15% 16% 18% 23% 26% 29% 37% 39% 37% 40% 39% 35% 42% 46% 42% 48% 39% 51% 46% 38%Improve/Increase Engineering Discipline Enhance Software Maintainability/Extensibility Improve Team Morale Reduce Cost Simplify Development Process Reduce Risk Project Visibility Enhance Software Quality Better Align IT/Business Increase Productivity Manage Changing Priorities Accelerate Time to Market
Highest Importance Very Important Somewhat Important Not Important
What is Agile?
Practices
Principles
Values
“Agile is an idea supported by a set of values and
principles. Agile defines a target culture for
successful delivery of product.”
Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we
value the items on the leftmore.
Individuals and interactions
over
processes and tools
Working software
over
comprehensive documentation
Customer collaboration
over
contract negotiation
Agile Principles
1)
Satisfy the
Customer
2)
Welcome
changing requirements
3)Deliver
working software frequently
4)
Business people and developers
working together
daily
5)Build projects around
motivated
individuals
6)
Face-to-face
conversation
is the best form of communication
7)Working software
is the principle measure of progress
8)
Agile processes promote a
sustainable
pace
9)
Continuous attention
to technical excellence & good design
enhances agility
10)
Simplicity
11)
Self-organizing
teams
Methodologies
52% 14% 9% 8% 3% 3% 2%2% 2% 2% 1%1%1% Scrum Scrum/XP Hybrid Custom Hybrid Don't Know Kanban Scrumban Feature-Driven Development Extreme Programming XP Lean OtherAgile Unified Process (AgileUP) Agile Modeling
Dynamic Systems Devlelopment Method (DSDM)
Scrum in a Nutshell
Split your organization into small cross-functional
teams.
Split your work into small concrete deliverables.
Prioritize and estimate relative to other work.
Split time into short, fixed-length iterations.
Optimize and update priorities in collaboration with
your customers.
Optimize your process through retrospectives after
each iteration.
Kanban in a Nutshell
Visualize the workflow
Split the work into small pieces
Use named columns to visualize the state in the workflow
Limit Work in Progress (WIP)
Assign explicit limits to how many items may progress in each workflow state
Measure the “Lead” time
Lead Time = average time to complete one item
Optimize the workflow to make the lead time as small and predictable as possible
Which Tool is Best?
Tool
= anything you use to accomplish a task or purpose
Prescriptive or Adaptive
Waterfall (Many) RUP (120+) XP (13) Scrum (9) Kanban (3) Do Whatever (0)Fixed
Estimated
Plan Driven or Value Driven
Features Time Time Features/Value Budget Budget Plan Driven Value/Vision Driven
Traditional
Agile
We tend to build the wrong stuff
Never 45% Rarely 19% Sometimes 16% Often 13% Always 7%Prioritization
Financial Value
Return on Investment (ROI)
Net Present Value (NPV)
Internal Rate of Return (IRR)
Customer Value
MoSCoW Must Have, Should Have, Could Have, Won’t Have
Kano Analysis
Must Be, Performance, Delighter, Not Relevant
Cost of Delay / Weighted Shortest Job First
Risk-Adjusted Backlog
Expected Monetary Value (EMV) = Risk Impact ($) * Risk Probability (%)
Risk Factor (RF) = Risk Impact (Days) * Risk Probability (%)
Relative Prioritization / Ranking
Ranked Order ListRisk
High Risk
Low Value
High Risk
High Value
Low Risk
Low Value
Low Risk
High Value
Source: Agile Estimating & Planning by Mike Cohn Do last, if at all
High
Low
Minimize Risk and Realize Value
Agile delivers value incrementally while
reducing the risk of failure over time.
Resource Allocation
Build Test Define Build Test DefineMultiple projects Assigned but not many tasks yet Multiple projects,
rolled off some
Build
Test Define
Resource Optimization
Exercise:
Focus
Rules:
• Instructor will give you the rules
Materials:
• Sheet of paper and writing utensil
Team Structures
Features Features Product Backlog Features Features Features Features Middleware UI Backend Feature A UI MW BE ProductIn
te
g
ra
ti
o
n
Feature A UI MW BE Feature B Feature C Feature A UI MW BE UI MW BE Features Features Product Backlog Features Features Features Features Agile Team B Agile Team A Agile Team C Component TeamsColocated / Distributed Teams
Common Practices
Team norms
Core hours
Working agreements
Colocated
Osmotic Communication
Tacit Knowledge
Distributed
Webcams
Instant Messaging
Interactive Whiteboards
Heavier reliance on documentation
Colocate geographically
Cone of Uncertainty
Requirements Design Code Test DeployUncertainty
Cost of change increases over time
Progressive Elaboration
The process of adding more detail as information emerges
Plans
Architectural designs
Risk assessments
Requirements definitions
Acceptance criteria
Estimates
Test scenarios
Continuous Planning
Vision Roadmap Release Sprint Daily Big PictureAs necessary by Product Owner/Stakeholders
Ties Vision to Approach
Every release by Product Owner
View of Horizon
Every release by Product Owner and Team
Near-term Plan
At the start of each sprint by Team
Inspect and Adapt
Traditional Roadmap
Days 90 180 270 360 012 Month Roadmap
Project A Project B Project C EnhancementsAgile Roadmap
Days
90
180
270
360
0
Release Plans– MVP/MMF
Search
Search PayPay ShipShip
By Title By Title By Credit Card By Credit Card Via UPS Via UPS Via USPS Via USPS By Gift Card By Gift Card Via FedEx Via FedEx By Pay Pal By Pay Pal By Genre By Genre By Author By Author
Buy a Book
Buy a Book
Buy known book by credit card and ship via UPS ground
Buy known book by credit card and ship via UPS ground
Story Map
Pay Ship Search by Genre Pay by Gift Card Pay by Credit Card Ship Via USPS Search by Author Ship via FedEx Ship via UPS Pay by Pay Pal Select Shipping Options Wish List Store Account Data Modify Account Data Delete a Book Enter Payment Info C ri ti c a li ty Always Use Seldom UseRequirements
Brief, simple statement from a User perspective
Emphasize verbal rather than written communication.
Clearly defined acceptance criteria
Great for planning
Starting point for a conversation
Details will come later
As apatient,
I want access to my test results online,
so that I don’t need to call the doctor. Story ID Risk Estimate Value Who What Why
The system shallprovide access to test results online
Acceptance Criteria
Instead of replacing the conversation with an upfront,
detailed document, we allow the details to emerge
through conversations
Acceptance Criteria is the result of the conversations
that we had about the User Story
Acceptance criteria spell out what the Product Owner
expects and what a team needs to accomplish
Acceptance criteria are the story-specific part of the
definition of done
Estimates
Wideband Delphi and Planning Poker
Team-based Estimation
Consensus
Ideal Time
Relative Sizing / Story Points
Based on
Size
and
Complexity
,
not time
Triangulate with other known factors
Smaller stories
Similar stories
Larger stories
Use abstract unit of measure:
Story Points
Yesterday’s Weather
Velocity
Average number of story points completed in a sprint
Lead Time
Average time to complete one item
A good predictor of the future
is what we’ve done in the past
Managing Issues
Potential
Issue
Tooling
The Agile Application Lifecycle Management Tools:
Track all aspects of an Agile Project
Stories
Defects
Iterations
Scrum/Kanban boards
Team member capacity
Progress
Etc.
Tracking Progress - Team
Source: Henrik Kniberg
Whole team maintains task boards
Low-tech, high-touch approach
0 20 40 60 80 100 120 E ff o rt
Burnup
Total Planned Completed PlannedTracking Progress - Project
0 20 40 60 80 100 1 2 3 4 5 6 7 8 9 10 E ff o rt Date
Burndown
Tracking Investments
Track expenditures by Investment Category –
Where are we spending our money?
Gartner Value Model
Run, Grow, Transform
Geoffrey Moore
Optimize, Neutralize, Differentiate
Custom
New Market, Maintenance, Cost Savings
Definition of Ready
How do you know when you’re ready?
Story Ready:
INVEST
Acceptance Criteria
Estimated
Understood
Dependencies
Risks
Sprint/Release Ready:
Little or all research
Dependencies
Goal understood
Infrastructure
Resources
Definition of Done
How do you know when you’re done?
Story Done:
Code
Test
Integration
Documentation
Configuration
Sprint/Release Done:
User Manual
Training
Release Notes
Install Docs
Scripts
Measuring Teams
Reliability
Value
Quality
Improvement
Agile Contracts
Money for Nothing, Change for Free
Standard fixed price contract, some T&M for extra work
“Change for Free” allows change to occur for no extra cost
“Money for Nothing” allows for early termination if no value
Fixed Price Work Packages
Smaller sequential SOWs
Vendor can re-estimate subsequent packages based on new information/risks Fixed Estimated Features Time Time Features/Value Budget Budget Plan Driven Value/Vision Driven Traditional Agile
Scaling – SAFe
Keys to Agility
Small, Empowered Teams
Small, Frequent Releases
Transparency
Continuous Improvement
Eliminate Waste
Limit Work in Progress
Exercise:
Simulation
Rules:
• Each ball must be touched be each team member
• A pass must have air time
• Cannot pass to neighbor (shoulder to shoulder)
• Drop or bad pass, is considered a defect
Planning (2 minutes):
• Plan/design your process
• Give estimate
Iteration 1 (2minutes)
• Pass as many balls as possible
Retrospective (2minutes):
• Review design and plan – Improve
Iteration 2 (2minutes)
• Pass as many balls as possible
Wrap-Up
Only Agile
Email: rschilling@onlyagile.com
URL: www.onlyagile.com