Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Gilbs agile principles and values agilia conf keynote brno cz march 27 2013

1,473 views

Published on

My Keynote at Agilia conference Brno CZ 27 Mar 2013

  • Be the first to comment

  • Be the first to like this

Gilbs agile principles and values agilia conf keynote brno cz march 27 2013

  1. 1. Value Driven Development – Principles and Values Keynote Tom Gilb, Norway Teacher, Author, Consultant Dobrŷ den !By Tom Gilb Agilia ConferenceTom@gilb.com Brno, CZ, March 27www.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. 2. Summary27 March 2013 Agilia Brno & Y Soft 2
  3. 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. 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. 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 ConferenceTom@gilb.com Brno, CZ, March 27www.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. 6. Gilb’s ‘Value Driven Planning’ Principles:1. Critical Stakeholders determine the values2. Values can and must be quantified3. Values are supported by Value Architecture4. Value levels are determined by timing, architecture effect, and resources5. Value levels can differ for different scopes (where, who)6. Value can be delivered early7. Value can be locked in incrementally8. 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. 7. Value Driven Planning Principles in Detail:Published in www.agilerecord.com2010 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. 8. 1. Critical Stakeholders determine the valuesCritical: “having a decisive or crucialimportance 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. 9. Stakeholder Map Identify your „40‟ stakeholders and their needs Suzanne Robertson & James RobertsonCopyright The Atlantic Systems Guild, Used with Kind Permission.http://www.requirementsnetwork.com/sites/requirementsnetwork.com/files/Volere_Requirements-A_Socio_Technical_Discipline.pdf
  10. 10. Impact Estimation: Value-for-Money Delivery TableQuantify Value for resources to prioritize next delivery steps 29.5 : 1 27 March, 2013 © Gilb.com Slide 10
  11. 11. 1. Critical Stakeholders determine the values Do the important stuff first27 March 2013 Agilia Brno & Y Soft 11
  12. 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. 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. 14. 2. ‘Values’ can and must be quantified Beperfectly clear27 March 2013 Agilia Brno & Y Soft 14
  15. 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. 16. Code quality – ”green” week Confirmit (2005) Norwaydecided 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. 17. 3. Values are supported by Value Architecture •Design the value in27 March 2013 Agilia Brno & Y Soft 17
  18. 18. 4. Value levels are determined by timing, architecture effect, and resourcesValue 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. 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 ArchitectureStatus: Demo draft,Stakeholder: {Operator, Tester}.Ambition: Rapid-duration automatic testing of <critical complex tests>, withextreme 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 specificConditions]. sophistication, for drillingGoal [All Customer Use, Recorded mode simulation by playingVolume = 1,000,000 data items, back the dump file,Type = WireXXXX Vs DXX,Skill = First Time Novice, Application test harnessOperating Conditions = Field, {Sea Or consoleDesert}] <10 mins. Source: 6.2.1 HFA
  20. 20. 4. Value levels are determined by timing, architecture effect, and resourcesThe value you can deliver, depends on your design effectiveness and youravailable resources27 March 2013 Agilia Brno & Y Soft 20
  21. 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, industriesThere is nothing simple like „one level for all‟ 27 March 2013 Agilia Brno & Y Soft 21
  22. 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 "Im not sure if 1 second is acceptable or realistic, its 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% ? - TGMarch 27, 2013 © www.gilb.com 22
  23. 23. 5. Required Value levels can differ for different scopes (where, who) The value you need depends on who and when and where27 March 2013 Agilia Brno & Y Soft 23
  24. 24. 6. Value can be delivered earlyYou 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 continuouslyYou 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. 25. Value Added Paradigm Value Added with Iterations Project Cost Value Added without Iterations Project Start Project EndFigure 1. Value Added by Iterative Delivery versus Non-iterative. Courtesy: Erik Simmons, Intel Oregon
  26. 26. 6. Value can be delivered early Deliver the highest value earliest27 March 2013 Agilia Brno & Y Soft 26
  27. 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. 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. 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. 30. 7. Value can be locked in incrementally Prove real value delivery then Scale up and Spread out27 March 2013 Agilia Brno & Y Soft 30
  31. 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. 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, its main failings were that it almost totally missed the ability to track delivery of actual value improvements to a projects stakeholders, and the ability to react to changes in requirements and priority for the projects 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 Smith27 March, 2013 © Gilb.com 32
  33. 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, its main failings were that it almost totally missed the ability to track delivery of actual value improvements to a projects stakeholders, and the ability to react to changes in requirements and priority for the projects 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. 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, its main failings were that it almost totally missed the ability to track of USD billions of notional delivery of actual value improvements to a projects stakeholders, and the ability to react to changes in requirements and priority for the projects 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 Smith27 March, 2013 © Gilb.com 34
  35. 35. 8. New Values can be discovered (external news, experience)Discovering newstakeholders and requirements is endless but is always an improvement27 March 2013 Agilia Brno & Y Soft 35
  36. 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. 37. Strategy Impact Estimation: for a $100,000,000 Organizational Improvement Investment Defined In earlier slide27 March 2013 Agilia Brno & Y Soft 37
  38. 38. 9. Values can be evaluated as a function of architecture (using ‘Impact Estimation’) Most architecture impacts most requirements See next slide For enlargement27 March 2013 Agilia Brno & Y Soft 38
  39. 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. 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. 41. Raytheon 95 Software Productivity 2.7X betterProductivity + 170% 1988 1994
  42. 42. Achieving Project Predictability: Raytheon 95Cost At Completion / Budget % 140% 100% 1988 1990 1994 SEE PPT NOTE FOR DEFINITION. Wednesday, March 27, 2013 Copyright Gilb@acm.org 42
  43. 43. 10. Value delivery will attract resources. Deliver value Resources will find you27 March 2013 Agilia Brno & Y Soft 43
  44. 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/095722340427 March 2013 Agilia Brno & Y Soft 44
  45. 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. 46. • Extra Slides27 March 2013 Agilia Brno & Y Soft 46
  47. 47. 27 March 2013 Agilia Brno & Y Soft 47
  48. 48. 27 March 2013 Agilia Brno & Y Soft 48
  49. 49. End of Lecture• In practice after 40 minutes.• The rest of the slides are for additional documentation27 March 2013 Agilia Brno & Y Soft 49
  50. 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. 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. 52. Some AssertionsAssertion 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. 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 AUDIENCE27 March 2013 Agilia Brno & Y Soft 53
  54. 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 resultsEstimate the impacts of your designs, on your quantified goalsSelect designs with the best impacts for their costs, do them first.Decompose the workflow, into weekly (or 2% of budget) time boxesChange designs, based on quantified experience of implementationChange requirements, based on quantified experience, new inputsInvolve the stakeholders, every week, in setting quantified goalsInvolve 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. 55. Gilb’s Ten Key Agile Principles (Sum) to avoid bureaucracy and give creative freedomMain Idea: Get early and frequent real stakeholder net value delivered 27 March 2013 Agilia Brno & Y Soft 55
  56. 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. 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. 58. Give developers freedom, to find out how to deliver those results27 March 2013 Agilia Brno & Y Soft 58
  59. 59. Estimate the impacts of your designs, on your quantified goals27 March 2013 Agilia Brno & Y Soft 59
  60. 60. Select designs with the best impacts for their costs, do them first.27 March 2013 Agilia Brno & Y Soft 60
  61. 61. Decompose the workflow, into weekly (or 2% of budget) time boxes27 March 2013 Agilia Brno & Y Soft 61
  62. 62. Change designs, based on quantified experience of implementation27 March 2013 Agilia Brno & Y Soft 62
  63. 63. Change requirements, based on quantified experience, new inputs27 March 2013 Agilia Brno & Y Soft 63
  64. 64. Involve the stakeholders, every week, in setting quantified goals27 March 2013 Agilia Brno & Y Soft 64
  65. 65. Involve the stakeholders, every week, in actually using increments27 March 2013 Agilia Brno & Y Soft 65
  66. 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. 67. My 10 Agile Values? (Detail)• Simplicity• Communication• Feedback• Courage 27 March 2013 Agilia Brno & Y Soft 67
  68. 68. Simplicity – 1. Focus on real stakeholder values27 March 2013 Agilia Brno & Y Soft 68
  69. 69. Communication – 2. Communicate stakeholder values quantitatively27 March 2013 Agilia Brno & Y Soft 69
  70. 70. Estimate Often• 3. Estimate expected results and costs for weekly steps27 March 2013 Agilia Brno & Y Soft 70
  71. 71. Feedback – 4. Generate results, weekly, for stakeholders, in their environment27 March 2013 Agilia Brno & Y Soft 71
  72. 72. Measure Critical Stuff• 5. Measure all critical aspects of the improved results cycle.27 March 2013 Agilia Brno & Y Soft 72
  73. 73. Learn from Deviations• 6. Analyze deviation from your initial estimates27 March 2013 Agilia Brno & Y Soft 73
  74. 74. Courage – 7. Change plans to reflect weekly learning27 March 2013 Agilia Brno & Y Soft 74
  75. 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. 76. Tell Stakeholders What’s next• 9. Tell stakeholders exactly what you will deliver next week27 March 2013 Agilia Brno & Y Soft 76
  77. 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 paymasters27 March 2013 Agilia Brno & Y Soft 77
  78. 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

×