See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/221592363
Agile Project Management
Conference Paper · August 2004
DOI: 10.1007/978-3-540-27777-4_29 · Source: DBLP
CITATIONS
READS
267
22,759
6 authors, including:
Frank Maurer
Philippe Kruchten
The University of Calgary
University of British Columbia - Vancouver
308 PUBLICATIONS 6,298 CITATIONS
290 PUBLICATIONS 13,919 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Collaboration Meets Interactive Spaces: A Springer Book View project
Social Debt in Software Engineering View project
All content following this page was uploaded by Philippe Kruchten on 13 March 2014.
The user has requested enhancement of the downloaded file.
SEE PROFILE
Agile Project Management
Frank Maurer
University of Calgary
Computer Science
e-Business Engineering Group
maurer@cpsc.ucalgary.ca
http://ebe.cpsc.ucalgary.ca/Frank.Maurer/
Project Management?
•
•
•
•
•
What is it?
Why do we need it?
What is important?
Best experience?
Worst experience?
20-Sep-07
Agile Project Management
2
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
1
Why estimate effort?
20-Sep-07
Agile Project Management
3
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07
Agile Project Management
4
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
2
20-Sep-07
Agile Project Management
5
Copyright © 2006 Frank Maurer. All Rights Reserved.
Common Management Issues
•
•
•
•
•
•
Building teams
Risk management
Project planning
Team coordination
Progress tracking
Quality assurance
20-Sep-07
Agile Project Management
6
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
3
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
•
•
•
20-Sep-07
what is to be done
how it is to be done
the exact time allowed for doing it
Agile Project Management
7
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
8
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
4
Empowerment
•
•
•
•
•
Self-determination
Motivation
Leadership
Expertise
Amplify learning by
feedback and frequent
synchronization
20-Sep-07
Agile Project Management
9
Copyright © 2006 Frank Maurer. All Rights Reserved.
Risk Management
• Risk identification
– E.g. unknown technologies, tools
• Risk quantification
• Risk resolution
– Reserve time for
overcoming troubles
– Define tasks that reduce
risks
• Contingency plan
20-Sep-07
http://www.pru.uts.edu.au/images/risk_management_benefits.gif
Agile Project Management
10
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
5
Typical Risks
• Changing scope
• Technology is immature or unknown to
developers
• Wrong effort estimates
• Low quality
• …
20-Sep-07
Agile Project Management
11
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07
Agile Project Management
12
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
6
Four Project Variables
•
Cost
– CHAOS Reports, Standish Group, 19942002
•
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
20-Sep-07
Agile Project Management
13
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
14
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
7
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
20-Sep-07
Agile Project Management
15
Copyright © 2006 Frank Maurer. All Rights Reserved.
Project Management Tasks
•
Planning the project
– Define tasks, task dependencies and milestones
•
Estimate effort
•
Scheduling the tasks
– How long will it take to do something
– 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
20-Sep-07
Agile Project Management
16
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
8
Gantt Chart
20-Sep-07
Agile Project Management
17
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
18
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
9
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)
20-Sep-07
Agile Project Management
19
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
20
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
10
20-Sep-07
Agile Project Management
21
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
22
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
11
Product Owner
•
•
•
•
•
Defines project vision  big picture
Provides/finds funding for projects
Checks ROI
Prioritizes backlog
One person – must represent all stakeholders
20-Sep-07
Agile Project Management
23
Copyright © 2006 Frank Maurer. All Rights Reserved.
DSDM Process
Feasibility
Feasibility
Agree schedule
Create
Functional
Prototype
Functional Model
Implement
Identify
Functional
Prototype
Review
business
busines
s
Implementation
Train
users
User approval and
user guidelines
Review Prototype
Identify
Design prototype
Agree
Schedule
Design and Build
Iteration
Review
Design
Prototype
Create
Design Prototype
20-Sep-07
Agile Project Management
24
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
12
Return on Investment (ROI)
• Payback time
Software by Numbers, p. 16
• Net present value, internal rate of return
 SE Economics
• Monetary versus non-monetary payback
20-Sep-07
Agile Project Management
25
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
Cost of
change requests
How urgently do
I need the contract?
Risk multiplier
(Insurance premium)
Honest effort estimate
26
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
13
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 =
BREbias 
(actual  estimate )
min( actual , estimate )
Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission
20-Sep-07
Agile Project Management
27
Copyright © 2006 Frank Maurer. All Rights Reserved.
Contracts
• Contracts are important since they often regulate
collaboration (directly or indirectly)
Target Pricing
• 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
A 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
Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission
20-Sep-07
Agile Project Management
28
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
14
Contract form and overruns
Boxplot of BREBias vs Contract form
1,5
BREBias
1,0
0,5
0,0
-0,5
1 - By the hour
2 - Fixed price
3 - Target price
Contract form
4 - Other
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
Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission
20-Sep-07
Agile Project Management
29
Copyright © 2006 Frank Maurer. All Rights Reserved.
Contact frequency and overruns
BREBias
Boxplot of BREBias by Communication frequency
2,0
Level
Mean
Median
1,5
Daily
0.09
0.19
1,0
Not Daily
0.58
0.35
0,5
0,0
Daily
Not daily
Communication frequency
•
•
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
Moløkken-Østvold, Furulund: “The Relationship between Customer Collaboration and Software Project Overruns”, slide used with permission
20-Sep-07
Agile Project Management
30
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
15
20-Sep-07
Agile Project Management
31
Copyright © 2006 Frank Maurer. All Rights Reserved.
Mike Cohn: Agile Estimating & Planning
Why we plan
“Planning is everything. Plans are nothing.”
Field Marshal Helmuth Graf von Moltke
•
•
•
•
•
Reduce risk
Reduce uncertainty
Support better decision making
Establishing trust
Conveying information
20-Sep-07
Agile Project Management
32
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
16
Barry Boehm’s Cone of Uncertainty
Mike Cohn: Agile Estimating & Planning, p. 4
Upfront Planning and the Cost of Change
Standard SE
Cost
of
change
Agile assumption
time
20-Sep-07
Agile Project Management
34
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
17
Mike Cohn: Agile Estimating & Planning
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
Ibid. p 15
20-Sep-07
Agile Project Management
35
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07
Agile Project Management
36
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
18
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
20-Sep-07
Agile Project Management
37
Copyright © 2006 Frank Maurer. All Rights Reserved.
Architectural Spike
•
•
•
•
Throw-away prototype
Answers technical issue
Reduce technical risk or improve reliability
Usually: Pair for 1-2 weeks
20-Sep-07
Agile Project Management
38
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
19
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
20-Sep-07
Agile Project Management
39
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
40
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
20
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
20-Sep-07
Agile Project Management
41
Copyright © 2006 Frank Maurer. All Rights Reserved.
The Five FDD Processes
Peter Coad et al: Java Modeling Color with UML, Prentice Hall 1999, p.190
20-Sep-07
Agile Project Management
42
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
21
FDD Process
Peter Coad et al: Java Modeling Color with UML, Prentice Hall 1999, p.198
20-Sep-07
Agile Project Management
43
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
44
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
22
20-Sep-07
Agile Project Management
45
Copyright © 2006 Frank Maurer. All Rights Reserved.
Agile Requirements Definition
• User stories/Backlog Entries
Feature 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
20-Sep-07
Agile Project Management
46
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
23
When is a User Story Done?
•
•
•
•
All unit tests pass
All acceptance test pass
The customer accepts it
All refactorings are done
20-Sep-07
Agile Project Management
47
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
48
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
24
Mike Cohn: Agile Estimating & Planning, p 135
20-Sep-07
Agile Project Management
49
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
50
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
25
M. Denne, J. Cleland-Huang: Software by Numbers,
Prentise-Hall, 2004
Minimum Marketable Features
• Components with intrinsic marketable value
• Creates business value by
–
–
–
–
–
Competitive differentiation
Revenue generation
Cost Saving
Brand projection
Enhanced loyalty
20-Sep-07
Agile Project Management
51
Copyright © 2006 Frank Maurer. All Rights Reserved.
Mike Cohn: Agile Estimating & Planning, p 83+85
Prioritization of features
• Amount of risk removal
High
High risk
Low Value
High risk
High Value
Avoid
Do first
Low risk
Low Value
Low risk
High Value
Risk
• Financial value
• Development cost
• Amount of learning
Do last
Low
Low
20-Sep-07
Agile Project Management
Do second
Value
High
52
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
26
20-Sep-07
Agile Project Management
53
Copyright © 2006 Frank Maurer. All Rights Reserved.
Low fi prototypes describing product vision
•
•
•
•
Sketches
Storyboards
Pictive
Wizard of Oz
20-Sep-07
Agile Project Management
54
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
27
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Sketching and Prototyping
Early design
Brainstorm different representations
Choose a representation
Sketches & low fidelity paper
prototypes (LO-FI)
Rough out interface style
Task centered walkthrough and redesign
Medium fidelity prototypes
Fine tune interface, screen design
Heuristic evaluation and redesign
Usability testing and redesign
High fidelity prototypes
Limited field testing
Alpha/Beta tests
Working systems
Late design
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
Desktop Technology Program
28
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
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
Desktop Technology Program
• 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
29
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
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
Desktop Technology Program
30
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Initial
screen
Change the
color ->
Scan the
stroller ->
Place the
order ->
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
Alternate
path…
Touch
previous
item ->
Desktop Technology Program
Scan the
shirt ->
Delete
that item->
31
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
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
list box
entries
Desktop Technology Program
32
Desktop Technology Program
33
Desktop Technology Program
34
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
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
Control panel for pump 2
DANGER!
coolant flow 45 %
coolant flow 0 %
next
drawing
retardant 20%
speed 100%
Shut Down
Desktop Technology Program
retardant 20%
(for shut
down
condition)
speed 100%
Shut Down
35
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
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
Control panel for pump 2
– script deviations blow the
DANGER!
simulation
coolant flow 45 %
coolant flow 0 %
retardant 20%
speed 100%
Shut
Shut Down
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
Desktop Technology Program
36
Courtesy of Dr Sharlin/Greenberg (CPSC 481)
• “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
Speech
Computer
What the user sees
From Gould, Conti & Hovanvecz, Comm ACM 26(4) 1983.
Desktop Technology Program
37
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
Dear Henry
Speech
Computer
What the user sees
The wizard
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
Desktop Technology Program
38
20-Sep-07
Agile Project Management
77
Copyright © 2006 Frank Maurer. All Rights Reserved.
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?
Sprint: 30 days
Features assigned to Sprint
Desktop Technology Program
Potentially Shippable Functionality
39
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
20-Sep-07
Agile Project Management
79
Copyright © 2006 Frank Maurer. All Rights Reserved.
Agile estimation process
20-Sep-07
Agile Project Management
80
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
40
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
Estimates
are not
commitments
• Presumed Issue:
Effort estimates done by developers might lead to slack
20-Sep-07
Agile Project Management
81
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
…
20-Sep-07
Agile Project Management
82
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
41
Mike Cohn: Agile Estimating & Planning, p 69ff
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
20-Sep-07
Agile Project Management
83
Copyright © 2006 Frank Maurer. All Rights Reserved.
Mike Cohn: Agile Estimating & Planning, p 49ff
Techniques for estimating
“Prediction is very difficult, especially about the future”
Niels Bohr
• 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
20-Sep-07
Agile Project Management
84
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
42
Mike Cohn: Agile Estimating & Planning, p 121ff
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
20-Sep-07
Agile Project Management
85
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
n
• Slack needed for learning
 Tom DeMarco: Slack
 (wce mlce )
2
i
i
i 1
20-Sep-07
Agile Project Management
86
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
43
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
20-Sep-07
Agile Project Management
87
Copyright © 2006 Frank Maurer. All Rights Reserved.
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?
20-Sep-07
Agile Project Management
88
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
44
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
20-Sep-07
Agile Project Management
89
Copyright © 2006 Frank Maurer. All Rights Reserved.
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
20-Sep-07
Agile Project Management
90
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
45
Scrum Study (Mann/Maurer)
• 2 year longitudinal case study
• Researcher embedded in development team
Average Percent Overtime Worked By Team
• Overall results:
Windows App 1 support and
Windows App 2
Development
100.00
Scrum Introduced
New Windows
App Release
80.00
% Hours Overtime
60.00
Website Release
40.00
20.00
0.00
02-13-2005
01-09-2005
12-05-2004
10-31-2004
09-26-2004
08-22-2004
07-18-2004
06-13-2004
05-09-2004
04-04-2004
02-29-2004
01-25-2004
12-21-2003
11-16-2003
10-12-2003
09-07-2003
08-03-2003
06-29-2003
05-25-2003
04-20-2003
03-16-2003
02-09-2003
-20.00
01-05-2003
– Reduced
overtime
– Increased
customer
satisfaction
Week
20-Sep-07
Agile Project Management
91
Copyright © 2006 Frank Maurer. All Rights Reserved.
20-Sep-07
Agile Project Management
92
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
46
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
20-Sep-07
Agile Project Management
93
Copyright © 2006 Frank Maurer. All Rights Reserved.
Based on Ken Schwaber’s
Certified Scrum Master course
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!"
20-Sep-07
Agile Project Management
94
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
47
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
20-Sep-07
Agile Project Management
95
Copyright © 2006 Frank Maurer. All Rights Reserved.
End-of-Sprint Review
Proceed or terminate?
Proceed:
define next iteration
Based on Ken Schwaber‟s
Certified Scrum Master course
20-Sep-07
Agile Project Management
96
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
48
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
20-Sep-07
Agile Project Management
97
Copyright © 2006 Frank Maurer. All Rights Reserved.
Reporting: Tracking Progress & Metrics
• Two questions
– How many hours/days have you worked?
– How many more does it take?
}
Which one is more important
• 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
…
20-Sep-07
Agile Project Management
98
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
49
Iteration tracking
Ibid 228
20-Sep-07
Agile Project Management
99
Copyright © 2006 Frank Maurer. All Rights Reserved.
Based on Ken Schwaber’s
Certified Scrum Master course
Project Tracking: Work Burndown Charts
No one home
2500
2000
1500
No one home
1000
500
Underestimating
31
29
27
25
23
21
19
17
15
9
13
7
11
5
3
1
0
Overestimating
3000
1800
1600
2500
1400
2000
1200
1000
1500
Underestimating
Overestimating
800
1000
600
400
500
200
20-Sep-07
Agile Project Management
31
29
27
25
23
21
19
17
15
13
11
9
7
5
3
0
1
31
29
27
25
23
21
19
17
15
13
9
7
11
5
3
1
0
100
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
50
Progress Tracking with FDD
http://www.togethercommunity.com/coad-letter/Coad-Letter-0070.html
20-Sep-07
Agile Project Management
101
Copyright © 2006 Frank Maurer. All Rights Reserved.
Parking Lot Diagram
Pg. 201, Java Modeling in Color with UML
20-Sep-07
Agile Project Management
102
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
51
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
20-Sep-07
Agile Project Management
103
Copyright © 2006 Frank Maurer. All Rights Reserved.
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:
–
–
•
•
•
•
Planning horizon: do not overlook the big picture
Process improvement entries in backlog
Inter-team learning: informal meeting of Scrum masters
Scrum is scalable
–
–
–
•
1.5days initially
Later 1day
Scrum of Scrums
Multiple teams working together: 20% overhead
Infrastructure teams (often: virtual teams): other teams are customers
Architecture diagram for reporting progress visually
20-Sep-07
Agile Project Management
104
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
52
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
20-Sep-07
Agile Project Management
105
Copyright © 2006 Frank Maurer. All Rights Reserved.
Ibid p 249ff
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
20-Sep-07
Agile Project Management
106
Copyright © 2006 Frank Maurer. All Rights Reserved.
Desktop Technology Program
53
Summary
• Vision, release, iteration
• Short horizon for detailed planning
• Reporting needs to tie in with vision and
business value
• Adaptive and flexible
• Team effort
20-Sep-07
Agile Project Management
107
Copyright © 2006 Frank Maurer. All Rights Reserved.
Discussion
maurer@cpsc.ucalgary.ca
http://ebe.cpsc.ucalgary.ca/Frank.Maurer
Desktop Technology Program
View publication stats
54