The document discusses Tom Gilb's principles of Value Driven Development which focus on quantifying and prioritizing values determined by critical stakeholders, designing value architecture to deliver those values incrementally based on available resources and timing, and determining value levels achieved over time. The presentation provides examples and details on applying these principles to ensure projects deliver the most value to stakeholders.

1. Value Driven Development – Principles
and Values
Keynote
Tom Gilb, Norway
Teacher, Author, Consultant
Dobrŷ den !
By Tom Gilb Agilia Conference
Tom@gilb.com Brno, CZ, March 27
www.gilb.com 2013
9:10 to 9:55
(45 mins.)
These slides will be
available Gilb.com
27 March 2013 Agilia Brno & Y Soft downloads, Slides
1

2. Summary
27 March 2013 Agilia Brno & Y Soft 2

3. no external Value delivery?
not even a thought about Stakeholders?
It is all about YOU
“You, the developer, have become the center of the universe!”
<- Scott Ambler

4. Our highest priority is to satisfy the
customer
through early and continuous delivery
of valuable software.
Working software is the primary measure of
progress.

5. Agile Manifesto: A Decade +, What can we do better? – A rewrite
The intent of Agile has always been to focus on
delivering value to our stakeholders.
But,
I think we need to be a lot more specific about
what this means,
because
some people think it means „delivering bug free
code to a user or customer‟,
even if the stakeholder gets no real value!
By Tom Gilb Agilia Conference
Tom@gilb.com Brno, CZ, March 27
www.gilb.com 2013
9:10 to 9:55
(45 mins.)
These slides will be
available Gilb.com
27 March 2013 Agilia Brno & Y Soft downloads, Slides
5

6. Gilb’s ‘Value Driven Planning’ Principles:
1. Critical Stakeholders determine the values
2. Values can and must be quantified
3. Values are supported by Value Architecture
4. Value levels are determined by timing, architecture effect, and
resources
5. Value levels can differ for different scopes (where, who)
6. Value can be delivered early
7. Value can be locked in incrementally
8. New Values can be discovered (external news, experience)
9. Values can be evaluated as a function of architecture (Impact
Estimation)
10. Value delivery will attract resources.
27 March 2013 Agilia Brno & Y Soft 6

7. Value Driven Planning
Principles
in Detail:
Published in www.agilerecord.com
2010 Part 1 and 2
• Value-Driven Development: Principles and Values
– Agility is the Tool, Not the Master.
• http://www.gilb.com/tiki-download_file.php?fileId=431
• Part 2
• “Values for Value”
• http://www.gilb.com/tiki-download_file.php?fileId=436
27 March 2013 Agilia Brno & Y Soft 7

8. 1. Critical Stakeholders determine the values
Critical: “having a decisive or crucial
importance in the success or failure of
something ” <-Dictionary
• The primary and prioritized values we
need to deliver are determined by
– analysis of the needs and values of
stakeholders
• stakeholders who can determine whether
we succeed or fail.
• We cannot afford to satisfy other
(less critical) levels,
• at other times and places, yet.
– Because that might undermine our
ability to satisfy the more critical
stakeholders –
• and consequently threaten our overall
project success.
27 March 2013 Agilia Brno & Y Soft 8

9. Stakeholder Map
Identify your „40‟ stakeholders and their
needs
Suzanne Robertson
& James Robertson
Copyright The Atlantic Systems Guild, Used with Kind Permission.
http://www.requirementsnetwork.com/sites/requirementsnetwork.com/files/Volere_Requirements-A_Socio_Technical_Discipline.pdf

10. Impact Estimation: Value-for-Money Delivery Table
Quantify Value for resources to prioritize next delivery steps
29.5 : 1
27 March, 2013 © Gilb.com Slide 10

11. 1. Critical Stakeholders determine the values
Do the
important
stuff first
27 March 2013 Agilia Brno & Y Soft 11

12. 2. ‘Values’ can and must be quantified
• Values can, if you want, be
expressed numerically.
– With a defined scale of measure
– with a deliverable level of
performance
– and with qualifier info [Where,
When, If]
• Quantification is useful:
– to clarify your own thoughts
– to get real agreement to one clear
idea
– to allow for varied targets and
constraints
– to allow direct comparison with
benchmarks
– to put in Request for bids, bids and
contracts
– to manage project evolutionarily :
track progress
– as a basis for measurement and
testing
– to enable research on methods
27 March 2013 Agilia Brno & Y Soft 12

13. •Figure 1: Real (NON-CONFIDENTIAL version) example of an initial draft of setting the objectives that
engineering processes must meet.
27 March 2013 Agilia Brno & Y Soft 13

14. 2. ‘Values’ can and must be quantified
Be
perfectly
clear
27 March 2013 Agilia Brno & Y Soft 14

15. 3. Values are supported by Value Architecture
• Value Architecture: defined as:
– anything you implement
with a view to satisfying
stakeholder values.
• Value Architecture:
– includes product/system
objectives
• Which are a „design‟ for
satisfying stakeholder
values
– Has a multitude of
performance and cost
impacts
– can impact a given system
differently, depending on
what is in the system, or
what gets put in later
– Needs to try to maximize
value delivered for
resources used.
27 March 2013 Agilia Brno & Y Soft 15

16. Code quality – ”green” week
Confirmit (2005) Norway
decided to design „ease of change‟ in, to a legacy system, in
one-week delivery-cycles, per month, using „Evo‟ Agile
„Refactoring to reduce technical debt‟ -> Re-Engineering
• In these ”green” weeks, some of the deliverables will be less visible for the end users, but more visible
for our QA department.
We manage code quality through an Impact Estimation table.
•
Speed
Maintainability
Nunit Tests
PeerTests
TestDirectorTests
Robustness.Correctness
Robustness.Boundary
Conditions
ResourceUsage.CPU
Maintainability.DocCode
SynchronizationStatus

17. 3. Values are supported by Value Architecture
•Design
the
value in
27 March 2013 Agilia Brno & Y Soft 17

18. 4. Value levels are determined by timing, architecture
effect, and resources
Value levels: defined as:
the degree of satisfaction of
value needs.
Value level:
– depends on when you observe
the level
• The environment, the people,
other system performance
characteristics (security, speed,
usability)
– depends on the current
incremental power of particular
value architecture components
– depends on resources
available both in development
and operation
27 March 2013 Agilia Brno & Y Soft 18

19. Real example of Levels of Conditions for a requirement
And some suggested architecture Testability:
Testability:
Type: Software Quality Requirement.
Version: 20 Oct 2006-10-20 Suggested Architecture
Status: Demo draft,
Stakeholder: {Operator, Tester}.
Ambition: Rapid-duration automatic testing of <critical complex tests>, with
extreme operator setup and initiation. Design Hypothesis:
Tool Simulators,
Scale: the duration of a
Reverse Cracking Tool,
defined [Volume] of testing,
or a defined [Type], Generation of simulated
telemetry frames entirely
by a defined [Skill Level] of system in software,
operator,
under defined [Operating Application specific
Conditions]. sophistication, for drilling
Goal [All Customer Use, Recorded mode
simulation by playing
Volume = 1,000,000 data items, back the dump file,
Type = WireXXXX Vs DXX,
Skill = First Time Novice, Application test harness
Operating Conditions = Field, {Sea Or console
Desert}]
<10 mins. Source: 6.2.1 HFA

20. 4. Value levels are determined by timing, architecture
effect, and resources
The value you can
deliver,
depends on
your
design
effectiveness and
your
available resources
27 March 2013 Agilia Brno & Y Soft 20

21. 5. Required Value levels can differ
for different scopes (where, who)
The level of value needed, and
the level of value delivered -
for a single attribute
dimension (like Ease of Use)
can vary for:
– different stakeholders
– at different times
• (peak, holiday, slack,
emergency, early
implementation)
– for different „locations‟
– countries, companies, industries
There is nothing simple like
„one level for all‟
27 March 2013 Agilia Brno & Y Soft 21

22. Erieye Intuitiveness Requirement
The Goal has 3 levels depending on Qualifier conditions
INTUITIVE: USAB.INTUITIVENESS
Ambition: High probability in % that operator will <immediately> within a specified
time from deciding the need to perform the task (without reference to
handbooks or help facility) find a way to accomplish their desired task.
Scale: Probability that an <intuitive>, TRAINED operator will find a way to do
whatever they need to do, without reference to any written instructions (i.e. on
paper or on-line in the system, other than help or guidance instructions offered
by the system on the screen during operation of the system) within 1 second of
deciding that there is a necessity to perform the task. <-- MAB "I'm not sure if 1
second is acceptable or realistic, it's just a guess"
Meter: To be defined. Not crucial this 1st draft - TG
Past [GRAPES] 80% ?  LN
Record [MAC] 99%?  TG
Fail [TRAINED, RARETASKS [{<1/week,<1/year}] ] 50 - 90%? MAB
Goal [TASKS DONE [<1/week (but more than 1/Month)]] 99% ? LN
[TASKS DONE [<1/year]] 20% ? - JB
[Turbulence, TASKS DONE [<1/year] ] 10% ? - TG
March 27, 2013 © www.gilb.com 22

23. 5. Required Value levels can differ
for different scopes (where, who)
The value you need
depends
on
who
and
when
and
where
27 March 2013 Agilia Brno & Y Soft 23

24. 6. Value can be delivered early
You do not have to wait until „the
project is done‟ to deliver useful
stakeholder value satisfaction.
You can intentionally target the
highest priority stakeholders,
and their highest priority value
area, and levels.
You can deliver them early and
continuously
You can learn what is possible
And what stakeholders really
value.
Discover new value ideas
Discover new stakeholders
Discover new levels of
satisfaction
27 March 2013 Agilia Brno & Y Soft 24

25. Value Added Paradigm
Value Added with Iterations
Project Cost
Value Added
without Iterations
Project Start Project End
Figure 1. Value Added by Iterative Delivery versus Non-iterative.
Courtesy: Erik Simmons, Intel Oregon

26. 6. Value can be delivered early
Deliver
the
highest
value
earliest
27 March 2013 Agilia Brno & Y Soft 26

27. 7. Value can be locked in incrementally
• You can increment the value
satisfaction
– towards longer term Goal levels
• You can spread the value deliveries
– that are proven in some places,
– more widely in the next increments
• This probably assumes that you
have really handed over real results
to real people.
– Not just developed systems without
delivery
27 March 2013 Agilia Brno & Y Soft 27

28. CONFIRMIT, Norway)
project step planning and accounting:
using an Impact Estimation Table
• IET for MR Project – Confirmit 8.5
Trond Johansen
• This is end of Increment 9 (week 9 ) of Evo delivery to pilots
• Before release to work at end of 12 week cycle.
• The incremental value is locked in at each Evo step

29. Evo’s impact on Confirmit product qualities 1st Qtr
• Only 5 highlights of the 25 impacts are listed here
Release 8.5
© Tom@Gilb.com www.gilb.com

30. 7. Value can be locked in incrementally
Prove
real value delivery
then
Scale up
and
Spread out
27 March 2013 Agilia Brno & Y Soft 30

31. 8. New Values can be discovered
(external news, experience)
• Expect, and try to
discover,
– entirely new
stakeholder values.
• These will of course
emerge after you start
delivering some
satisfaction, because:
– Stakeholders believe
you can help
– Things change
27 March 2013 Agilia Brno & Y Soft 31

32. Experience: if top level requirements
are separated from design, the
„requirements‟ are stable!
•
•
http://rsbatechnology.co.uk/blog:8
Back in 2004, I was employed by a large investment bank in their FX e-commerce IT • “On the largest critical
department as a business analyst.
• The wider IT organisation used a complex waterfall-based project methodology that
required use of an intranet application to manage and report progress.
project,
• However, it's main failings were that it almost totally missed the ability to track
delivery of actual value improvements to a project's stakeholders, and the ability
to react to changes in requirements and priority for the project's duration. • the original business
• The toolset generated lots of charts and stats that provided the illusion of risk
control. but actually provided very little help to the analysts, developers and testers
actually doing the work at the coal face. functions & performance
• The proof is in the pudding;
– I have used Evo (albeit in disguise sometimes) on two large, high-risk
objective requirements
projects in front-office investment banking businesses, and several smaller tasks.
– On the largest critical project, the original business functions & performance
requirements document, which
objective
document,
included no design, essentially remained
unchanged over the 14 months the project took to deliver,
• which included no
– but the detailed designs (of the GUI, business logic, design,
changed many many
• essentially remained
performance characteristics)
times, guided by lessons learnt and feedback gained by delivering a succession
of early deliveries to real users.
– In the end, the new system responsible for 10s of USD billions of notional risk, unchanged
successfully went live over over one
weekend for 800 users worldwide, and • over the 14 months the
was seen as a big success by the
sponsoring stakeholders.
project took to deliver,….”
“ I attended a 3-day course with you and Kai whilst at Citigroup in 2006”, Richard Smith
27 March, 2013 © Gilb.com 32

33. Dynamic (Agile, Evo) design testing:
not unlike ‘Lean Startup’
• http://rsbatechnology.co.uk/blog:8
• Back in 2004, I was employed by a large investment bank in their FX e-commerce IT
“… but the
detailed
department as a business analyst.
• The wider IT organisation used a complex waterfall-based project methodology that
required use of an intranet application to manage and report progress.
•
•
designs
However, it's main failings were that it almost totally missed the ability to track
delivery of actual value improvements to a project's stakeholders, and the ability to
react to changes in requirements and priority for the project's duration.
• The toolset generated lots of charts and stats that provided the illusion of risk control.
but actually provided very little help to the analysts, developers and testers actually
doing the work at the coal face.
– (of the GUI, business logic,
• The proof is in the pudding; performance
– I haveused Evo (albeit in disguise sometimes) on two large, high-risk projects
characteristics)
in front-office investment banking businesses, and several smaller tasks.
– On the largest critical project, the original business functions & performance objective
requirements document, which included no
design, essentially remained unchanged over
the 14 months the project took to deliver,
• changed many
– but the detailed designs (of the GUI, business logic, performance
characteristics) changed many many times, guided by
many times,
lessons learnt and feedback gained by delivering a succession of early deliveries to real
users. • guided by lessons learnt
– In the end, the new system responsible for 10s of USD billions of notional risk,
successfully went live over over one • and feedback gained by
weekend for 800 users worldwide, and • delivering a succession of early
was seen as a big success by the deliveries
sponsoring stakeholders.
• to real users”
“ I attended a 3-day course with you and Kai whilst at Citigroup in 2006”, Richard Smith
27 March, 2013 © Gilb.com 33

34. It looks like the stakeholders liked
the top level system qualities,
on first try
•
•
http://rsbatechnology.co.uk/blog:8
Back in 2004, I was employed by a large investment bank in their FX e-commerce IT
– “ In the end, the new
•
department as a business analyst.
The wider IT organisation used a complex waterfall-based project methodology that
system responsible for 10s
•
required use of an intranet application to manage and report progress.
However, it's main failings were that it almost totally missed the ability to track
of USD billions of notional
delivery of actual value improvements to a project's stakeholders, and the ability
to react to changes in requirements and priority for the project's duration.
risk,
• The toolset generated lots of charts and stats that provided the illusion of risk
control. but actually provided very little help to the analysts, developers and testers
actually doing the work at the coal face.
– successfully went
• The proof is in the pudding; live
–
–
I have used Evo (albeit in disguise sometimes) on two large, high-risk
projects in front-office investment banking businesses, and several smaller tasks.
On the largest critical project, the original business functions & performance
– over over one
requirements document, which
objective weekend
included no design, essentially remained
unchanged over the 14 months the project took to deliver, – for 800 users
– but the detailed designs (of the GUI, business logic, worldwide ,
performance characteristics) changed many many – and was seen as a
times, guided by lessons learnt and feedback gained by delivering a succession
of early deliveries to real users. big success
– by the sponsoring
stakeholders.”
“ I attended a 3-day course with you and Kai whilst at Citigroup in 2006” , Richard Smith
27 March, 2013 © Gilb.com 34

35. 8. New Values can be discovered
(external news, experience)
Discovering new
stakeholders and
requirements
is endless
but
is always
an improvement
27 March 2013 Agilia Brno & Y Soft 35

36. 9. Values can be evaluated as a function of
architecture (using ‘Impact Estimation’)
• It is possible to get an overview of
– the totality of impacts
– that your architecture
– (all designs and strategies)
– might have
– on all your defined stakeholder
needs.
• Use an Impact Estimation table
– and you will be able to spot See next slide
opportunities for For enlargement
• high value and
• low cost early deliveries
– by analyzing the numbers on the
table
27 March 2013 Agilia Brno & Y Soft 36

37. Strategy Impact Estimation:
for a $100,000,000 Organizational Improvement Investment
Defined
In earlier slide
27 March 2013 Agilia Brno & Y Soft 37

38. 9. Values can be evaluated as a function of
architecture (using ‘Impact Estimation’)
Most
architecture
impacts
most
requirements See next slide
For enlargement
27 March 2013 Agilia Brno & Y Soft 38

39. 10. Value delivery will attract resources.
• If you are really good at
delivering value
– You can expect to attract
• even more funding
– Managers like
• to be credited with success
– Money seeks
• best interest rates
27 March 2013 Agilia Brno & Y Soft 39

40. Return On Investment at Raytheon
about $10,000 per programmer/year
http://www.sei.cmu.edu/pub/documents/95.reports/pdf/tr017.95.pdf
9
8
7
6
5
4
3
2
1
0
Invested Payback
• ROI = $7.70 per $1 invested at Raytheon
• Sell your improvement program to top management on this basis
• “we got almost all corporate investment available,
because we could show the best return on
investment”
Wednesday, March 27, 2013 Copyright Gilb@acm.org 40

41. Raytheon 95 Software Productivity 2.7X better
Productivity
+
170%
1988 1994

42. Achieving Project Predictability: Raytheon
95
Cost At Completion / Budget %
140%
100%
1988 1990 1994
SEE PPT NOTE FOR
DEFINITION.
Wednesday, March 27, 2013 Copyright Gilb@acm.org 42

43. 10. Value delivery will attract resources.
Deliver value
Resources
will find you
27 March 2013 Agilia Brno & Y Soft 43

44. Meet Brian Wernham: Our Next Speaker Today: 10:05
His book is great on well-documented case studies in
agile use of stakeholder analysis and value focus
See my detailed opinion in the foreword to this book
http://www.amazon.com/Agile-Project-Management-Government-Wernham/dp/0957223404
27 March 2013 Agilia Brno & Y Soft 44

45. Last slide
• Ecstatic Stakeholder!
• PS Special free offer Agilia:
– If you email me tom@gilb.com
– Subject ‘Book’
– I will send you my Competitive
Engineering book digitally
– And several Agile papers
27 March 2013 Agilia Brno & Y Soft 45

46. • Extra Slides
27 March 2013 Agilia Brno & Y Soft 46

47. 27 March 2013 Agilia Brno & Y Soft 47

48. 27 March 2013 Agilia Brno & Y Soft 48

49. End of Lecture
• In practice after 40 minutes.
• The rest of the slides are for additional
documentation
27 March 2013 Agilia Brno & Y Soft 49

50. Gilb’s Value Manifesto: A Management Policy?
1. Really useful value, for real stakeholders will be
defined measurably.
No nice-sounding emotive words please.
2. Value will be seen in light of total long term costs
as a decent return on investment.
3. Powerful management devices, like motivation and
follow-up, will make sure that the value for money
is really delivered –
or that the failure is punished, and the success is
rewarded.
4. The value will be delivered evolutionarily –
not all at the end.
5. That is, we will create a stream of prioritized value
delivery to stakeholders, at the beginning of our
value delivery projects;
and continue as long as the real return on
investment is suitably large.
6. The CEO is primarily responsible for making all
this happen effectively.
1. The CFO will be charged with tracking all
value to cost progress.
2. The CTO and CIO will be charged with
formulating all their efforts in terms of
measurable value for resources.
Source “Value Delivery in Systems Engineering” available at www.gilb.com
Unpublished paper http://www.gilb.com/community/tiki-download_file.php?fileId=137
27 March 2013 Agilia Brno & Y Soft 50

51. The Value Delivery Problem
• Sponsors who order and pay for systems
engineering projects, must justify their money
spent based on the expected consequential
effects (hereafter called ‘value’) of the systems.
•
• The value of the technical system is often
expressed in presentation slides and
requirements documents as a set of nice-
sounding words, under various titles such as
“System Objectives”, and “Business Problem
Definition”
27 March 2013 Agilia Brno & Y Soft 51

52. Some Assertions
Assertion 1. When top management allows large projects to proceed, with such badly formulated primary
objectives, then
– they are responsible as managers for the outcome (failure).
– They cannot plead ignorance.
Assertion 2. The failure of technical staff (project management) to react to the lack of primary objective
formulation by top management is also a total failure to do reasonable systems engineering.
– Management might have a poor requirements culture, but we should routinely save them from
themselves.
Assertion 3. Both top managers and project personnel can be trained and motivated to clarify and quantify
critical objectives routinely.
– But until the poor external culture of education and practice changes, it may take strong CEO action
to make this happen in your corporation.
– My experience is that no one else will fight for this.
Assertion 4. All top level system performance improvements, are by definition, variables.
– So, we can expect to define them quantitatively.
– We can also expect to be able to measure or test the current level of performance.
– Words like ‘enhanced’, ‘reduced’, ‘improved’ are not serious systems engineering requirements
terms.
27 March 2013 Agilia Brno & Y Soft 52

53. THESE ARE SAME PRINCIPLES AND VALUES
• BUT WITH NO DETAILED TEXT FOR EACH AND
NO GILB EXAMPLES
• FOR USE WHEN LITTLE TIME AND NOT TOO
DEMANDING AUDIENCE
27 March 2013 Agilia Brno & Y Soft 53

54. Gilb’s Ten Key Agile Principles
to avoid bureaucracy and give creative freedom (Summary)
Control projects by quantified critical-few results. 1 Page total !
(not stories, functions, features, use cases, objects, ..)
Make sure those results are business results, not technical
Align your project with your financial sponsor‟s interests!
Give developers freedom, to find out how to deliver those results
Estimate the impacts of your designs, on your quantified goals
Select designs with the best impacts for their costs, do them first.
Decompose the workflow, into weekly (or 2% of budget) time boxes
Change designs, based on quantified experience of implementation
Change requirements, based on quantified experience, new inputs
Involve the stakeholders, every week, in setting quantified goals
Involve the stakeholders, every week, in actually using increments
Copyright 2004-8 Gilb, may be used citing source
27 March 2013 Agilia Brno & Y Soft 54

55. Gilb’s Ten Key Agile Principles (Sum)
to avoid bureaucracy and give creative freedom
Main Idea:
Get early and frequent real stakeholder net value delivered
27 March 2013 Agilia Brno & Y Soft 55

56. Control projects by quantified
critical-few results. 1 Page total !
(not stories, functions, features, use cases, objects, ..)
27 March 2013 Agilia Brno & Y Soft 56

57. Make sure those results are
business results, not technical
Align your project with your financial sponsor‟s interests!
27 March 2013 Agilia Brno & Y Soft 57

58. Give developers freedom,
to find out how
to deliver those results
27 March 2013 Agilia Brno & Y Soft 58

59. Estimate the impacts of your designs,
on your quantified goals
27 March 2013 Agilia Brno & Y Soft 59

60. Select designs with the best impacts
for their costs,
do them first.
27 March 2013 Agilia Brno & Y Soft 60

61. Decompose the workflow,
into weekly (or 2% of budget) time boxes
27 March 2013 Agilia Brno & Y Soft 61

62. Change designs,
based on
quantified experience of implementation
27 March 2013 Agilia Brno & Y Soft 62

63. Change requirements,
based on quantified experience,
new inputs
27 March 2013 Agilia Brno & Y Soft 63

64. Involve the stakeholders,
every week,
in setting quantified goals
27 March 2013 Agilia Brno & Y Soft 64

65. Involve the stakeholders,
every week,
in actually using increments
27 March 2013 Agilia Brno & Y Soft 65

66. My 10 Agile Values? (Summary)
• Simplicity
– 1. Focus on real stakeholder values
• Communication
– 2. Communicate stakeholder values quantitatively
– 3. Estimate expected results and costs for weekly steps
• Feedback
– 4. Generate results, weekly, for stakeholders, in their environment
– 5. Measure all critical aspects of the improved results cycle.
– 6. Analyze deviation from your initial estimates
• Courage
– 7. Change plans to reflect weekly learning
– 8. Immediately implement valued stakeholder needs, next week
• Don’t wait, don’t study (analysis paralysis), don’t make excuses.
• Just Do It!
– 9. Tell stakeholders exactly what you will deliver next week
– 10. Use any design, strategy, method, process that works quantitatively well - to get your
results
• Be a systems engineer, not a just programmer (a ‘Softcrafter’).
• Do not be limited by your craft background, in serving your paymasters
27 March 2013 Agilia Brno & Y Soft 66

67. My 10 Agile Values? (Detail)
• Simplicity
• Communication
• Feedback
• Courage
27 March 2013 Agilia Brno & Y Soft 67

68. Simplicity
– 1. Focus on real stakeholder values
27 March 2013 Agilia Brno & Y Soft 68

69. Communication
– 2. Communicate stakeholder values
quantitatively
27 March 2013 Agilia Brno & Y Soft 69

70. Estimate Often
• 3. Estimate expected results and costs for
weekly steps
27 March 2013 Agilia Brno & Y Soft 70

71. Feedback
– 4. Generate results, weekly, for
stakeholders, in their environment
27 March 2013 Agilia Brno & Y Soft 71

72. Measure Critical Stuff
• 5. Measure all critical aspects of the
improved results cycle.
27 March 2013 Agilia Brno & Y Soft 72

73. Learn from Deviations
• 6. Analyze deviation from your initial
estimates
27 March 2013 Agilia Brno & Y Soft 73

74. Courage
– 7. Change plans to reflect weekly learning
27 March 2013 Agilia Brno & Y Soft 74

75. Deliver Value Now
• 8. Immediately implement valued
stakeholder needs, next week
• Don’t wait, don’t study (analysis
paralysis), don’t make excuses.
• Just Do It!
27 March 2013 Agilia Brno & Y Soft 75

76. Tell Stakeholders What’s next
• 9. Tell stakeholders exactly what you will
deliver next week
27 March 2013 Agilia Brno & Y Soft 76

77. If it works, do it!
• 10. Use any design, strategy, method,
process that works quantitatively
well - to get your results
• Be a systems engineer, not a just
programmer (a ‘Softcrafter’).
• Do not be limited by your craft
background, in serving your
paymasters
27 March 2013 Agilia Brno & Y Soft 77

78. Last slide
• Ecstatic Stakeholder!
• PS Special free offer Agilia:
– If you email me tom@gilb.com
– Subject ‘Book’
– I will send you my Competitive
Engineering book digitally
– And several Agile papers
27 March 2013 Agilia Brno & Y Soft 78