Seven Deadly Sins of Enterprise Software Development & What to do About Them

The seven deadly sins of enterprise software
development and what to do about them
or
Why your digital transformation is so hard and
how to be successful when traditional project
management approaches fail
Kevin J Mireles
©Kevin J Mireles @kevinjmireles 1

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 is much harder.
2©Kevin J Mireles @kevinjmireles

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.
©Kevin J Mireles @kevinjmireles

4
Impossible to accurately define, design and plan when unknowns
exceed knowns
But not when the road ends and you need to figure out how to get to the other
side without a map!

5
Impossible to accurately define, design and plan when unknowns
exceed knowns
Which is why I put this presentation together, to help you, your leadership and
your business partners understand why embracing an agile culture is so critical to
success and what happens when you don’t as you scale the enterprise mountains
standing in the way of your digital transformation

6
Sin #1
The belief in our own omniscience & ability to
accurately forecast the future

7
Are we all knowing gods?

Do we have crystal balls filled with perfect insight?
Roadmaps that tell us how long and how to get there?

Or is what you can see only the tip of the iceberg, with 80% waiting to be
discovered?
9
?

It’s easy to forecast the future when you have simple systems
10
1
2

But simple systems become exponentially evermore complex systems, as each
system connects to other systems
11
10
5
N(N-1)
2

The reality: In an organization as big, old and complex as FedEx it’s impossible to
really understand all the systems, users, implications to accurately forecast the
future
12
2,600 applications and more than 14,000 custom interfaces
Until in large organizations they become so complex that understanding how all
the pieces fit together and being able to identify impacted systems, users and
processes becomes virtually impossible

That complexity is compounded by age as people move on, retire and pass on

14
By creativity & the paper-clip problem of people using your product in ways you
never envisioned, resulting in you discovering new use cases you need to support
that you won’t discover until you try retiring the old system and users revolt

By siloed perspectives with different groups and people only comprehending
their portion of the overall system, solution and challenge, so that unless you
engage everyone you’ll never discover how everything fits together.

By outside forces that drive inevitable requirement changes

And ultimately your customers and users’ acceptance based on their needs,
perceptions, amount of change required by users and their willingness to change
Perceived Work Required = Amount of work, e.g. additional steps, learning, change, etc.
required to adopt
Power, Culture & Personality Factor = The various dynamics that determine someone’s
willingness to try new things, change existing habits/processes
Perceived Value = Benefit customer or users expect to receive, includes expected, initial
& long-term value.

Despite the challenges, traditional project management assumes you can
accurately forecast the future.
18
Project will cost
$1.47M, be
completed Jan. 27,
2019 resulting in
ecstatic customers &
$25M in incremental
revenue

Which is enshrined in the all-knowing Gantt chart
Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1 90%
2 90%
3 90%
4 90%
5 90%
6 90%
7 90%
8 90%
9 90%
10 90%
11 90%
12 90%
13 90%
14 90%
15 90%
16 90%
17 90%
18 90%
19 90%
20 90%
19
Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

But it assumes 100% confidence rates that all the tasks will be completed on time
and with quality
Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1 90%
2 90%
3 90%
4 90%
5 90%
6 90%
7 90%
8 90%
9 90%
10 90%
11 90%
12 90%
13 90%
14 90%
15 90%
16 90%
17 90%
18 90%
19 90%
20 90%
20
Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1 100%
2 100%
3 100%
4 100%
5 100%
6 100%
7 100%
8 100%
9 100%
10 100%
11 100%
12 100%
13 100%
14 100%
15 100%
16 100%
17 100%
18 100%
19 100%
20 100%

In reality, you’d be pretty excited if you had a 90% confidence level that each task
would be completed in the allotted time frame
Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1 90%
2 90%
3 90%
4 90%
5 90%
6 90%
7 90%
8 90%
9 90%
10 90%
11 90%
12 90%
13 90%
14 90%
15 90%
16 90%
17 90%
18 90%
19 90%
20 90%

Unfortunately, even with a 90% confidence rate of completing each task on time
and with quality, the actual overall probability drops to 12% after 20 tasks.
Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1 90%
2 90%
3 90%
4 90%
5 90%
6 90%
7 90%
8 90%
9 90%
10 90%
11 90%
12 90%
13 90%
14 90%
15 90%
16 90%
17 90%
18 90%
19 90%
20 90%
22
Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1 90%
2 81%
3 73%
4 66%
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1 90%
2 81%
3 73%
4 66%
5 59%
6 53%
7 48%
8
9
10
11
12
13
14
15
16
17
18
19
20
Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tasks
1 90%
2 81%
3 73%
4 66%
5 59%
6 53%
7 48%
8 43%
9 39%
10 35%
11 31%
12 28%
13 25%
14 23%
15 21%
16 19%
17 17%
18 15%
19 14%
20 12%

23
The ability to forecast the future decays exponentially making it impossible to
accurately predict outcomes for projects that combine both uncertainty and
complexity
(% Probability of Success for Each Task )^(# of Variables) = Overall Probability of
Success as Initially Planned
(100%)^20 100%
(95%)^20 36%
(90%)^20 12%
(80%)^20 1%
(70%)^20 0%

At the end of PI Planning do not average fist of five confidence rates, multiply
them to get your true probability of success!
24
The same rules of probability impact your forecasting ability when you have
multiple teams working on multiple components required for a feature/EPIC.

Understand that predictability and innovation are inversely related. If innovation
goes up, predictability goes down.
25
Innovation
Predictability
High Innovation
Low
Predictability
Low Innovation
High
Predictability

The probability of successfully executing business-software project within estimated time
& scope can be roughly quantified by multiplying the probability of technical success by
the probability of customer adoption by the number of discrete components.
26
Probability of Technical
Success
X
Probability of Successful
Customer Adoption( )^N
Perceived Work Required = Amount of work, e.g. additional steps, learning, change, etc. required to adopt
Power, Culture & Personality Factor = The various dynamics that determine someone’s willingness to try new
things, change existing habits/processes
Perceived
Value* -
Perceived Work
Required*( +/-
100
) Power, Culture &
Personality Factor*
Customer Adoption =
Perceived Value = Benefit customer or users expect to receive, includes expected, initial & long-term value.
* Expressed as number between -100 & 100
N = Number of discrete project components, e.g. tasks, user stories, features, epics, etc.
The larger than number of variables, lower probability of success
% Confidence
in Team X
% Confidence
in Technology )(Probability of
Technical Success =
% Confidence in Team = % Confidence that the team has the technical skills, resources, cohesion and subject
matter expertise, etc. to successfully deliver a technically sound solution with the available technology
% Confidence in Technology = % Confidence that the technology chosen has the usability, stability, flexibility,
scalability, etc. to meet the project’s requirements

What you’ll see is that any complexity and uncertainty drives your ability to
accurately forecast project scope and timelines to almost zero quickly.
Probability of
Technical Success
X
Customer Adoption( )^N = Overall probability
of project success
100% X 100%
( )^1 = 100%
100% X 80%
( )^1 = 80%
80% X 80%
( )^1 = 60%
80% X 80%
( )^2 = 41%
80% X 80%
( )^3 = 26%
80% X 80%
( )^4 = 17%

Technical Ability Questions: Below are some questions to ask and
probability ranges for determining confidence in team’s technical
ability to execute per their estimate. This is far from complete list.
28
Probability of Accurately Forecasting Success
Low confidence
Probability = 0-40%
Medium Confidence
Probability = 41%-70%
High Confidence
What is the team cohesion &
performance like?
New team. Struggling team.
Some experience.
Together <1 year
Stable high-performing
team
How much experience does the team
have with the technology?
Little to none. New area
software, form factor, etc
Some experience but still
learning
Experts. Done similar
projects previously
How much expertise does the team have
with the overall subject matter?
Little to none. Doesn’t
understand the business.
Some experience but not
experts.
Experts, understand not
only common use cases but
exceptions as well
Are separate IT ecosystems being
merged?
Separate ecosystems with
different data models,
business rules, etc.
Two or more similar
systems being merged
Enhancing existing
functionality
have with the specific existing systems &
processes?
Little to none. Never worked
on app & no documentation
Worked on it but not a
systems expert
Experts. Helped develop
system. Know where are all
the quirks are.
have with the specific users?
Little to none. Many different
types of users
Some familiarity Worked as a user
How much will the changes impact other
systems or other systems impact you?
High. Requires changes to
dozens/unknown #
Small changes No changes
If interacting with other systems, how
much control does team have over the
other systems.
Low. Need to request
assistance from group with
different priorities/
governance
Some. Can shape other
teams’ priorities but still
risks
High control. Complete
control over dependent
systems© Kevin J Mireles

Technology Confidence Questions: Below are some questions to ask
and probability ranges for determining confidence in technology to
execute per their estimate.
29
Low confidence
Probability = 0-40%
Medium Confidence
High Confidence
Is the technology proven?
Never at our company or to
solve similar problems with
similar scale, etc.
Yes, In similar companies or
our organization, but not in
exact same manner
Yes! Standard part of
technology stack
Has the technology been proven to
scale?
Never at our company or to
solve similar problems with
similar scale, etc.
Yes, In similar companies or
our organization, but not in
exact same manner
Absolutely! No issues.
How easy is it to develop for?
Don’t know. Not an easy-to-
develop for/in platform. Lots of
quirks & unintuitive
workarounds
Works reasonably well &
understand quirks.
Easy & developers like
it!
Has the technology been deployed
in a customer-facing manner?
No. Or Don’t know. Yes at other companies. Yes, within our company
Can it be easily customized to meet
our unique use cases?
No. Or Don’t know.
Should be able to but
haven’t fully validated.
Yes.
How stable/bug-free is the
technology?
Not stable. Buggy technology.
Should be fairly reliable but
haven’t deployed in our org.
Stable & bug free.
© Kevin J Mireles

Perceived Value Questions: Below are some questions to ask
and probability ranges for determining perceived value.
30
Low confidence
Probability = 0-40%
Medium Confidence
High Confidence
Does the product match and exceed current
capabilities of existing system critical to
core users?
No. Matches some but not
all functionality. It’s an MVP
not MVR.
Yes. Matches all
existing functionality
Matches & exceeds all
functionality
Are the benefits immediately visible to the
end user?
No. Requires work & or
training to discover
functionality
For the most part, but
requires some level of
discovery
Everything is completely
visible
Do you have a narrowly focused target
market with fairly homogenous needs &
traits or a broad range of users with
different needs/use cases?
Target = whole world. From
large to small, etc
Will serve a variety of
different users with a
variety of use cases
Laser focused on specific
subset of users.
Do you know who your most important
customers are?
No More or less.
Absolutely! Know each
& everyone by name,
role, etc.
What level of usability & value testing have
you done?
Testing? What’s that?
Tested interactive
prototype but not
functional.
Thoroughly tested
completely usable
prototype with key users
Does the product save time & money or
increase revenue
No.
No change from
existing system
Absolutely! Saves both
time & money!
How does the application impact key
customer metrics
Negatively impacts or no
alignment to existing KPIs
Somewhat, but not
directly.
Aligned to key goals, e.g.
closing new sales.
© Kevin J Mireles

Perceived Work-Required Questions: Below are some questions to
ask and probability ranges for determining perceived work-required.
31
Low confidence
Probability = 0-40%
Medium Confidence
High Confidence
Does the application eliminate the need
for a person to operate the system?
No. Requires additional
people.
No change
Completely automates the
process, so no UI or
operator required.
Does the application subtract or add
work for the user?
Adds work.  No change
Eliminates time-consuming
steps! 
Does the application require training?
Yes! Lots & lots of
repetition to get good at it
but users will use it
infrequently.
Some training would be
good but fairly intuitive
No! Eliminates the user
interface all together
How much work is required for before
get value?
Requires not just training,
but integration into other
systems, massaging data,
etc. before get value
Some setup required but
fairly straightforward.
No work whatsoever or
someone else does all the
work.
Does getting value require
organizational & process changes?
Yes! Need to change
fundamental processes,
roles & Organizations in
order to get benefit
Minor changes to
process.
No changes whatsoever
beyond eliminating steps
people hated.
© Kevin J Mireles

Power, culture, personality & other factors: What additional factors
will increase or decrease your probability of successful adoption
32
Decrease confidence
Subtract up to 30%
Neither good nor bad
No change
Increase Confidence
Add up to 30%
Power dynamics: Who has the
power in the relationship?
They do! They are your largest
customer & can easily switch
as there are lots of
competitors
They need you as much
as you need them
• You are one of their largest
customers and they can’t get
paid unless they use the new
software.
• They’re lower-level employees
with little power
Culture/Personality: Does the
organization culture/ users’
personalities embrace or reject
change?
Org has been working same
way for decades & embraces
tradition as core value
Willing to try new things
& changes when makes
sense
Org is always looking for new toys
and embraces change as
competitive advantage
Regulatory or other
environmental constraints
Regulations or other things
about the environment make
adopting new systems high
risk
Regulations require adopting new
system to comply
Money: How much will it cost
to make changes?
Customer has to pay lots of
money to adopt
Customer is paid to make
changes
Etc.
© Kevin J Mireles

33
Some Confidence Less Confidence Even Less Confidence
The inability to predict the future is why adopting agile & agile planning are so
critical and why project plans and timelines lead to unrealistic expectations
Current
Program
Increment
Next
Program
Increment
Next +1
Program
Increment
Future
Work
No Confidence
Agile doesn’t mean no planning, it embraces the fact that
omniscience is an illusion and change is mandatory for
success!
Instead agile requires not less planning, but more planning,
just done iteratively and at different levels of precision based
on the size/complexity of the work and the time frame.

34
Some Confidence Less Confidence Even Less Confidence
Which is why adopting agile & agile planning are so critical and why project plans
and timelines lead to unrealistic expectations
Current
Program
Increment
Next
Program
Increment
Next +1
Program
Increment
Future
Work
No Confidence
Agile doesn’t mean no planning, it embraces the fact that
omniscience is an illusion and change is mandatory for success!
Instead agile requires not less planning, but more planning, just done
iteratively and at different levels of precision based on the
size/complexity of the work and the time frame.

35
Sin #2
Deadline Driven Development

36
If you can’t forecast the future, and timelines
are a figment of your imagination, then what’s
the point of overall deadlines on complex
projects, other than to destroy value and set
unrealistic expectations?

Since timelines are impossible to predict on complex projects, then if you
guarantee features, quality & delivery date, you are lying.

And lies lead to more lying

And when you have multiple teams, corporate chicken, or see who fesses up first
39
Uh… We won’t
hit the deadline

And when you have multiple teams, corporate chicken, or see who fesses up first
40
Uh… We won’t
hit the deadline
Yes! We escaped,
somebody else is to
blame for not hitting the
deadlines

Ultimately, fake deadlines have real consequences
41
Deadline-
Defined
Quality
The Black Hole of Deadline-Driven Development

Long design cycle results in high-
fidelity model & specifications
that can be turned into concrete
plans with limited set of variables
42
The challenge is that traditional model of software development is based on a
civil-engineering or manufacturing model, where any variation from timelines
and initial design represent design and planning failures.
Development is a linear process
where the end-state and the plans
to get there are clearly defined.

Unlike building a physical structure, where all the important variables can and
should be known and designed for in advance, software is a combination of art,
science and engineering where expectations change and change is constant.
43
Success & value
are in the eye of
the beholder
The answer to
hypotheses are often
found through trial,
error & aha!
moments
Standards &
processes ensure
technical excellence
& efficiency
Art Science Engineering

Unfortunately, truly transitioning from waterfall to agile feels liking stepping
backwards, from a world where you could provide “definitive” answers to one
where you only have hypotheses and maybes in need of validation
44
From Pretty Lies
• We know what needs to be done
• We know how to do it
• We know when it will be done
• We know how much it will cost
• It’s all right here on our Project Plan!
To Ugly Truths
We have a hypothesis about:
• What needs to be done
• How to do it
• When it will be done
• What it will cost
But we won’t actually know until we validate
our work
• And our plan is to plan and replan every
two weeks and two months!

Transitioning to an agile culture requires leadership that embraces messiness as
integral to innovation, and rewards honesty and learning as opposed to just
reports that always highlight linear progress!
45
“I started to clap! I said, Mark, that was
fantastic! Fantastic. Is there anything we
can do to help you?”
Alan Mulally, former Ford CEO, explaining
how rewarding honesty instead of
punishing the truth led to solving
problems sooner instead of hiding
problems and hoping they’d be fixed later.

Ultimately, it means embracing the fact that while deadlines are easy to measure
and make us feel good, what’s really needed is to accept gravity and implement
iterative planning and forecasting since the future is truly unpredictable.

47
Sin #3
Picking your horse too early in the race & embracing
the sunk cost fallacy

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
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
And the more you invest in the wrong thing, the greater
differential between cost & perceived value
Perceived Customer Value Being Delivered

51
Ultimately if the mistakes are embedded into the core
design and foundation, they may prevent you from ever
achieving your initial goals

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
And that doing it right, usually costs more up front
but results in time and cost savings in the long run

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
Run experiments in parallel
“I have not failed, I’ve just found 10,000 ways that don’t work”
Thomas Edison

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
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
Ruthlessly discard what doesn’t work and keep only the
knowledge gained
And you people, are
fired for hiding the
truth!

59
Sin #4
Confusing startup/departmental agile with
enterprise agile

60
Difference between startup agile and enterprise agile is
like the difference between building a custom home and
a skyscraper.

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
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
Startup agile enables you to deliver value to market
much faster
Great job! That
was a quick win!

64
But good luck scaling
I can’t believe I
fell for the quick
win again!

65
The higher you go, the deeper you need to dig!
But the longer it may take
to deliver the initial value

66
Sin #5
Picking the wrong 80% to focus on

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
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
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
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
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

72
Sin #6
Confusing MVP with MVR

73
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

MVP G
MVP F
MVP E
MVP D
MVP C
MVP B
74
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
Smallesttolargest
MVP A

Minimum Viable Replacement
MVP G
MVP F
MVP E
MVP D
MVP C
MVP B
75
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
Smallesttolargest

MVP G 1,2,3,4, 5,6,7, 8, etc.
MVP F
MVP E
MVP D
MVP C
MVP B
76
And if individual customers are large enough to have
customer-specific requirements, then an MVP/MVR has
to be developed for each customer.
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Customer segment G
Smallesttolargest

MVP G 1,2,3,4, 5,6,7, 8, etc.
MVP F
MVP E
MVP D
MVP C
MVP B
77
The more customizations and changes required by
internal and external stakeholders, the more difficult the
migration will be
Customer segment B
Customer segment C
Customer segment D
Customer segment E
CustomersegmentF
Customer segment G
Smallesttolargest

MVP G
MVP F
MVP E
MVP D
MVPC
MVP B
MVP A
78
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
Smallesttolargest
Customer segment G

79
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

80
Sin #7
Confusing In Market with Market Ready

81
Do not confuse your internal desire to declare victory
with the market requirements for a successful product

82
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

83
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

84
So conduct testing early and often with your target users in
order to truly understand whether the product is truly
market ready!

Seven Deadly Sins of Enterprise Software Development & What to do About Them

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (15)

Ähnlich wie Seven Deadly Sins of Enterprise Software Development & What to do About Them

Ähnlich wie Seven Deadly Sins of Enterprise Software Development & What to do About Them (20)

Mehr von kevinjmireles

Mehr von kevinjmireles (14)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Seven Deadly Sins of Enterprise Software Development & What to do About Them

Hinweis der Redaktion