Cagan: So tell me, why you don’t empower your team(s)? CEO/ Manager (voice is going down): You know, I don’t trust them. You saw them – you met them, right? (pause) How could you trust them, how should I trust them? So tell me, what should I do? Cagan: What? Wait – really??? But you hired them! So what do you want me to do?
Agile experiences from the trenches #DBART 2020
IoT is f*#%ing awesome! Like a boss...
from the trenches
Subject period March 2017 till January 2020; product available since 2013
New organisation since February 2020
Product Owner’s view; biased personal view; incomplete
Individual agile development process
DTAG 5 level hierarchies and mixed legal
Organising your product and value streams matters
and is reflected in Conway’s law:
“…organizations which design
systems … are constrained to
produce designs which are
copies of the communication
structures of these
Larman's Laws of Organizational Behavior
1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-
level manager and “specialist” positions & power structures.
2. As a corollary to (1), any change initiative will be reduced to redefining or overloading
the new terminology to mean basically the same as status quo.
3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”,
“revolutionary”, "religion", and “needing pragmatic customization for local concerns” —
which deflects from addressing weaknesses and manager/specialist status quo.
4. As a corollary to (1), if after changing the change some managers and single-specialists
are still displaced, they become “coaches/trainers” for the change, frequently reinforcing
(2) and (3).
5. Culture follows structure.
Try system thinking - WIP it real good
Count the hops between the
team and ...
- sales & marketing
- each other (inc. design & test)
- the budget
- data & insights
- deployment into prod
- prod-like env
- hiring (new teammates)
You'll learn a ton.
“A bad system will beat a good person every time.”
– W. Edwards Deming
The nudge: product teams and thinking
Delivery vs feature vs product teams
Delivery teams are not cross-functional (basically just developers plus a backlog
administrator product owner), they are not focused on outcome (they are all about
output), and they are not empowered (they are there to code and ship).
Feature teams usually are cross-functional (at least some form of designer and some
form of product manager), but they are still all about output and not empowered.
Product teams are cross-functional, focused and measured by outcome, and
empowered to come up with solutions that work.
Product Team Empowerment
Why don’t more companies empower their teams?
In a word:
- Marty Cagan
“People are allowed to do their thing.”
12 Signs You’re Working in a Feature Factory
● No measurement.
● Rapid shuffling of teams and projects (aka Team Tetris)
● Success theater around “shipping” with little discussion
● Infrequent (acknowledged) failures and scrapped work.
● No connection to core metrics.
● No PM retrospectives.
● Obsessing about prioritization.
● No tweaking.
● Large batches.
● Chasing upfront revenue.
● Shiny objects
Tetris mindset: fetishizing busyness & output
Pandora’s box of prioritization: roadmap violation & overcommitment
A roadmap IS NOT
● a project or release plan
● a list with dates and features
A roadmap IS
● a strategic communication tool
● a prototype of your product strategy
● state of intend and direction
● how you will realize your product vision
The revenge of the PMO - obsession with (ill-)planning
Roadmap vs project plan
Impact with product team empowerment
Output over outcome?
Goal: Ship fast!
● Continuous Integration
Deciding what to build.
Goal: Learn fast.
● Are we meeting stakeholder needs?
● Can customers use it?
● Do customers want our solution?
● Are we solving a problem the customer
● Are we driving a desired outcome?
XP: Manage Your Goals Instead of Activities
Less of... More of ...
An Iterative Waterfall Isn’t Agile - #BDUF
Engineering gets brought in way too late!
Dual track development
“To set your expectations,
strong teams normally test
many product ideas each
week—on the order of 10 to 20
or more per week.”
- Marty Cagan (Inspired)