Stand Back and Deliver Making Ship Happen A Framework for Agile Leadership Todd Little •

Download Report

Transcript Stand Back and Deliver Making Ship Happen A Framework for Agile Leadership Todd Little •

Stand Back and Deliver
Making Ship Happen
A Framework
for Agile Leadership
Todd Little
•
Making Ship Happen
Managing the Coming Storm
Inside the Tornado
Project Kickoff
When will we get the requirements?
All in good time, my little pretty, all in good time
But I guess it doesn't matter anyway
Just give me your estimates by this afternoon
Team Unity
Not so fast! Not so fast! ... I'll have to give the matter a little
thought. Go away and come back tomorrow
No, we need something today!
Ok then, it will take 2 years.
No, we need it sooner.
Doesn't anybody believe me?
I already promised the customer it will be out in 6 months
You're a very bad man!
We’re not in Kansas
Anymore
Developer Hero
I may not come out alive, but I'm goin' in there!
Reorg
The Great and Powerful Oz has got matters well in hand.
My! People come and go so quickly here!
Testing
"Hee hee hee ha ha! Going so soon? I wouldn't
hear of it! Why, my little party's just beginning!
Hurricane Rita
On Time
To Spec
Within Budget
Long Ago
Excellent! Pharaoh
will be quite pleased
to learn that you’ve
completed
construction under
budget and ahead of
schedule.
Da Plan, Boss – Da Plan
Long Ago and Far, Far Away…
Long Ago and Far Away
Long Ago and Far Away
Long Ago and Far Away
Long Ago and Far Away
Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:




Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Agile Manifesto Revisited:
Dealing with the Right
 Processes and tools that support agility,
individuals and interactions (e.g. wikis,
collaboration environments, etc.)
 Documentation as a consumable rather than as a
deliverable.
 Contracts that are written in a manner consistent
with collaboration and agile delivery
 Plans that anticipate and expect change
We are a community of project leaders that are highly
successful at delivering results. To achieve these results:
•We increase return on investment by making continuous flow of
value our focus.
•We deliver reliable results by engaging customers in frequent
interactions and shared ownership
•We expect uncertainty and manage for it through iterations,
anticipation, and adaptation.
•We unleash creativity and innovation by recognizing that individuals
are the ultimate source of value, and creating an environment where
they can make a difference.
•We boost performance through group accountability for results and
shared responsibility for team effectiveness.
•We improve effectiveness and reliability through situationally
specific strategies, processes and practices.
Declaration of Independence from Bureaucratic
Project Management
When in the Course of project events it becomes
necessary for Project Teams to dissolve the political
bureaucracies which have burdened them, a decent
respect to the opinions of mankind requires that they
should declare the causes which impel them to the
separation.
We hold these truths to be self-evident, that all projects
are not created equal, that they are endowed by their
creation with uncertain and complex characteristics. That
project teams are most effective when they value Life,
Liberty and the pursuit of Happiness.
Interdependence and
Leadership






Value
Customers
Uncertainty
Individuals
Teams
Context
Decisions
Cultivate
Innovation
Collaboration
Delivery
Embrace
Change
Real Options
Leadership Models
Strategy
It Depends
 Uncertainty: We expect
uncertainty and manage
for it through iterations,
anticipation, and
adaptation.
 Context: We improve
effectiveness and
reliability through
situationally specific
strategies, processes and
practices.
Hurricane Rita
Uncertainty
 We expect uncertainty and manage for it through
iterations, anticipation and adaptation.
Project Differences
Bulls
Uncertainty
Colts
Dogs
Cows
Project Complexity
Project Differences
Uncertainty
High
Colts
Bulls
Simple, young projects.
Need agility
Tight Teams
Agility to handle uncertainty
Process definition to cope
with complexity
Dogs laissez faire
Cows
Complex, mature market
Need defined interfaces
Low
Low
High
Project Complexity
Plenty of Bull
Bull Product Release
Reduce Uncertainty or
Complexity
Uncertainty
Complexity
Attribute
Score
Attribute
Score
Market
███
Team Size
█████████
Technical
███
Mission Critical
█████████
# Customers
█████████
Team Location
█████████
Duration
█████████
Team Maturity
███
Change
███
Domain Gaps
███
Dependencies
█████████
Opportunities to Reduce Uncertainty:
Opportunities to Reduce Complexity:
 Use proven technologies
 Reduce project duration
 Collocate the team
 Break project into sub-projects
Partitioning
Colt
Project
Bull
Program
Dog
Project
Cow
Project
Remember: Loose Coupling and Strong Cohesion
Uncertainty
Colts
Dogs
Bulls
Cows
Project Complexity
Bull Program, Dog Project
First Integration Release
Colts
Bulls
New acquisitions
The Integration Release
Uncertainty
High
Dogs Existing Products
Cows
Integration data model
Low
Low
High
Project Complexity
Integrating Software by
Integrating People
Creating the Future
Friday@4 Weekly
PMM Quarterly
Developers’
Conference Yearly
Y2K Release
Colts
Bulls
None
None
Uncertainty
High
Dogs All Products
Cows
The overall Program
Low
Low
High
Project Complexity
Products Lifecycle Paths
Product Lifecycle
Uncertainty
High
C
Colts
A
Low
Low
Bulls
Skunks
B
Dog
s
Complexity
Cows
High
Project Leadership Guide
Create
Change
High
Deploy
Market
Differentiating
Invent
Ad Hoc
Eliminate
Change
Offload
Low
Embrace
Change
Outsource
Low
Agile
Control
Change
Manage
Structured
Mission Critical
High
Portfolio Management
RAPID Quadrant Assessment
12.0
Uncertainty
Uncertainty
10.0
8.0
6.0
4.0
2.0
0.0
0.0
5.0
10.0
15.0
20.0
Project Complexity
Project Complexity
25.0
30.0
Leadership Development
People
Business
Process
Technology
Leadership Development
Uncertainty
High
Colts
Bulls
Business
& Technology
Dogs
Low
Cows
People
& Process
Low
High
Project Complexity
Leadership Development
People
Process
Technology
Business
Read
Read
Read
Read
Read
Read
Write
Write
Write
Write
Read
Read
Delete
Write
Write
Write
Not all dogs are the same
Great Leadership
 Create a place where people want to be
not have to be
 Make sure everyone has what they need
to succeed.
Agile Leadership
Contact
Todd Little
 [email protected]
 www.toddlittleweb.com
 www.accelinnova.com
Stand Back and Deliver, Pixton,
Nickoliasen, Little, and McDonald,
published by Addison Wesley, due out in
early 2009
Cultivate Innovation
Business Value
Collaboration
Project Governance
Real Options
Embrace Change
Frameworks Model
Strategy
Stand Back and Deliver
Your Questions?
Waterfall has context too!
 Small Waterfalls
Waterfall has context too!
 Medium
Waterfall has context too!
 Face Gate
Waterfall has context too!
 Glacial
Waterfall has context too!
 Bring in the Gurus
Penal Management
Institute
Now that I am a Penal
Management Professional I
can show them how to
improve these Convicts’
Maturity Model
Business Process Value
Chain Interdependence
Market
Product
Development
Sales
Product
Company
Specifications
Development
Delivery
Contract
Model
Development
Delivery
Internal
IT
Business Need
Overall process flow
Iterations
Inputs
Outputs
Adaptive Activities
Preconditions
Postconditions
•Released
Software
CORE Activities
Project
Sanction
RTM
Core Practices






Aggregate Product Plan
A/B/C List
Quality Agreement
Continuous Integration
Expert User Involvement
Project Dashboard
The Aggregate Product Plan sets the high
level vision and expectations
Project: OpenWells Davenport
Product: OpenWells
Project Code: 010265
Target Date: 3/30/2004
Version: 2003.11.0.0
Release Date: 3/31/2004
Product Manager: Marcus Ridgway
SDD: David Field
Vision:
Version 2.0 of Well Operations reporting and data
analysis application. Will bring powerful new query,
graphing and reporting capabilities. Comprehensive
D&WS input data and output reports will be
supported including integration to Production suite.
Platforms:
Windows 2000 /Oracle
8.1.7
Windows XP / Oracle 9i
Windows 2000 & XP
/MSDE
Features:
18 additional reports
Addtnl apps - Data Anlyzr, NG Profile, Autoprint
Extended Rig Equipment support
Knowledge Management - Technical limit drilling,
lessons learned, non-productive time, and
equipment failures
Application enhancements (spreadsheet support and
tailored well services tab and others)
Strategic Fit:
Integration
Workflow ( Prototype, plan, actual)
Top quartile technology
Target Markets:
Existing DIMS customers
US Independents
NOCs
Government and
regulatory organizations
Companies requiring
integrated offering
w/decent wellbore
schematic requirements
Service companies
The A/B/C List sets proper
expectations
A
MUST be completed in order to ship the product.
B
SHOULD be completed in order to ship the
product.
C
MAY be completed prior to shipping the product
if time allows.
Only “A” features may be committed to customers.
“A” features must fit in a p90 confidence schedule. No more
than 50% of the planned effort can be allocated to “A” items
A/B/C List
50%
25%
25%
B
C D
A
Typical Delivery
1.2
1
0.8
0.6
A
B
Backlog Plan
C
0.4
0.2
50%
Target
Delivery Date
D
ec
em
be
r
r
em
be
N
ov
ct
O
m
be
te
Se
p
100%
ob
er
r
t
us
Au
g
ly
Ju
Ju
ne
ay
M
il
Ap
r
ar
ch
M
ry
ua
Fe
br
Ja
nu
ar
y
0
A/B/C List
50%
25%
25%
A B
Uncertainty Risk
C D
1.2
1
0.8
0.6
A
B
Backlog Plan
C
0.4
0.2
50%
Target
Delivery Date
D
ec
em
be
r
r
em
be
N
ov
ct
O
m
be
te
Se
p
100%
ob
er
r
t
us
Au
g
ly
Ju
Ju
ne
ay
M
il
Ap
r
ar
ch
M
ry
ua
Fe
br
Ja
nu
ar
y
0
A/B/C List
Oxbridge - P&E Systems Requirements
ARIES
#
1
2
Rank Name
A Honor common login
A
Certify against old data model
3
B
User group requests
4
B
Fill RMS functionality gaps
5
C
Fill RMS functionality gaps
6
C
User group requests
7
C
User group requests
Notes/Purpose/Description
Recognize and support the EDM common login information
Formally test the new ARIES product against the old ARIES database. If
successful, this will ease the transition by giving customers flexibility and
enabling them to easily evaluate acquisition databases
Improve decline calculations to a reserve limit when using hyp/exp
switchover
Provide multi-level approval and freeze process. Allowing multiple sets of
reserve values.
Current reconciliation is by EIA or SEC change codes. Need ability for more
detail and or user defined arrangements.
START date with option for a variable DELAY/SHIFT period (number of
months) including use with ENDDATE
Expand range in which we solve for an unknown decline rate in a hyperbolic
equation
Estimates
P10 P50 P90 T-Shirt
5
10 20 M
10
20
40
L
15
30
60
L
30
60
120 XL
35
70
140 XL
5
10
20
M
5
10
20
M
We use a Quality Agreement
similar to Thomsett
Attribute
“A”
Very
Important
“B”
Important
X
Completeness of Functionality
Completeness of Testing
X
Reliability
X
X
Performance
Installation
X
X
Usability
Integration
X
X
On Line Help
Training
“C”
Not Very
Important
X
Product Innovation Flow
Hot Items
Product
Backlog
Release
Backlog
A
Items
Items
Idea Filter
Sales
Adaptive Activities
Services
RTM
B&C
Project Sanction
Iteration
Backlog
Newly Discovered
Flexible Scope
Backlog
CORE Activities
Most Items for consideration in next release
Backlog
Burnup
B/C/D
A
Customer
Support
From the home office in
Duncan, Oklahoma Dubai, UAE
Top Ten reasons why we are late
in 2008
Top Ten reasons why we
are late in 2008
10: Requirements, what Requirements?
What you want, baby I
got it
R-E-Q-U-I-R-E
Find out what it
means to me
Top Ten reasons why we
are late in 2008
9: Dependencies on other groups that were late
Top Ten reasons why we
are late in 2008
8: Over-optimistic Schedule Estimation
Always look on the bright side of code
.......
Always look on the bright side of code
.......
The code’s a piece of $#!^,
when we look at it
We can always overlook a minor kink . . .
It probably compiles, it might even link . .
Surely that must mean it doesn’t stink
Top Ten reasons why we
are late in 2008
7: Those weren’t MY estimates
Scheduling Ritual
How low can you go!
Top Ten reasons why we
are late in 2008
6: Not enough testers or documentation
resources.
Who needs them anyway? We
put those bugs--I mean features-in there on purpose. Besides, it
was difficult to program, it should
be difficult to use.
Top Ten reasons why we
are late in 2008
5: Offshore and Outsourcing issues
My source code lies over the ocean,
My source code lies over the sea .
My source code lies over the ocean,
Oh bring back my source code to me
.....
Bring Back, Bring Back,
oh bring back my source code to me, to me
Bring Back, Bring Back,
oh bring back my source code to me
Top Ten reasons why we are
late in 2008
4: One word, Ch-ch-ch-changes
Top Ten reasons why we
are late in 2008
3: I can’t get no, System Admin





I can’t get no, CM action
‘cause I try,
..and I try,
….and I try,
……and I try….
Top Ten reasons why we
are late in 2008
2: You didn’t give me the headcount
that you promised
Top Ten reasons why we
are late in 2008
1: Weren’t you doing the backups!?