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

282 29,850

6 authors, including:

Frank Maurer Philippe Kruchten

The University of Calgary University of British Columbia
319 PUBLICATIONS 6,889 CITATIONS 290 PUBLICATIONS 14,995 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Philippe Kruchten on 13 March 2014.

The user has requested enhancement of the downloaded file.

 Agile Project Management

Frank Maurer
University of Calgary
Computer Science
e-Business Engineering Group
[email protected]
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

• what is to be done
• how it is to be done
• the exact time allowed for doing it

20-Sep-07 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 http://www.pru.uts.edu.au/images/risk_management_benefits.gif

20-Sep-07 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, 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

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
– 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
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 Implement

Create Identify
Functional Functional Model Functional Review Implementation Train
Prototype Prototype business
busines users
s
User approval and
Review Prototype user guidelines

Identify
Design prototype
Agree Review
Design and Build
Schedule Design
Iteration
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 Cost of
– Contract requires documentation change requests
 imposes process
– Opposing sides of table
• How are fixed prices derived by development
organization? How urgently do
I need the contract?
• Time and expenses contracts: Fixed budget/
variable scope/early termination
– Trust by feedback and involvement
Risk multiplier
– Collaborative environment
(Insurance premium)
– Changes easy
– Issues:
• No time limit on project Honest effort estimate
• No guaranteed functionality

20-Sep-07 Agile Project Management 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
(actual  estimate )
• Overrun measure = BREbias 
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)
• Common contract types Target Pricing
A pricing method that involves (1) identifying
– Time and material the price at which a product will be
– Fixed price competitive in the marketplace, (2) defining
the desired profit to be made on the product,
– Target price (better: Flexible pricing) and (3) computing the target cost for the
product by subtracting the desired profit from
• Mutual sharing of cost overruns (and the competitive market price. The formula
vice versa)
• Floors and ceilings for cost sharing 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

1,0
BREBias

0,5

0,0

-0,5
1 - By the hour 2 - Fixed price 3 - Target price 4 - Other
Contract form 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

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
BREBias

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
• Financial value • Amount of risk removal
• Development cost
High
High risk High risk
Low Value High Value
• Amount of learning
Avoid Do first
Risk

Low risk Low risk

Low Value High Value

Low Do last Do second

Low Value High

20-Sep-07 Agile Project Management 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 Sketches & low fidelity paper
Choose a representation 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 • Constrained resolution
– to make – doesn‟t restrain concept
• Timely exploration
– provided when needed • Consistency with state
• Disposable – refinement of rendering
matches the actual state of
– investment in the concept, development of the
not the execution concept
• Plentiful • Suggest & explore
– they make sense in a rather than confirm
collection or series of ideas
– value lies in suggesting
• Clear vocabulary and provoking what could
– rendering & style indicates be
it‟s a sketch, not an – sketches are the medium
implementation to conversation and
interaction

Desktop Technology Program 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 Scan the

screen stroller ->

Change the Place the

color -> order ->

Courtesy of Dr Sharlin/Greenberg (CPSC 481)

Alternate Scan the

path… shirt ->

Touch Delete
previous that item->
item ->

Desktop Technology Program 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 % next coolant flow 0 %
drawing
retardant 20% retardant 20%
(for shut
speed 100% down speed 100%
condition)

Shut Down Shut Down

Desktop Technology Program 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
– script deviations blow the Control panel for pump 2
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)

Scrum: 15 min daily meetings
Team members respond to basics:
-What did you do since last Scrum?
-Do you have any obstacles?
Ken Schwaber, Agile Project Management with Scrum, -What will you do before next meeting?
Microsoft Press: 2004.

Sprint: 30 days

Features assigned to Sprint Potentially Shippable Functionality

Desktop Technology Program 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 hours
ideal days
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 Estimates
• Team effort are not
– Optimism wins commitments
– Team usually does not
overrule the estimate of
programmers responsible for a task
• 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 • Slack needed for learning
standard deviation  Tom DeMarco: Slack
n

 (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
• Overall results: Average Percent Overtime Worked By Team
Windows App 1 support and
Scrum Introduced
100.00 Windows App 2
– Reduced 80.00
Development
New Windows
App Release

% Hours Overtime
overtime 60.00 Website Release

– Increased 40.00

20.00
customer
0.00

satisfaction -20.00
01-05-2003
02-09-2003
03-16-2003
04-20-2003
05-25-2003
06-29-2003
08-03-2003
09-07-2003
10-12-2003
11-16-2003
12-21-2003
01-25-2004
02-29-2004
04-04-2004
05-09-2004
06-13-2004
07-18-2004
08-22-2004
09-26-2004
10-31-2004
12-05-2004
01-09-2005
02-13-2005
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

0
11

13

15

17

19

21

23

25

27

29

31
1

Underestimating Overestimating

3000 1800

1600
2500
1400

2000 1200

1000
1500 Underestimating Overestimating
800

1000 600

400
500
200

0
0
11

13

15

17

19

21

23

25

27

29

31
1

11

13

15

17

19

21

23

25

27

29

31
1

20-Sep-07 Agile Project Management 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:
– 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

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

[email protected]
http://ebe.cpsc.ucalgary.ca/Frank.Maurer

Desktop Technology Program

View publication stats
54