i290 lean/agile product management
unit 6: managing work
This work © 2015-2020 Jez Humble
Licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
consider key metrics and the eﬀect of measurement
understand the diﬀerent roles people play on teams
be able to explain key frameworks and their goals
distinguish what is and isn’t essential
be able to perform planning activities
the production line
•Our highest priority is to satisfy the customer through early and continuous delivery of
•Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
•Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.
•Business people and developers must work together daily throughout the project.
•Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
•The most eﬃcient and eﬀective method of conveying information to and within a
development team is face-to-face conversation.
•Working software is the primary measure of progress.
•Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indeﬁnitely.
•Continuous attention to technical excellence and good design enhances agility.
•Simplicity—the art of maximizing the amount of work not done—is essential.
•The best architectures, requirements, and designs emerge from self-organizing teams.
•At regular intervals, the team reﬂects on how to become more eﬀective, then tunes and
adjusts its behavior accordingly.
xp scrum kanban
openness, & respect
principles 14 principles
start where you are;
change; respect existing
roles, responsibilities &
practices 13 practices 3 artifacts, 5 events
visualize work, limit WIP,
manage ﬂow, make mgmt
policies explicit, improve
whole team including
product owner, scrum
cadence 1-2 week iterations 2-4 week iterations ﬂow-based (no iterations)
measuring velocity velocity + burndown lead time
team estimates stories, breaking down large ones
every 1-4 weeks on cadence, put aside 1-3h
prerequisite: user stories derived from goals/backlog
product owner veriﬁes capacity and prioritizes work
team identiﬁes areas of risk and discusses mitigations
iteration planning meetings
dependencies on other teams / systems
we don’t know how we will do the work
we don’t know if the work will achieve the outcome
Leaky abstractions: http://www.joelonsoftware.com/articles/LeakyAbstractions.html
understand if we can achieve our goals
identify large/risky work and break down/mitigate
grow shared understanding of how work will be done
set expectations with stakeholders
• t-shirt sizing
• function points
• COCOMO predictors
• SLIM parameters
• beware: relative vs absolute!
try it for a few weeks
Cumulative Flow Diagram (CFD) / burn up chart / turndown chart / ﬁnger diagram
the people who made the estimates do the work
not a productivity metric!
can’t be compared across teams
it can be gamed (Goodhart's law)
problems with velocity
design vs delivery
Product Design and Development
(build, testing, deployment)
Create new products and services that
solve customer problems using
hypothesis-driven delivery, modern UX,
Enable fast ﬂow from development to
production and reliable releases by
standardizing work, reducing variability
and batch sizes.
Feature design and implementation may
require work that has never been
Integration, test and deployment must be
performed continuously as quickly as
Estimates are highly uncertain.
Cycle times should be well-known and
Outcomes are highly variable. Outcomes should have low variability.
2019 State of DevOps Report: cloud.google.com/devops
lean mgmt & product dev
“At regular intervals, the team reﬂects
on how to become more eﬀective, then
tunes and adjusts its behavior
to propose experiments for getting better
held at the end of an iteration before planning
to reﬂect on—and learn from—the past as a team
many possible exercises / activities!
retrospective prime directive
“Regardless of what we discover, we
understand and truly believe that
everyone did the best job they could,
given what they knew at the time, their
skills and abilities, the resources
available, and the situation at hand.”
— Norm Kerth
• Extreme Programming Explained: Embrace Change (2nd Edition) by
Kent Beck and Cynthia Andres
• Kanban: Successful Evolutionary Change for Your Technology Business by
David J Anderson