v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Funding Agile Delivery
@ScrumDotOrg
Bringing Agile Techniques to Portfolio Management
2
Kurt Bittner kurt.bittner@Scrum.org
@ksbittner
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 3
Traditional Funding Model Challenges
"You can never change things by fighting reality. To
change something, build a new model that makes
the existing model obsolete.”
~ R. Buckminster Fuller
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Some questions to consider:
• Can you finish a project on-time and on-budget and still be
unsuccessful?
• How do you decide what to fund when opportunities arrive
continuously?
• What’s more valuable: Increasing conversion by 10% or
adding a new feature?
• How do you know whether a feature is valuable?
4
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
How The
Traditional
Funding
Approach Falls
Short
5
Opportunities arise continuously, not just in
annual cycles
• Why commit to more work than can be currently
worked on?
• Annual funding ties up funding and capacity that
may be better applied when better opportunities
arise
Principle
Delay funding decisions as long as possible
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
How The
Traditional
Funding
Approach Falls
Short
6
Funds work in large, hard-to-control increments
• Discourages experimentation
• Increases risk
• Hard to measure results
• Encourages too much WIP
Principle
Reduce funding increment to reduce risk
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
How The
Traditional
Funding
Approach Falls
Short
7
Plans are often based on unvalidated
assumptions:
• About what problem is being solved
• About the benefits of solving that problem
• About what features will really deliver value to
customers
Principle
Reduce funding increment to improve time-to-
market and time-to-feedback
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
8
Decision-making in an uncertain world
Source: Stacey RD. Strategic
Management and Organizational
Dynamics: The Challenge of Complexity.
3rd ed. Harlow: Prentice Hall, 2002.
Agile delivery practices
help here
Traditional
delivery
practices fit
here
http://blog.agilistic.nl/on-complexity-why-your-software-project-needs-scrum/
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
A big risk: some requirements are wrong, but which ones?
“Only one third of the ideas
tested on the Experimentation
Platform at Microsoft improved
the metric(s) they were designed
to improve (Kohavi, Crook and
Longbotham 2009).”
“at Google, only about 10
percent of these [controlled
experiments, were] leading to
business changes.” (Manzi
2012)
“80% of the time we are wrong about what
a customer wants.” (Kaushik 2006)
“It's been humbling to realize how rare it is
for [features] to succeed on the first
attempt.” (McKinley 2013)
Source: http://www.exp-platform.com/Documents/2015%20Online%20Controlled%20Experiments_EncyclopediaOfMLDM.pdf
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 10
https://www.cnet.com/news/fire-phone-one-year-later-why-amazons-smartphone-flamed-out/
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
First Lesson: Beware of HiPPOs
11
https://s-media-cache-ak0.pinimg.com/originals/67/f3/05/67f3053febdf5048ef696e87537c9e55.jpg
Highly Paid Person’s Opinions
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Managing Output
Maximizes things produced
(more = better)
12
Second Lesson: You get what you measure
Managing Outcomes
Maximizes results
(improved customer
outcomes)
Which is better?
The challenge: measure and reward
outcomes, not output
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
3 Innovation Horizons
13
Horizon 3
Envision, Explore
Horizon 2
Exploit, Scale
Horizon 1
Sustain, Retire
1 year 5 years
Paul Hobcraft (2010), building on The Alchemy of Growth, by Baghai, Coley, & White, 1999
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 14
“Good judgment comes from
experience, most of which comes from
bad judgment.”
- anonymous
Horizon 1
Priority: Sustain Revenue
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Horizon 1: Sustain, Retire
15
1 year 5 years
60% of portfolio
Critical questions
• “Is the business large enough
and profitable enough?”
• “Is it growing?”
• “Will additional investment
drive growth and
profitability?”
• “What needs to be done to
protect or support the
business?”
• “Can investment be scaled-
back?”
• “Are there any unmet
customer outcomes?”
Critical measures
• Revenue
• Profitability
• Growth
• Efficiency
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Fund Product Teams Based on Revenues
13%
6%
13% 14% 15%
• When Product has sustained
revenue and customers
• When Team is stable and
proven
• When the organization trusts
the Product Owner and the
Development Team to make
the right product decisions
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 17
Horizon 3
Priority: Invest in Innovation
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 18
Horizon 3: Envision, Explore
1 year 5 years
10% of portfolio
Critical questions
• “What are the unmet
customer outcomes?”
• “Can we create
solutions that will
improve outcomes?”
• “Can we create
solutions that
customers will love?”
Critical measures
• Improvements in customer
satisfaction gaps
• Not concerned with
profitability, yet.
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Goals
• Quickly evaluate the value of new ideas using
empirical data
• Better understand opportunities
• Reap benefits of new ideas quickly
• Reduce amount spent on things that yield poor
results
Benefits
• Reduce WIP
• Reduce waste from building the wrong solution
• Eliminate over-funding
• Eliminate “use or lose it” spending
Funding
Innovation
Using An
Outcome-
based
Approach
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 20
Inspect and Adapt Applied to Software
Understand
Desired
Outcomes
Evaluate
Possible
Solutions
Build at
least part
of it
Deploy,
measure
Identify an
Opportunity
Continue until happy
1
2
3
4
5
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
What makes a successful product?
21
Is it
Valuable?
Is it
Usable?
Is it
Feasible?
Developer
UxBusiness
source: Jeff Patton, User Story Mapping, page 156+
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Funding Innovation
Opportunities
Size
Value
Explore
Alternative
Solutions
(Scrum)
Evaluate
Alternative(s)
Deliver
Incremental
Solution
(Scrum)
∆ Business
Outcomes
Feedback
Market
Research, VoC,
Observation, etc.
Fund
Exploration
Funded
Alternative
Viable
Alternative(s)
No Viable Alternatives
Re-prioritize
Opportunity
Product
Backlog
Rejected
Alternatives
Opportunity
Backlog
Satisfaction
Gap
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
23
Opportunity
Backlog
an outcome-based roadmap of
things that might improve
business results
Leaders communicate strategy & set priorities by
ordering the Opportunity Backlog
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 24
Persona-based Opportunity Sizing
Current Experience
Desired Outcome
Satisfaction
Gap
Opportunity
=
Value of Closing
Satisfaction Gap
Persona Another technique: Empathy Mapping
https://www.uxpin.com/studio/blog/the-practical-guide-to-empathy-maps-creating-a-10-minute-
persona/
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Sizing Opportunities – Three Questions
Do
Reasonable
Alternatives
for Closing the
Gap Exist?
What’s the
Value of
Closing the
Gap?
What’s the
Gap Between
Current and
Desired
States?
Ways to identify
opportunities
• Marketing data
• Survey data
• Customer feedback
• Direct Observation
• Interviews
• Instrumented
Application data
Ways to identify
alternatives:
• Mock-ups and focus
groups
• Educated hypotheses
about possible
solutions
• Design Thinking
Ways to value improved outcomes:
• Focus groups and Surveys to understand
how much people will pay for improved
outcome
• Market data to estimate number of people who
would be willing to pay for improved outcome
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 26
Opportunity Size
=
[#People Matching Persona]
(market size)
x
[Their Perceived Value of Closing Satisfaction Gap]
(benefit of closing gap)
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 27
Fund Releases or Teams?
Low
Trust, Risk
(based on track record)
Team Autonomy
High
Low High
Fund Releases Fund Releases
Fund Teams
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Exploring Alternative Solutions Balances Two Aspects
Who Explores Alternatives?
• Cross-functional team (Business, Technical, Marketing, Business Operations, IT Ops, …)
• Ideally the same team who will build it
Explore
Alternative
Solutions
(Scrum)
Exploratory
Funding
Viable
Alternative(s)
Technical Feasibility
• Can solution close satisfaction gap?
• Can it be built? What skills and
resources are needed?
Business Viability
• TCO/lifetime cost target threshold (cost
envelope)
• Time to market window
• Is the problem worth solving?
Apply Design Thinking
practices...
... But Also
Build Working Software!
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
The “Design Squiggle”
30
http://cargocollective.com/central/The-Design-Squiggle
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Example: Apple iPhone design evolutions
31http://www.cultofmac.com/181782/every-iphone-prototype-apple-ever-made-before-released-the-first-iphone-gallery/
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Funding Incremental Solutions – Just Enough To Validate
Fund
Incremental
Solution
Funded
Increment
Viable
Alternative(s)
• The size of the Opportunity
• The value of closing the Satisfaction Gap
• The technical feasibility of the solution
• Whether the solution can be delivered within the
“cost envelope”
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 33
How Certain Do You Need To Be?
Adapted from Lean UX: Designing Great Products with Agile T
Low
High
interviews
Paperprototypes
Prototypewithlivedata
A|Btests
Datafromactualuse
lunch
vacation
car
retirement
Size of
“bet”
Amount of evidence
Stakeholderreviews
house
Constable’s “Truth Curve”
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
What’s the smallest funding increment?
What’s the smallest releasable increment?
Satisfaction
Gap
One Persona One Outcome
“Minimum Marketable Capability”
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Deliver Incremental Solutions Using Scrum
Deliver
Incremental
Solution
(Scrum)
Changed Business
Outcomes,
Customer
Feedback
Ideas
Size
Opportunity
Rapidly deliver solutions in small increments, then
Inspect and Adapt
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 36
“Whether you think you can, or you think you
can’t, you’re right”
- Henry Ford
Horizon 2
Priority: Grow Revenue
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Horizon 2: Exploit, Scale
37
1 year 5 years
30% of portfolio
Critical questions
• “Can the business be
profitable, and how
much?”
• “Is business
worthwhile? Is it
sustainable?”
• “Can the business
scale?”
Critical measures
• Growing market share
• Potential for market
leadership
• Potential for profitability
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Moving from
Horizon 3
(experimentatio
n) to Horizon 2
(productization
)
At what point do you create a product and fund a
team? Typically:
38
• Market proven
• Solution proven
• Sustainable revenues
• Stable team (including Product Owner)
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 39
Closing
“A man who carries a cat by the tail learns
something he can learn in no other way.”
- Mark Twain
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
“Inspect and Adapt” each opportunity:
• For new products and new markets
• When the competitive landscape has dramatically
changed
• When requirements or technology uncertainty are
high
• When teams or delivery approaches are unproven
Fund teams and let them “Inspect and Adapt”:
• When revenues, markets, and customers are stable
• When teams and delivery approaches are proven
• When competitive risk is low
Choosing
Which Funding
Model To Use
Depends on
Risk and
Uncertainty
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Recommended Reading
41
Also check out Beyond Budgeting at http://bbrt.org
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Recommended Reading (2)
42
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Recommended Reading (3)
43
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved 44
Recommended Reading (4)
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Questions?
v 3.4 © 1993 – 2017 Scrum.org All Rights Reserved
Thank You!
47

Funding model technorama antwerp - may 2017 copy

  • 1.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved
  • 2.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Funding Agile Delivery @ScrumDotOrg Bringing Agile Techniques to Portfolio Management 2 Kurt Bittner kurt.bittner@Scrum.org @ksbittner
  • 3.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 3 Traditional Funding Model Challenges "You can never change things by fighting reality. To change something, build a new model that makes the existing model obsolete.” ~ R. Buckminster Fuller
  • 4.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Some questions to consider: • Can you finish a project on-time and on-budget and still be unsuccessful? • How do you decide what to fund when opportunities arrive continuously? • What’s more valuable: Increasing conversion by 10% or adding a new feature? • How do you know whether a feature is valuable? 4
  • 5.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved How The Traditional Funding Approach Falls Short 5 Opportunities arise continuously, not just in annual cycles • Why commit to more work than can be currently worked on? • Annual funding ties up funding and capacity that may be better applied when better opportunities arise Principle Delay funding decisions as long as possible
  • 6.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved How The Traditional Funding Approach Falls Short 6 Funds work in large, hard-to-control increments • Discourages experimentation • Increases risk • Hard to measure results • Encourages too much WIP Principle Reduce funding increment to reduce risk
  • 7.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved How The Traditional Funding Approach Falls Short 7 Plans are often based on unvalidated assumptions: • About what problem is being solved • About the benefits of solving that problem • About what features will really deliver value to customers Principle Reduce funding increment to improve time-to- market and time-to-feedback
  • 8.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 8 Decision-making in an uncertain world Source: Stacey RD. Strategic Management and Organizational Dynamics: The Challenge of Complexity. 3rd ed. Harlow: Prentice Hall, 2002. Agile delivery practices help here Traditional delivery practices fit here http://blog.agilistic.nl/on-complexity-why-your-software-project-needs-scrum/
  • 9.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved A big risk: some requirements are wrong, but which ones? “Only one third of the ideas tested on the Experimentation Platform at Microsoft improved the metric(s) they were designed to improve (Kohavi, Crook and Longbotham 2009).” “at Google, only about 10 percent of these [controlled experiments, were] leading to business changes.” (Manzi 2012) “80% of the time we are wrong about what a customer wants.” (Kaushik 2006) “It's been humbling to realize how rare it is for [features] to succeed on the first attempt.” (McKinley 2013) Source: http://www.exp-platform.com/Documents/2015%20Online%20Controlled%20Experiments_EncyclopediaOfMLDM.pdf
  • 10.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 10 https://www.cnet.com/news/fire-phone-one-year-later-why-amazons-smartphone-flamed-out/
  • 11.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved First Lesson: Beware of HiPPOs 11 https://s-media-cache-ak0.pinimg.com/originals/67/f3/05/67f3053febdf5048ef696e87537c9e55.jpg Highly Paid Person’s Opinions
  • 12.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Managing Output Maximizes things produced (more = better) 12 Second Lesson: You get what you measure Managing Outcomes Maximizes results (improved customer outcomes) Which is better? The challenge: measure and reward outcomes, not output
  • 13.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 3 Innovation Horizons 13 Horizon 3 Envision, Explore Horizon 2 Exploit, Scale Horizon 1 Sustain, Retire 1 year 5 years Paul Hobcraft (2010), building on The Alchemy of Growth, by Baghai, Coley, & White, 1999
  • 14.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 14 “Good judgment comes from experience, most of which comes from bad judgment.” - anonymous Horizon 1 Priority: Sustain Revenue
  • 15.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Horizon 1: Sustain, Retire 15 1 year 5 years 60% of portfolio Critical questions • “Is the business large enough and profitable enough?” • “Is it growing?” • “Will additional investment drive growth and profitability?” • “What needs to be done to protect or support the business?” • “Can investment be scaled- back?” • “Are there any unmet customer outcomes?” Critical measures • Revenue • Profitability • Growth • Efficiency
  • 16.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Fund Product Teams Based on Revenues 13% 6% 13% 14% 15% • When Product has sustained revenue and customers • When Team is stable and proven • When the organization trusts the Product Owner and the Development Team to make the right product decisions
  • 17.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 17 Horizon 3 Priority: Invest in Innovation
  • 18.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 18 Horizon 3: Envision, Explore 1 year 5 years 10% of portfolio Critical questions • “What are the unmet customer outcomes?” • “Can we create solutions that will improve outcomes?” • “Can we create solutions that customers will love?” Critical measures • Improvements in customer satisfaction gaps • Not concerned with profitability, yet.
  • 19.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Goals • Quickly evaluate the value of new ideas using empirical data • Better understand opportunities • Reap benefits of new ideas quickly • Reduce amount spent on things that yield poor results Benefits • Reduce WIP • Reduce waste from building the wrong solution • Eliminate over-funding • Eliminate “use or lose it” spending Funding Innovation Using An Outcome- based Approach
  • 20.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 20 Inspect and Adapt Applied to Software Understand Desired Outcomes Evaluate Possible Solutions Build at least part of it Deploy, measure Identify an Opportunity Continue until happy 1 2 3 4 5
  • 21.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved What makes a successful product? 21 Is it Valuable? Is it Usable? Is it Feasible? Developer UxBusiness source: Jeff Patton, User Story Mapping, page 156+
  • 22.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Funding Innovation Opportunities Size Value Explore Alternative Solutions (Scrum) Evaluate Alternative(s) Deliver Incremental Solution (Scrum) ∆ Business Outcomes Feedback Market Research, VoC, Observation, etc. Fund Exploration Funded Alternative Viable Alternative(s) No Viable Alternatives Re-prioritize Opportunity Product Backlog Rejected Alternatives Opportunity Backlog Satisfaction Gap
  • 23.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 23 Opportunity Backlog an outcome-based roadmap of things that might improve business results Leaders communicate strategy & set priorities by ordering the Opportunity Backlog
  • 24.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 24 Persona-based Opportunity Sizing Current Experience Desired Outcome Satisfaction Gap Opportunity = Value of Closing Satisfaction Gap Persona Another technique: Empathy Mapping https://www.uxpin.com/studio/blog/the-practical-guide-to-empathy-maps-creating-a-10-minute- persona/
  • 25.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Sizing Opportunities – Three Questions Do Reasonable Alternatives for Closing the Gap Exist? What’s the Value of Closing the Gap? What’s the Gap Between Current and Desired States? Ways to identify opportunities • Marketing data • Survey data • Customer feedback • Direct Observation • Interviews • Instrumented Application data Ways to identify alternatives: • Mock-ups and focus groups • Educated hypotheses about possible solutions • Design Thinking Ways to value improved outcomes: • Focus groups and Surveys to understand how much people will pay for improved outcome • Market data to estimate number of people who would be willing to pay for improved outcome
  • 26.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 26 Opportunity Size = [#People Matching Persona] (market size) x [Their Perceived Value of Closing Satisfaction Gap] (benefit of closing gap)
  • 27.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 27 Fund Releases or Teams? Low Trust, Risk (based on track record) Team Autonomy High Low High Fund Releases Fund Releases Fund Teams
  • 28.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Exploring Alternative Solutions Balances Two Aspects Who Explores Alternatives? • Cross-functional team (Business, Technical, Marketing, Business Operations, IT Ops, …) • Ideally the same team who will build it Explore Alternative Solutions (Scrum) Exploratory Funding Viable Alternative(s) Technical Feasibility • Can solution close satisfaction gap? • Can it be built? What skills and resources are needed? Business Viability • TCO/lifetime cost target threshold (cost envelope) • Time to market window • Is the problem worth solving? Apply Design Thinking practices... ... But Also Build Working Software!
  • 29.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved The “Design Squiggle” 30 http://cargocollective.com/central/The-Design-Squiggle
  • 30.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Example: Apple iPhone design evolutions 31http://www.cultofmac.com/181782/every-iphone-prototype-apple-ever-made-before-released-the-first-iphone-gallery/
  • 31.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Funding Incremental Solutions – Just Enough To Validate Fund Incremental Solution Funded Increment Viable Alternative(s) • The size of the Opportunity • The value of closing the Satisfaction Gap • The technical feasibility of the solution • Whether the solution can be delivered within the “cost envelope”
  • 32.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 33 How Certain Do You Need To Be? Adapted from Lean UX: Designing Great Products with Agile T Low High interviews Paperprototypes Prototypewithlivedata A|Btests Datafromactualuse lunch vacation car retirement Size of “bet” Amount of evidence Stakeholderreviews house Constable’s “Truth Curve”
  • 33.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved What’s the smallest funding increment? What’s the smallest releasable increment? Satisfaction Gap One Persona One Outcome “Minimum Marketable Capability”
  • 34.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Deliver Incremental Solutions Using Scrum Deliver Incremental Solution (Scrum) Changed Business Outcomes, Customer Feedback Ideas Size Opportunity Rapidly deliver solutions in small increments, then Inspect and Adapt
  • 35.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 36 “Whether you think you can, or you think you can’t, you’re right” - Henry Ford Horizon 2 Priority: Grow Revenue
  • 36.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Horizon 2: Exploit, Scale 37 1 year 5 years 30% of portfolio Critical questions • “Can the business be profitable, and how much?” • “Is business worthwhile? Is it sustainable?” • “Can the business scale?” Critical measures • Growing market share • Potential for market leadership • Potential for profitability
  • 37.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Moving from Horizon 3 (experimentatio n) to Horizon 2 (productization ) At what point do you create a product and fund a team? Typically: 38 • Market proven • Solution proven • Sustainable revenues • Stable team (including Product Owner)
  • 38.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 39 Closing “A man who carries a cat by the tail learns something he can learn in no other way.” - Mark Twain
  • 39.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved “Inspect and Adapt” each opportunity: • For new products and new markets • When the competitive landscape has dramatically changed • When requirements or technology uncertainty are high • When teams or delivery approaches are unproven Fund teams and let them “Inspect and Adapt”: • When revenues, markets, and customers are stable • When teams and delivery approaches are proven • When competitive risk is low Choosing Which Funding Model To Use Depends on Risk and Uncertainty
  • 40.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Recommended Reading 41 Also check out Beyond Budgeting at http://bbrt.org
  • 41.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Recommended Reading (2) 42
  • 42.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Recommended Reading (3) 43
  • 43.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved 44 Recommended Reading (4)
  • 44.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Questions?
  • 45.
    v 3.4 ©1993 – 2017 Scrum.org All Rights Reserved Thank You! 47

Editor's Notes

  • #9 Some of the sources of complexity: Communication styles & skills Mandate and support within the organization Skill-level of the team(s) A clear goal and/or vision Technical skill of developers Number of people involved Organizational culture Knowledge-sharing Process Accessibility of stake- and shareholders Involvement of the customer and/or end-users Tools Volatility of the market Time-management skills Flow Motivation Temporal factors (like how long will the project run) Existing codebase (quality, size, knowledge) Relationship with suppliers of important components
  • #14 See “The Three Horizons – Providing a Common Language in its Innovation Use”, Paul Hobcraft, http://bit.ly/1IZeDXN
  • #40 Examples of companies who use this sort of approach: Intuit, Pearson, Autotrader UK, …