Agile Project Management
-
date post
20-Sep-2014 -
Category
Business
-
view
6 -
download
0
description
Transcript of Agile Project Management
Desktop Technology Program 1
Agile Project Management
Frank MaurerUniversity of CalgaryComputer Science
e-Business Engineering [email protected]
http://ebe.cpsc.ucalgary.ca/Frank.Maurer/
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 2
Project Management?
• What is it?
• Why do we need it?
• What is important?
• Best experience?
• Worst experience?
Desktop Technology Program 2
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 3
Why estimate effort?
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 4
Desktop Technology Program 3
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 5
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 6
Common Management Issues
• Building teams
• Risk management
• Project planning
• Team coordination
• Progress tracking
• Quality assurance
Desktop Technology Program 4
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 7
Team Formation: Tayloristic Way
• role-based (functional, horizontal)
• follow detailed plans of entire software development
lifecycle
• the focus is not on individuals but on the process itself!
• teams are tailored to repeatable, manufacturing-like
process
• tend to lead to isolated islands of knowledge
• what is to be done
• how it is to be done
• the exact time allowed for doing it
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 8
Team Formation: Agile Way
• cross-functional teams (vertical)
• require less knowledge transfer (because there
is no intermediates who may loose/alter
knowledge)
• facilitate better knowledge transfer (informally)
• rotations from one role to another are common
• highly specialized experts can be shared among
several teams
Desktop Technology Program 5
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 9
Empowerment
• Self-determination
• Motivation
• Leadership
• Expertise
• Amplify learning by
feedback and frequent
synchronization
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 10
Risk Management
• Risk identification
– E.g. unknown technologies, tools
• Risk quantification
• Risk resolution
– Reserve time for
overcoming troubles
– Define tasks that reduce
risks
• Contingency planhttp://www.pru.uts.edu.au/images/risk_management_benefits.gif
Desktop Technology Program 6
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 11
Typical Risks
• Changing scope
• Technology is immature or unknown to
developers
• Wrong effort estimates
• Low quality
• …
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 12
Desktop Technology Program 7
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 13
Four Project Variables
• Cost
– CHAOS Reports, Standish Group, 1994-2002
• Scope
– Feature creep
– Requirements churn
• Time
– “Adding people to a late project just makes it later”
Brooks, Mythical Man Month
• Quality
– Disasters and software bugs
http://www.mtholyoke.edu/~rzdalea/cs100/software_disasters/sd.htm
http://www.csl.sri.com/users/neumann/illustrative.html
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 14
Software Project Overruns
• Kjetil Moløkken-Østvold, Kristian Marius Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, Proc Agile 2007, IEEE:– About 70-80% of all projects encounter effort (cost) overruns
– The average magnitude of effort overruns is 30-40%
– Similar results for schedule overruns
– No apparent change the past 30-40 years
• Moløkken-Østvold and Jørgensen, "A Comparison of Software Project Overruns“, IEEE Transactions on Software Engineering, 2004:– Effort overruns based on development process
• Projects using sequential processes: Median= 60% (Mean=55%)
• Projects using flexible processes: Median=1% (Mean=24%)
• Interviews found that flexible development processes fostered good collaboration with the customer
Desktop Technology Program 8
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 15
Project Management
• Project management =
planning, organizing, controlling of tasks &
resources to accomplish a defined objective
• What, who, when, how much (i.e. costs)
• Command and control
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 16
Project Management Tasks
• Planning the project– Define tasks, task dependencies and milestones
• Estimate effort
– How long will it take to do something
• Scheduling the tasks
– Define start and finish dates
• Assign tasks– Who will work on it
– Resource leveling
– Myth: “if we fall behind the schedule, we can always add more programmers and catch up later in the project”
• Tracking progress – Conducting periodic project status meetings
– Determine whether formal project milestones have been accomplished
– Compare planned and actual end dates
Desktop Technology Program 9
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 17
Gantt Chart
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 18
Managers and Leaders
• Managers: command and control
– Define and assign tasks
– Gather status reports and track progress
• Leaders: convince and steer
– Help team to plan project
– Coach team members
– Remove obstacles
Desktop Technology Program 10
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 19
Agile Management Strategy
• Team members accept responsibility
– Tasks are not assigned but team members sign up for
them
• Committed to do quality work
• Not much management overhead
• Coaching & mentoring (software apprentice)
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 20
Four Values
• Communication
– “problems with projects can invariably be traced to somebody not
talking to somebody else about something important” XP p. 29
• Simplicity
– “what is the simplest thing that could possibly work?”
– YAGNI – you ain‟t gone need it
• Feedback
– Put system in production ASAP
– “Have you written a test case for that yet?”
• Courage
– Hill climbing (simple, complex, simpler,..)
– Big jumps take courage
Desktop Technology Program 11
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 21
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 22
Project Vision
• Vision =Statement of what the business will look like once the new system is implemented.
• Used to establish a project budget
• Established by product owner– Provides/finds funding for projects
• Vision includes– Anticipated benefits for business
– Assessment criteria for management to evaluate progress and conformance to vision Management oversight needed
Desktop Technology Program 12
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 23
Product Owner
• Defines project vision big picture
• Provides/finds funding for projects
• Checks ROI
• Prioritizes backlog
• One person – must represent all stakeholders
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 24
DSDM Process
Feasibility
Functional Model
Review Prototype
Identify
Functional
Prototype
Agree schedule
Create
Functional
Prototype
Implementation
User approval and
user guidelines
Train
users
Implement
Review
business
Design and Build
Iteration
Create
Design Prototype
Review
Design
Prototype
Identify
Design prototype
Agree
Schedule
Feasibility
Review Prototype
Identify
Functional
Prototype
Agree schedule
Create
Functional
Prototype
User approval and
user guidelines
Train
users
Implement
Review
busines
s
Create
Design Prototype
Review
Design
Prototype
Identify
Design prototype
Agree
ScheduleDesign and Build
Iteration
Functional Model Implementation
Desktop Technology Program 13
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 25
Return on Investment (ROI)
• Payback time
• Net present value, internal rate of return SE Economics
• Monetary versus non-monetary payback
Software by Numbers, p. 16
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 26
A Matter of Trust: Business Contracts
• Fixed scope/fixed price contracts– Trust by contract
– Attempts to move technical risk to development side
– Contract requires documentation imposes process
– Opposing sides of table
• How are fixed prices derived by development organization?
• Time and expenses contracts: Fixed budget/variable scope/early termination– Trust by feedback and involvement
– Collaborative environment
– Changes easy
– Issues: • No time limit on project
• No guaranteed functionality
Honest effort estimate
Risk multiplier
(Insurance premium)
How urgently do
I need the contract?
Cost of
change requests
Desktop Technology Program 14
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 27
The Relationship between Customer Collaboration and
Software Project Overruns
• Good collaboration is subjective, and not precisely defined
• This paper (and presentation) highlights these collaboration issues
– Communication
– Contracts
– Customer capability
• In-depth analysis of 18 projects conducted by a contractor
– Follow up of the large-scale study in 18 different organizations
– Personal interviews
• Overrun measure =),min(
)(
estimateactual
estimateactualBREbias
Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 28
Contracts
• Contracts are important since they often regulate collaboration (directly or indirectly)
• Common contract types– Time and material
– Fixed price
– Target price (better: Flexible pricing)• Mutual sharing of cost overruns (and
vice versa)• Floors and ceilings for cost sharing
Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission
Target PricingA pricing method that involves (1) identifying
the price at which a product will be
competitive in the marketplace, (2) defining
the desired profit to be made on the product,
and (3) computing the target cost for the
product by subtracting the desired profit from
the competitive market price. The formula
Target Price - Desired Profit = Target Cost
Target cost is then given to the engineers and
product designers, who use it as the
maximum cost to be incurred for the materials
and other resources needed to design and
manufacture the product. It is their
responsibility to create the product at or
below its target cost.http://www.answers.com/topic/target-pricing?cat=biz-fin
Desktop Technology Program 15
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 29
Contract form and overruns
N Mean Median
By the hour 4 0.55 0.37
Fixed price 5 0.33 0.19
Target price 7 0.10 0.21
Other 2 0.13 0.13
Contract form
BR
EB
ias
4 - Other3 - Target price2 - Fixed price1 - By the hour
1,5
1,0
0,5
0,0
-0,5
Boxplot of BREBias vs Contract form
Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 30
Contact frequency and overruns
• A Kruskal-Wallis test for difference results in p=0.023
• The corresponding size of effect is d=1.25, indicating a large size of effect
Communication frequency
BR
EB
ias
Not dailyDaily
2,0
1,5
1,0
0,5
0,0
Boxplot of BREBias by Communication frequency Level Mean Median
Daily 0.09 0.19
Not Daily 0.58 0.35
Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission
Desktop Technology Program 16
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 31
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 32
Why we plan
• Reduce risk
• Reduce uncertainty
• Support better decision making
• Establishing trust
• Conveying information
“Planning is everything. Plans are nothing.”
Field Marshal Helmuth Graf von Moltke
Mike Cohn: Agile Estimating & Planning
Desktop Technology Program 17
Mike Cohn: Agile Estimating & Planning, p. 4
Barry Boehm’s Cone of Uncertainty
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 34
Upfront Planning and the Cost of Change
Costof
change
time
Standard SE
Agile assumption
Desktop Technology Program 18
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 35
Why plans fail
• Completion of activity vs feature delivery– Activities don‟t finish early
Parkinson‟s Law: Work expands so as to fill the time available for its completion
– Lateness is passed down the schedule: One thing that goes wrong is passed on (while all things must go right for early start)
– Activities are not independent
• Multitasking causes further delays
Mike Cohn: Agile Estimating & Planning
Ibid. p 15
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 36
Desktop Technology Program 19
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 37
Some Terminology
• Project planning, iteration planning, planning
game (XP), sprint planning (Scrum)
• Story card/index card (XP), backlog entry
(Scrum), feature/feature set (FDD)
• Customer, goal donor/user, gold owner/client,
product owner, scrum master
• Spike
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 38
Architectural Spike
• Throw-away prototype
• Answers technical issue
• Reduce technical risk or improve reliability
• Usually: Pair for 1-2 weeks
Desktop Technology Program 20
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 39
Project Planning: Agile Way
• Business value focused
– User stories, features
• Project scope not fixed at beginning
reactive to changing business needs
• Short timeframes
– 1 week – 3 months
• Planning and coordination are team efforts
– Planning game
– Product backlog
– Daily standup meeting (scrum)
– Estimates done by developers
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 40
Time Boxes
• Never slip a date change scope
• Sometimes external deadlines are HARD
• Advantages
– Increased motivation
• Successful delivery keeps developers and customers happy
– Faster feedback
– Creates a constant project heartbeat
– Deadlines create pressure (counters: work fills time available)
• Advantages of flexible dates
– Release only when required scope is completed
– Overly optimistic deadlines are made more realistic
Desktop Technology Program 21
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 41
Feature-Driven Development (Coad, Lefevbre, De Luca)
• Deliver frequent, tangible, working results that
are “useful in the eyes of the client”
• A feature defines a task
• Group features into business-related sets
• Focus on delivering results every two weeks
• Track and report progress by feature progress
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 42
The Five FDD Processes
Peter Coad et al: Java Modeling Color with UML, Prentice Hall 1999, p.190
Desktop Technology Program 22
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 43
FDD Process
Peter Coad et al: Java Modeling Color with UML, Prentice Hall 1999, p.198
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 44
Agile Project Planning
• Project vision the really big picture
• Release planning strategic picture– Chooses a few months worth of user stories/features
– Date and scope
– Can be changed
– Creates product backlog
• Iteration planning tactical picture– Few weeks
– Set of stories prioritized by customer
– Creates sprint backlog
– Define set of tasks for each story
– Task granularity: 1-3 work days estimation accuracy
Desktop Technology Program 23
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 45
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 46
Agile Requirements Definition
• User stories/Backlog EntriesFeature requests– On index cards
– Short descriptions of a feature
– In customer language, no techno babble
– Provide value to customer
– Independent of each other
– Testable
– Small decompose large stories
• Estimated by developers:best case, most likely, worst case
• Collect story cards and prioritize them
Desktop Technology Program 24
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 47
When is a User Story Done?
• All unit tests pass
• All acceptance test pass
• The customer accepts it
• All refactorings are done
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 48
Who Decides ?
• Business decisions– Scope: which “user stories” should be developed
– Priority of stories
– Composition of releases
– Release dates
• Technical decisions– Time estimates for features/stories
– Elaborate consequences of business decisions
– Team organization and process
– Scheduling
Desktop Technology Program 25
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 49
Mike Cohn: Agile Estimating & Planning, p 135
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 50
Managing a Release
• Value Driven Releases
• Business value = f(cost, time, functionality, quality)
• 80% of the business value can be derived from
20% of the functionality
• Linear development: Christmas wish lists
• Iterative development: prioritized wish list
Desktop Technology Program 26
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 51
Minimum Marketable Features
• Components with intrinsic marketable value
• Creates business value by
– Competitive differentiation
– Revenue generation
– Cost Saving
– Brand projection
– Enhanced loyalty
M. Denne, J. Cleland-Huang: Software by Numbers,
Prentise-Hall, 2004
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 52
Prioritization of features
• Financial value
• Development cost
• Amount of learning
• Amount of risk removal
High risk
Low Value
Avoid
High risk
High Value
Do first
Low risk
High Value
Do second
Low risk
Low Value
Do lastLow
Low
High
HighValue
Ris
k
Mike Cohn: Agile Estimating & Planning, p 83+85
Desktop Technology Program 27
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 53
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 54
Low fi prototypes describing product vision
• Sketches
• Storyboards
• Pictive
• Wizard of Oz
Desktop Technology Program 28
Sketching and Prototyping
Early design
Late design
Brainstorm different representations
Choose a representation
Rough out interface style
Sketches & low fidelity paper prototypes (LO-FI)
Task centered walkthrough and redesign
Fine tune interface, screen design
Heuristic evaluation and redesign
Usability testing and redesign
Medium fidelity prototypes
Limited field testing
Alpha/Beta tests
High fidelity prototypes
Working systems
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Sketches & Low Fidelity Prototypes
• Paper mock-up of the interface look, feel, functionality– quick and cheap to prepare and modify
• Purpose– brainstorm competing
representations
– bring out user reactions
– bring out user modifications / suggestions
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Desktop Technology Program 29
Sketches– drawing of the outward appearance of the intended
system
– crudity means people concentrate on high level
concepts
– but hard to envision a dialog‟s progression
Computer Telephone
Last Name:
First Name:
Phone:
Place Call Help
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
The attributes of sketches
• Quick
– to make
• Timely
– provided when needed
• Disposable
– investment in the concept,
not the execution
• Plentiful
– they make sense in a
collection or series of ideas
• Clear vocabulary
– rendering & style indicates
it‟s a sketch, not an
implementation
• Constrained resolution
– doesn‟t restrain concept
exploration
• Consistency with state
– refinement of rendering
matches the actual state of
development of the
concept
• Suggest & explore
rather than confirm
– value lies in suggesting
and provoking what could
be
– sketches are the medium
to conversation and
interaction
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Desktop Technology Program 30
Storyboarding– a series of key frames as sketches
• originally from film; used to get the idea of a scene
• snapshots of the interface at particular points in the
interaction
– users can evaluate quickly the direction the interface
is heading
Excerpts from Disney’s Robin Hood storyboard
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
note how each scene in this storyboard is annotated
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Desktop Technology Program 31
Scan the stroller ->
Change the color ->
Place the order ->
Initial screen
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Scan the shirt ->
Touch previous item ->
Delete that item->
Alternatepath…
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Desktop Technology Program 32
Pictive plastic interface for collaborative technology initiatives through video exploration
Muller, CHI 1991
• Designing with office supplies– multiple layers of sticky notes and plastic overlays
– different sized stickies represent icons, menus, windows etc.
• interaction demonstrated by manipulating notes– new interfaces built on the fly
• session videotaped for later analysis– usually end up with mess of paper
and plastic!
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Pictive
• Can pre-make paper interface components
buttons menu alert
box
combo box
tabs
entries
list box
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Desktop Technology Program 33
Desktop Technology Program 34
Desktop Technology Program 35
Medium Fidelity Prototypes• “With a computer”
• Many different types
– from simple computer drawn images to partially working systems
• May take longer to generate and change than low-fi
• Benefits
– Seems more like the completed detailed system, provides a clearer
idea of how it works
– May allow user testing (not true for all medium fidelity prototypes).
• Pitfalls
– User‟s reactions are usually “in the small”
• Blinds people to major representational flaws because of a tendency to
focus on more minor details
– Users more reluctant to challenge/change the design itself
• Designs are too “pretty”, developers‟ egos…
– Management may think its real!
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Medium Fidelity
Painting/drawing packages
• draw each storyboard scene on computer
– very thin horizontal prototype (across features, no
functionality)
– does not capture the interaction “feel”
Control panel for pump 2
coolant flow 45 %
retardant 20%
speed 100%
Control panel for pump 2
coolant flow 0 %
retardant 20%
speed 100%
DANGER!
next drawing
Shut Down Shut Down
(for shut down condition)
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Desktop Technology Program 36
Control panel for pump 2
coolant flow 45 %
retardant 20%
speed 100%
Shut Down
Medium Fidelity
Scripted simulations• create storyboard with media tools on a
computer
– scene transition activated by simple user inputs
– a simple vertical prototype
– Can use PowerPoint…
• user given a very tight script/task to follow
– appears to behave as a real system
– script deviations blow the
simulation
Control panel for pump 2
coolant flow 0 %
retardant 20%
speed 100%
DANGER!
Shut Down
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Medium Fidelity
Interface builders
–Tools for letting a designer layout the common widgets
–Construct mode
• Change attributes of objects
–Test mode:
• Objects behave as they would under real situations
–Excellent for showing look and
feel
• A broader horizontal prototype
• But constrained to widget library
–Vertical functionality added
selectively
• Through programming
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Desktop Technology Program 37
• “pay no attention to
the man behind the
curtain!”
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Wizard of Oz
• A method of testing a system that does not exist
– the listening typewriter, IBM 1984
Dear Henry
What the user sees
SpeechComputer
From Gould, Conti & Hovanvecz, Comm ACM 26(4) 1983.
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Desktop Technology Program 38
Wizard of Oz
• A method of testing a system that does not exist
– the listening typewriter, IBM 1984
What the user sees The wizard
SpeechComputer
Dear Henry
Dear Henry
From Gould, Conti & Hovanvecz, Comm ACM 26(4) 1983.
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Wizard of Oz
• Human „wizard‟ simulates system response
– interprets user input according to an algorithm
– controls computer to simulate appropriate output
– uses real or mock interface
– wizard sometimes visible, sometimes hidden
• “pay no attention to the man behind the curtain!”
• good for:
– adding simulated and complex vertical
functionality
– testing futuristic ideas
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Desktop Technology Program 39
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 77
Scrum Flow (Sutherland, Schwaber and Beedle)
Ken Schwaber, Agile Project Management with Scrum,
Microsoft Press: 2004.
Scrum: 15 min daily meetings
Team members respond to basics:
-What did you do since last Scrum?
-Do you have any obstacles?
-What will you do before next meeting?
Features assigned to Sprint
Sprint: 30 days
Potentially Shippable Functionality
Desktop Technology Program 40
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 79
Cohn‟s Iteration Planning (p 145ff)
• Tasks are not allocated during iteration planning
devs pick 1-2 at start of iteration and then the next
when these are done
built “we‟re all in this together” attitude
• Iteration vs Release Planning (p. 149
Release Plan Iteration Plan
Planning horizon 3-9 months 1-4 weeks
Items in plan User stories Tasks
Estimated in Story points or
ideal days
Ideal hours
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 80
Agile estimation process
Desktop Technology Program 41
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 81
Size estimation
• Story points or Ideal Days (Gummy Bears, Effort, …) – “Complexity” or “size” of task
– Relative to other tasks
• Based on experiences from the past
• Team effort– Optimism wins
– Team usually does not overrule the estimate of programmers responsible for a task
• Presumed Issue: Effort estimates done by developers might lead to slack
Estimates
are not
commitments
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 82
Ideal days
• How long is an American football game:– 4 x 15min = 60min (ideal time
– Approx. 3h (elapsed time)
• Elapsed time is influenced by – amount of none-development tasks
– estimation accuracy
– available developer time
– experience
– number of concurrent projects
– …
Desktop Technology Program 42
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 83
Story points vs ideal days
• Story points
– Help drive cross-functional behavior
– Estimates do not decay
– Pure size measure
– Often faster
– My ideal days are not your ideal days
• Ideal days
– Easier to explain to outsiders
– Easier at first
Mike Cohn: Agile Estimating & Planning, p 69ff
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 84
Techniques for estimating
• You will NOT be 100% accurate
• Diminishing return of more estimation effort
• Estimation scale: stay within one order of magnitude
– User stories, epics, themes
• Deriving an estimate
– Expert opinion
– Analogy
– Disaggregation
– Planning poker
Mike Cohn: Agile Estimating & Planning, p 49ff
“Prediction is very difficult, especially about the future”
Niels Bohr
Desktop Technology Program 43
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 85
Splitting user stories
• Split along the boundaries of the data supported by the story– E.g. Loan summary List of individual loans List of loans
with error handling
• Split based on operations performed within a story– E.g. separate CRUD operations
• Remove cross-cutting concerns– E.g. story without and with security
• Separate functional from non-functional requirements– Make it work, then make it fast
• Tracer bullet through all layers with partial story functionality
Mike Cohn: Agile Estimating & Planning, p 121ff
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 86
Reflecting plan uncertainty
• (Best case), most likely
case, worst case
• Project buffer:
– Max 70% of must have
features
– MoSCoW rule (must have,
should have, could have,
won‟t have) in DSDM
– Alternative: calculate
standard deviation
• Slack needed for learning
Tom DeMarco: Slack
n
i
ii mlcewce1
2
)(
Desktop Technology Program 44
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 87
Velocity
• Measures rate of progress of a team
• Amount of story points completed in the last iteration
• Best guess: next iteration = same as last iteration (“yesterday’s weather”)
• Story points (or ideal days) + velocity duration– Velocity corrects estimation error
– Accommodates developer optimism
– overcomes the issue of if story points are measured based on pairs or individuals
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 88
Comments on story points and velocity
• Task effort depends on the current development context – developer experience with technology
– “likeness” of task to others
– availability of reusable code
• Story points is not well defined what does 1 story point really mean?– Changing velocities over time can‟t use “old” numbers
• Customers sometimes prefer estimates in hours
• Velocity maps story points to person-hours available in iteration– blurs development effort for customers
open & honest communication?
Desktop Technology Program 45
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 89
Observations from Past Planning Exercises
• Effort: 2-4h for one week of work
– Brainstorming user stories usually not done
– Assignment of responsibilities missing
• Language for specifying requirements
– Often too much IT oriented
• useful for communicating with customer?
– Often to fine grained
• user stories need to have business value
– Testing tasks are not user stories
• Required to be done – no choice for customer
• Business value?
• Interaction with customer is NOT finished
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 90
Sprint Review Meeting Rules
• 2-3 hours
• Maximum 1 hour preparation
• No PowerPoint presentations
• Done on equipment where software was developed and tested
• Presented by team to Product Owner and customers/users
• Basis for planning next Sprint
• Must represent potentially shippable increment of product functionality
Desktop Technology Program 46
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 91
Scrum Study (Mann/Maurer)
• 2 year longitudinal case study
• Researcher embedded in development team
• Overall results:
– Reduced
overtime
– Increased
customer
satisfaction
Average Percent Overtime Worked By Team
-20.00
0.00
20.00
40.00
60.00
80.00
100.00
01-0
5-2
003
02-0
9-2
003
03-1
6-2
003
04-2
0-2
003
05-2
5-2
003
06-2
9-2
003
08-0
3-2
003
09-0
7-2
003
10-1
2-2
003
11-1
6-2
003
12-2
1-2
003
01-2
5-2
004
02-2
9-2
004
04-0
4-2
004
05-0
9-2
004
06-1
3-2
004
07-1
8-2
004
08-2
2-2
004
09-2
6-2
004
10-3
1-2
004
12-0
5-2
004
01-0
9-2
005
02-1
3-2
005
Week
%
Ho
urs
Overt
ime
Scrum Introduced
New Windows
App Release
Website Release
Windows App 1 support and
Windows App 2
Development
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 92
Desktop Technology Program 47
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 93
Daily Scrums (Stand-up Meetings)
• Daily 15 minute status meeting
• Same place and time every day
• Meeting room
• Chickens and pigs
• Three questions;
– What have you done since last meeting?
– What will you do before next meeting?
– What is in your way?
• Impediments and
• Decisions
Based on Ken Schwaber‟s Certified Scrum Master course
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 94
Chickens and Pigs
• A chicken and a pig are together when the chicken says, "Let's start a restaurant!“
• The pig thinks it over and says, "What would we call this restaurant?“
• The chicken says, "Ham n' Eggs!"
• The pig says, "No thanks. I'd be committed, but you'd only be involved!"
Based on Ken Schwaber’s
Certified Scrum Master course
Desktop Technology Program 48
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 95
Benefits of the Daily Meeting
• Focuses people to think about what has to be
done in the short term
• Puts peer pressure to see who is working to
accomplish goals
• Surfaces roadblocks quickly
• Forces managers to not interfere with the project
team
From: http://www.controlchaos.com/old-site/meeting.htm
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 96
End-of-Sprint Review
Based on Ken Schwaber‟s
Certified Scrum Master course
Proceed or terminate?
Proceed:
define next iteration
Desktop Technology Program 49
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 97
Sprint Review Meeting Rules
• 2-3 hours
• Maximum 1 hour preparation
• No PowerPoint presentations
• Done on equipment where software was developed and tested
• Presented by team to Product Owner and customers/users
• Basis for planning next Sprint
• Must represent potentially shippable increment of product functionality
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 98
Reporting: Tracking Progress & Metrics
• Two questions– How many hours/days have you worked?
– How many more does it take?
• Project metrics– Actual time worked on a task
– Work burndown graph• Per iteration
• #Backlog project
– #Bugs
– #Stories completed
– #Acceptance tests defined and passing
– #Unit tests
– Test coverage
– …
Which one is more important}
Desktop Technology Program 50
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 99
Iteration tracking
Ibid 228
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 100
Project Tracking: Work Burndown ChartsNo one home
0
500
1000
1500
2000
2500
1 3 5 7 9
11
13
15
17
19
21
23
25
27
29
31
No one home
Underestimating
0
500
1000
1500
2000
2500
3000
1 3 5 7 9
11
13
15
17
19
21
23
25
27
29
31
Underestimating
Overestimating
0
200
400
600
800
1000
1200
1400
1600
1800
1 3 5 7 9
11
13
15
17
19
21
23
25
27
29
31
Overestimating
Based on Ken Schwaber’s
Certified Scrum Master course
Desktop Technology Program 51
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 101
Progress Tracking with FDD
http://www.togethercommunity.com/coad-letter/Coad-Letter-0070.html
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 102
Parking Lot Diagram
Pg. 201, Java Modeling in Color with UML
Desktop Technology Program 52
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 103
Agile Practices
• Agile methods lay out a vision and then nurtures project resources
to do the best possible to achieve the plan.
• Agile is the “art of the possible.”
• “better to beg forgiveness than ask permission.”
• Agile employs the following practices:
– Frequent inspection and adaptation
– Emergence of requirements, technology, and team capabilities
– Self-organization and adaptation in response to what emerges
• Creativity
• Let the team figure out what to do and then do it
– Incremental emergence
– Dealing with reality, not artifacts
– Collaboration
Based on Ken Schwaber‟s Certified Scrum Master course
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 104
Scrum – Tips, Tricks, Observations
• Pay $1 for being late for a Scrum meeting
• Always deliver a vertical slice of user functionality
• Scrum backlog entries tend to be coarser grained than XP user stories
• Keep things visible in customer terms
• In Scrum meetings NO information is passed that is not potentially of interest for everybody
• Best case plan versus minimum promised to customer
• Sprint review & planning meeting: – 1.5days initially
– Later 1day
• Planning horizon: do not overlook the big picture
• Process improvement entries in backlog
• Inter-team learning: informal meeting of Scrum masters
• Scrum is scalable– Scrum of Scrums
– Multiple teams working together: 20% overhead
– Infrastructure teams (often: virtual teams): other teams are customers
• Architecture diagram for reporting progress visually
Desktop Technology Program 53
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 105
Common Impediments
• Workstation, network, and/or server are down;
• Network or server are slow;
• Required to attend human resource training session;
• Required to attend status meeting with management;
• Asked by management to do something else;
• Asked to do something other than what this team
member committed to for this Sprint;
• Unsure about how to proceed;
• Unsure of design decision; and
• Unsure how to use technology.Based on Ken Schwaber‟s Certified Scrum Master course
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 106
Why does it work?
• Replanning occurs frequently
• Separation of size and duration
• Plans at different levels
• Small cycle time (i.e small stores) keeps work
flowing
• Fuzzy states (e.g. 70% done) are elimnated
• Tracking at the team level
• Uncertainty is planned for
Ibid p 249ff
Desktop Technology Program 54
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07 Agile Project Management 107
Summary
• Vision, release, iteration
• Short horizon for detailed planning
• Reporting needs to tie in with vision and
business value
• Adaptive and flexible
• Team effort
Discussion
http://ebe.cpsc.ucalgary.ca/Frank.Maurer