The document discusses the seven deadly sins of enterprise software development and provides advice for overcoming challenges with digital transformation projects. It argues that accurately forecasting the future is impossible when a project involves both complexity and uncertainty. Traditional project management approaches assume one can perfectly predict outcomes, but complexity grows exponentially as more tasks and variables are added. The ability to forecast success decays rapidly as a result. Additionally, customer adoption depends on perceived value, work required, and willingness to change - which are also difficult to predict accurately. Ultimately, the document advises that any complexity or unknowns drives the ability to forecast a project's scope and timeline close to zero.
2. Adopting agile processes is hard. Adopting an agile culture that embraces
change, trusts people to do the right thing and is focused first and foremost on
satisfying the customer instead of arbitrary deadlines is much harder.
2@kevinjmireles www.DontMakeMeWork.com
The cartoon is not an original Dilbert comic but originated from Luca Minudel in 2011
https://www.flickr.com/photos/lucaminudel/6059269914/
3. 3
Can create designs and plans that can be faithfully executed with little
variation from initial specifications, scope and timeliness
Layering Scrum, SAFe and other agile-development methodologies on top of a
waterfall old-school operations-approach to software development works when
traveling well trodden paths with low complexity and few unknowns.
@kevinjmireles www.DontMakeMeWork.com
4. 4
But not when the road ends and you need to figure out how to get to the other
side of the mountains without a map!
@kevinjmireles www.DontMakeMeWork.com
Impossible to accurately define, design and plan when unknowns
exceed knowns
5. 5
Impossible to accurately define, design and plan when unknowns
exceed knowns
As a veteran mountaineer with plenty of project scars, I’ve put together these
slides to help guide you as you scale the enterprise mountains standing in the
way of your digital transformation.
@kevinjmireles www.DontMakeMeWork.com
48. 48
Why do we continually pick designs and continue to plow
money into them when we know they’re not ideal?
Despite adopting agile processes, organizations still have waterfall mindset and
believe:
1. Teams should have been able to design everything correctly up front
2. Experimenting with multiple designs is a waste because you should already
know everything
3. Learning and wisdom can’t be quantified and therefore are not valued
4. Progress should be a straight line measured quantitatively and anything that
veers from that is waste
5. Throwing away work represents failure not learning and good judgement
49. 49
Fear-driven development results in sinking money into
suboptimal designs that ultimately need to be replaced at
3-5X the cost of having experimented early on
StartFast.Limited
investmentinarchitecture&
discovery
Technical & UX debt and risk
being accrued
Incremental costs & time to do it right
Cost of Doing it Wrong
Cost & time to:
1. Develop wrong solution
2. Develop new architecture
3. Rip out and replace old
architecture
4. Rip out and replace dependent
components designed for the
wrong architecture
Opportunity cost of spent mitigating
technical debt vs. delivering value
50. 50
And the more you invest in the wrong thing, the greater
differential between cost & perceived value
Perceived Customer Value Being Delivered
51. 51
Ultimately if the mistakes are embedded into the core
design and foundation, they may prevent you from ever
achieving your initial goals
52. 52
SAF recommends set-based design to avoid being locked into a
design that may not work but requires leadership to embrace
throwing away work as a good engineering practice not a failure
53. 53
And that doing it right, usually costs more up front
but results in time and cost savings in the long run
54. 54
Set-based design practices provide a framework for
success
Run experiments in parallel
Solve the hardest problems first
Ruthlessly discard what doesn’t work
Keep the knowledge gained
55. 55
Run experiments in parallel
“I have not failed, I’ve just found 10,000 ways that don’t work”
Thomas Edison
56. 56
Solve the hardest problems with the most risk first, not later
We installed the engine,
painted it, polished it, even
turned it on and everything
worked great, until we
tested it under load & the
plane won’t take off, but
doesn’t it look beautiful!
57. 57
Ruthlessly discard what doesn’t work and keep only the
knowledge gained
Thank you! Deadlines
shmeadlines! You’re a
hero, you saved us a
ton of rework & lost
opportunity.
Uh… We won’t hit the deadline but we
learned a lot! By doing destructive
testing & usability research early, we
discovered the initial design won’t
work so we’re tossing it & trying some
new concepts based on our learnings.
58. 58
Ruthlessly discard what doesn’t work and keep only the
knowledge gained
And you people, are
fired for hiding the
truth!
60. 60
Difference between startup agile and enterprise agile is
like the difference between building a custom home and
a skyscraper.
61. 61
Startup agile requires little planning, low risk and can
easily leverage existing infrastructure
Need to answer:
•Is it useful?
•Is it valuable?
•Is it usable?
62. 62
Enterprise agile requires lots of planning, high risk and
often entirely new infrastructure and architectural
approaches to deal with the challenges of scale
Need to answer:
•Is it useful?
•Is it valuable?
•Is it usable?
•Can it scale?
63. 63
Startup agile enables you to deliver value to market
much faster
Great job! That
was a quick win!
64. 64
But good luck scaling
I can’t believe I
fell for the quick
win again!
65. 65
The higher you go, the deeper you need to dig!
But the longer it may take
to deliver the initial value
67. 67
The Pareto Principle says to focus on the 80%, but the
question is which 80%?
• Is it the 80% of your customers?
• Is it the 80% that are the most profitable overall?
• Is it the 80% that have the highest average profit?
68. 68
The Pareto Principle says to focus on the 80%, but the
question is which 80%?
• Or is it the one percent that drives the 60% of
your revenue and 80% of your complexity?
69. 69
The 1% have such vastly different requirements from the
other 99% that trying to transform a system designed for
everyone else is almost impossible
70. 70
Design & Architect for the 1% while delivering for the
80% first.
• Identify the business and scalability requirements
for the largest, most complex customers first
• Deliver simpler solutions that meet the needs
of your less complex customers first that you
can deliver to market sooner while building
more complex solutions for later delivery
71. 71
Or develop entirely different systems to meet the very
different needs
Standard designs &
features for the 99%
Custom solutions for
the 1%
Shared Infrastructure
whenever possible
73. MVP & MVR
• New technology platform/form
factor that initially compliments
existing platform, but may
ultimately replace prior platform.
• Competing against existing
software on older platform &
customer expectations
• Research required as to value of
service on new platform
• Identify best & easiest use cases
for new platform to test
73
If you are an older company, most of the time you are enhancing and
replacing existing systems to take advantage of new technologies and
address competitive threats, not developing entirely new capabilities.
Minimum Viable Product
• Entirely new functionality
leveraging new
technology.
• Competing against other
technologies & companies
• Need to prove that
“product” is valuable to
customers and company
• Start with easiest to solve
for use cases first so can
learn and prove value.
Minimum Viable Replacement
• Primarily existing functionality
being ported to new platform
that replaces old platform
• Competing against your own
existing software
• Minimal research required as
to value of product
• Identify most valuable and
most difficult use cases, and
solve for those first
74. 74
Minimum Viable Product = Hypothesis that a certain
minimum level of functionality is enough to meet a
specific market need
Market segment A
Market segment B
Market segment C
Market segment D
Market segment E
Market segment F
Market segment G
Segment Revenue Opportunity
Simplesttomostcomplex
Smallesttolargest
MVP A
75. MVP G
MVP F
MVP E
MVP D
MVP C
MVP B
75
Minimum Viable Replacement = Sum total of all the
MVPs required to meet all customer needs required to
transition existing customers and retire existing system
Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Customer segment G
Segment Revenue Opportunity
Simplesttomostcomplex
Smallesttolargest
MVP A
76. Minimum Viable Replacement
MVP G
MVP F
MVP E
MVP D
MVP C
MVP B
76
Plus any additional enhancements/ inducements
required to get stakeholders and customers to change
and adopt new systems and processes
MVP A Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Customer segment G
Segment Revenue Opportunity
Simplesttomostcomplex
Smallesttolargest
77. Minimum Viable Replacement
MVP G 1,2,3,4, 5,6,7, 8, etc.
MVP F
MVP E
MVP D
MVP C
MVP B
77
And if individual customers are large enough to have
customer-specific requirements, then an MVP/MVR has
to be developed for each customer.
MVP A Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Customer segment G
Segment Revenue Opportunity
Simplesttomostcomplex
Smallesttolargest
78. Minimum Viable Replacement
MVP G 1,2,3,4, 5,6,7, 8, etc.
MVP F
MVP E
MVP D
MVP C
MVP B
78
The more customizations and changes required by
internal and external stakeholders, the more difficult the
migration will be
MVP A Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Customer segment G
Segment Revenue Opportunity
Simplesttomostcomplex
Smallesttolargest
79. Minimum Viable Replacement
MVP G
MVP F
MVP E
MVP D
MVPC
MVP B
MVP A
79
Of course, since you are dealing with icebergs, you often
have no idea what is required for each MVP
Customer segment A
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Segment Revenue Opportunity
Simplesttomostcomplex
Smallesttolargest
Customer segment G
80. 80
At the same time, you have to balance the desire to
meet your existing customers’ needs with the opportunity
to serve new market segments with different functionality
A Bird in the Hand? Two in the Bush
• Someone is always going to be unhappy, the question is who, what are
the consequences and which tradeoffs are you willing to make?
or
82. 82
Do not confuse your internal desire to declare victory
with the market requirements for a successful product
83. 83
Deadline driven development encourages people to believe
that in market and market ready are the same thing
In Market: Might be an MVP but
not ready for mass market
Market Ready: Actually ready for
mass market
84. 84
Market ready is ultimately determined by our customers and
stakeholders, who may have very different perceptions
depending upon their specific needs & expectations
What is
Productivity?
What is Customer
Experience?
What is
Scalability?
What is
Success?
Success
What is it?
7 7 10
So determine in advance which customers you are really trying
to serve and make sure they are the ones that say your product
is actually market ready
85. 85
So conduct testing early and often with your target users in
order to truly understand whether the product is truly
market ready!