© Joseph Little 2013
MORE BUSINESS VALUE NOW“Transforming the World of Work”
1
© Joe Little 2013
Joe Little, CST & MBA
• Agile Coach & Trainer (CST)• 20+ years in senior level consulting to well-known firms in New York, London and
Charlotte, and elsewhere.• Focus on delivery of Business Value; interest in Lean • CST (CSP, CSM); MBA• Was Senior Manager in Big 6 consulting• Head of Kitty Hawk Consulting, Inc. since 1991• Head of LeanAgileTraining.com• Started trying to do [Agile] before reading The Mythical Man-Month
– http://agileconsortium.blogspot.com
2
© Joseph Little 2013
Basics
3
© Joe Little 2013
Key Issue
4
Having better lives (the good life)
Smaller version: Getting more from Scrum.
© Joe Little 2013
Would it be good to have more Business Value?
5
© Joe Little 2013
What’s in it for you? (Scrum)
More business value for the firmMore for the customers
More, cheaper, faster, betterFaster delivery (TTM)Better way to work (for the workers)More funIt just makes sense
6
© Joe Little 2013
If you are a Team member...
If you deliver more real business value, your life has a higher purpose....
You have done something for another person(s). This is a wonderful thing.
7
© Joe Little 2013
What is the problem?
We are not delivering enough Business Value.
Large success does happen often...why not much more often??
And a larger success more often...
8
© Joe Little 2013
Put another way
We need more...InnovationInventivenessCreativityBeauty
WOW factorSex appealNeat, cool, wonderful solutions to hard technical and business problems
9
© Joe Little 2013
Per Tom DeMarco
Project A will eventually cost about $1 million and will produce value of about $1.1 million
Project B will eventually cost about $1 million and will produce value of about $50 million.
What do we learn from this?
See: “Software Engineering: An idea whose time has come and gone”, by Tom DeMarco
10
© Joseph Little 2013
What we do now in Scrum
11
© Joe Little 2013
What does Scrum do ‘out of the box’ to get more business value?
1. Business and Technology collaborate2. We have a Product Owner for each Team3. We have a ‘prioritized’ Product Backlog4. Ordered mainly by Business Value5. Each sprint we have working product (per the
DOD)6. Each demo, we show the working product to
‘business stakeholders’ and get their feedbackAs in: ‘Did we build the best possible stuff for you this Sprint?’
7. We release earlier12
© Joe Little 2013
But we can do more...
13
© Joe Little 2013
What else can we do?
In small teams, with stickies. And large pens. One items per sticky...
What are some concrete things we could start doing tomorrow that could raise BV?
You have 2 minutes. The Team with the most stickies wins....
14
© Joseph Little 2013
3 More Ideas
15
© Joe Little 2013
The 3 ideas
16
Business Value Engineering
Priority Poker
The Pareto Idea
© Joe Little 2013
Business Value Engineering
A framework for continuously improving how you deliver more and more business value.
Steals from Value Stream Mapping (Lean)
Steals from Deming (Plan-Do-Check-Act)
Uses ideas similar to the scientific method
17
© Joe Little 2013
Priority Poker
Similar to Planning Poker, which you know and love
Puts BV Points on each fricken user story
Done as a Team
‘It’s the conversations, stupid.’
18
© Joe Little 2013
The Pareto Idea
We know this as the 80-20 rule...although not well enough.
Wilfredo Pareto: The ‘vital few’
Sifting to separate...The gold, platinum, diamonds
The silver and copperThe dirt (even the dirt gives a decent return)
19
© Joe Little 2013
Ummm...
These 3 ideas could be done separately....
OR...
They could be done together...
20
© Joseph Little 2013
Business Value Engineering
21
© Joe Little 2013
Business Value Engineering
A framework for continuously improving how you deliver more and more business value.
Steals from Value Stream Mapping (Lean)
Steals from Deming (Plan-Do-Check-Act)
Uses ideas similar to the scientific method
22
© Joe Little 2013
The two essential questions
How do we get the BV ideas and the requirements into the Team?
How do we deliver the ‘product’ to the customer?
23
© Joe Little 2013
The BV process is visible and we articulate the underlying
Do you understand yours, end-to-end?
CustomersExternal
&
Internal
The BusinessCustomer facing
people
Internal groups (Firm oriented)
The Team
24
© Joe Little 2013
Hallmarks of good BV Engineering
1. The process is visible and articulated & always improving
2. Failures in BV communication are identified and corrected frequently, quickly
3. There are many theories, and a concerted attempt to prove out each theory
4. There is appropriate dynamism and change5. Business & Technology are partners6. Success is forecast (modeled) and also measured
after the fact7. Human judgment is involved (the numbers are not
a dictator)
25
© Joseph Little 2013
Some good Theories (examples) - 1
The customer will change her mind 20% in 6 months. The customer does not really know what he wants.The customer cannot explain clearly what she wants.The customer only knows it when he sees it.The customer does not want software, just a solution to her problem.The Sales guys can explain some customer wants.
26
© Joseph Little 2013
Good Theories (examples) - 2
We can learn something about BV using better metrics (maybe even money).While we need some documentation, it is also very important to give the Team the Tacit knowledge.The telephone game effect should be minimized. Let’s have real customers come to some demos.
27
© Joseph Little 2013
Good Theories (examples) - 3
Customers disagree. And customers and our shareholders disagree on what is highest BV. We are always separating the diamonds from the dirt. It helps for the Team to understand BV, even the monetary return from the new product. We expect to revise the NPV estimates over time, for many reasons.
28
© Joseph Little 2013
Good Theories (examples) - 4
It is helpful to identify different ‘roles’ for the product. We should optimize delivery ‘end-to-end’.“End-to-end” starts when the customer has an idea, and ends when the customer is successfully using the product (achieving their business value).
29
© Joseph Little 2013
Good Theories (examples) - 5
There are important benefit-cost trade-offs in our work. Only by having Business-Technology as partners, can we make the better trade-offs. Knowledge about these trade-offs evolves over time.Understanding knowledge creation and knowledge decay are key to achieving ever higher business value.
30
© Joseph Little 2013
Good Theories (examples) - 6
Every customer has a high demand for simplicity and speed of delivery. And high quality....even if unstated.Some projects will be cancelled if the benefit-cost ratio declines enough. Every representative of ‘the customers’ is problematic to some degree. We are always looking to reduce the bias.Let’s let the coder talk to some of the end users.Testers must understand business value more.
31
© Joseph Little 2013
Good Theories (examples) - 7
The business value of the (next) release can often change significantly in a month or two. (While we are building it.)Often customers need our help in prioritizing the “requirements” that the diverse people from that firm have given usThe best possible feedback comes after it goes into production. (release sooner)By using working software, we will learn faster how much we are misunderstanding what they really want.
32
© Joseph Little 2013
Good Theories (examples) - 8
Watching a person working if often the best way to identify the real needs.Use cases can be helpful in articulating the requirementsShowing some real users working software frequently can be very useful for learning about requirementsThe customer often does not understand his problem, and is more often far from articulating well the ‘better’ solution for it. (eg, does not understand what is possible)
33
© Joseph Little 2013
Good Theories (examples) - 9
Exogenous variables (war, weather, economic) add more reasons to deliver something smaller faster.No one person at the customer firm ‘knows’ what the customer (firm) wants. We need to re-train some customers to trust us enough to want more frequent releases. And give them the necessary support (eg, for testing).We must have higher quality so that customer testing costs and ‘pain’ reaches an acceptably lower level.
34
© Joseph Little 2013
Some Outputs
A BV ‘process’ map (~30 objects/stickies)A list of underlying theories (~20)An ‘operational’ definition of BV for the next releaseA BV ModelA specific improvement to make (later: approved & work done) Something changesA way(s) of measuring (higher) BV (eg, after the release is in production)A way of evaluating success (later: success evaluated)
35
© Joseph Little 2013
Priority Poker
36
© Joseph Little 2013
What is it?
Priority Poker is very similar to Planning Poker, except it is about Business Value.
Other differences:The reference story is the highest BV one. (Not the lowest effort one.)We use the “5” best “experts” on Business Value.
37
3 roles• Product owner• Scrum master• Team
3 artifacts• Product backlog• Sprint backlog• Sprint burndown
4 activities• Sprint planning• Daily scrum• Sprint review• Retrospective
CSM v9.3 © Jeff Sutherland 1993-2008; © Joe Little 2013
Planning poker cards
http://planningpoker.crisp.se
Source: Henrik Kniberg38
© Joseph Little 2013
What happens?
They select the reference story. BVP=100They choose a story (random) to evaluateThey discussThey vote. Imagine: 2, 20, 20, 20, 40The two extremes talkThe vote again: 13, 20, 20, 20, 40. The average is 23. (Meaning: On average, they feel it is about 23% of the BV of the reference story)They go to the next story
39
© Joseph Little 2013
What is the pupose?
The number of each story card?
OR....
That the 5 ‘experts’ discussed some important issues, and ‘everyone’ now understands BV much better?
40
© Joseph Little 2013
The purpose is...
...that now everyone has shared their (key) tacit knowledge about business value.
...that now everyone has learned.
...that now mostly they see the same elephant (of BV).
41
© Joseph Little 2013
Now...
R = BVP / SP
We can do more work on the Pareto Idea... (up soon)
42
© Joseph Little 2013
Very simple...
...very powerful.
43
© Joseph Little 2013
A word of advice...
If the ‘wrong’ person explains it, they won’t do it
If the ‘right’ person explains it, they do it easily and see the value
Hard to explain why...but that seems to be the truth
44
© Joseph Little 2013
The Pareto Idea
45
© Joseph Little 2013
The Pareto idea
80-20
The vital few
Less is more...
Example: The iPod, not the Zune
46
© Joe Little 2013
Pareto’s Rule (you must prioritize!)
47
0
20
40
60
80
100
1st Quint. 2nd Quint. 3rd Quint. 4th Qunit. 5th Quint.
Pareto Curve
© Joe Little 2013
Pareto said...
You can re-apply the Pareto idea at every level of the population
THUS:
Every time you break down an Epic, part of it is high value, part medium, part low
48
© Joe Little 2013
Advice
Smaller stories!!!!!!
OK?...
Smaller stories!!!
49
© Joe Little 2013
More importantly...
You have been brainwashed, for years, into the 100%-100% rule
And everyone around you has been brainwashed
AND... we are still learning how to sift & see:gold, platinum, diamonds
silver, copperdirt
50
© Joe Little 2013
Advice: Learn to say ‘NO’
...in a nice way
See: The Power of a Positive No, by William Ury
51
© Joe Little 2013
Advice: First do the 85%-50% rule
85% of $3 million is $2,550,000
50% of 12 months is 6 months....
THUS: a 70% improvement with just the 85-50 rule
52
© Joe Little 2013
Advice: Work on it every day
Work on it HARD every day
Every day there is some additional work (feature) you can identify NOT to do in the Release.
Identifying that is hard.
Saying NO is hard.
53
© Joseph Little 2013
Killing Babies or Sizzling Steak
54
© Joe Little 2013
You have finished Release Planning...
55
By Apr 30th!
P.B.
© Joe Little 2013
You have finished Release Planning...
56
By Apr 30th!
P.B.
NO !!!
© Joe Little 2013
“Killing Babies”
I don’t recommend it
57
© Joe Little 2013
Show a Pareto Chart
58
0
20
40
60
80
12
34
5
R Factor
Bar Chart - Stories - Width is SPs
© Joe Little 2013
You have finished Release Planning...
59
By Apr 30th!
P.B.
© Joe Little 2013
Sizzling Steak!
Yes! We have to show the sizzling steak!
60
© Joseph Little 2013
Other basic ideas
61
© Joe Little 2013
Some simple things - 1
62
Benefit-cost analysisLet the coder talk to the real userAgile SpecsAsk the Doers to think about business value frequentlyCreate a BV ModelModify the BV Model once per monthLearn to cancel projects when better projects come along
© Joe Little 2013
Some simple things - 2
Identify & fix more technical debtMake the PO betterGet more PO time for the teamTeach the PO about the productGive the PO time to talk to end users and customersLet the PO watch a master PO Improve the quality of the Agile Specs
63
© Joe Little 2013
Some more simple things - 3
Get more creativeMake the product more elegant or beautifulGet better business stakeholdersMore feedback from the business stakeholdersMore time from the business stakeholdersA better relationship between the business stakeholders and the POBring real end users to the Demo
64
© Joe Little 2013
More simple things - 4
Map the stories (in several possible ways)The Doers should watch what the end users do each dayRe-calculate the BV Model more frequentlyIntegrate more between Team planning and firm planningStudy competitive productsRemove small features from the release (Pareto)Faster feedback within the Sprint (Doers - PO)
65
© Joe Little 2013
More simple things - 5
Have more fun!?!***Ask: “What will delight the customer?”Measure BV delivered (measure after a release)Focus on TTM (time to market). Measure it.Identify the BV drivers specific to your effortClarify the acceptance criteria (functional tests) moreAutomate the functional tests (more)
66
© Joseph Little 2013
Summary
67
© Joe Little 2013
Do these!!!
68
Business value engineering
Priority Poker
Execute on the Pareto Idea
© Joe Little 2013
If you do, you’ll have more fun!
69
Yes, even hard work can be fun, if you do it the right way....
© Joe Little 2013
Thank you.
Please contact me here:
Joseph Littlejhlittle@kittyhawkconsulting.comLeanAgileTraining.comLeanAgileTraining.com/blogTwitter: jhlittleOffice: 704-376-8881Cell: 917-887-1669
70
Top Related