Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Value Driven Development

Value Driven Development

How pursuing value from complex problems in high uncertain contexts? - RubyGDL October 2014

Manuel Vidaurre

October 16, 2014
Tweet

More Decks by Manuel Vidaurre

Other Decks in Technology

Transcript

  1. Text Manuel Vidaurre - @mvidaurre Value Driven Development How pursuing

    value from complex problems in high uncertain contexts? 1
  2. Manuel Vidaurre - @mvidaurre – Kent Beck “I get paid

    for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence …” 2
  3. 3

  4. Manuel Vidaurre - @mvidaurre What is the value of software

    development? (1) The main value of software is that it is soft - Robert C. Martin Production value of software and technical debt: debt as the costs to repair problems and interest as the additional costs due to the lack of quality. - Jelle de Groot and collaborators The fundamental goal of all good design and engineering is to create maximal value added for any given investment… design is an investment activity - Barry Boehm 4
  5. Manuel Vidaurre - @mvidaurre What is the value of software

    development? (2) Core Business Values for Software: Protect revenue Increase revenue Manage cost Increase brand value Make the product remarkable Provide more value to your customers 5 Cucumber Wiki
  6. 6

  7. Manuel Vidaurre - @mvidaurre What is explicitly “code that works”?

    (1) We always have limited resources. The development method by the criticality and the team size. 7
  8. Manuel Vidaurre - @mvidaurre What is explicitly “code that works”?

    (2) 8 Agile Software Development: The Cooperative Game 2ed, Alistair Cockburn, 2006
  9. Manuel Vidaurre - @mvidaurre Building the right thing in the

    correct way Value of Information: “Pay to learn, or don’t pay if you think you know” Value of Flexibility: “Pay to not have to decide or don’t pay, either because you are sure enough the decision is right, or because the cost of changing your decision later is low” 9 "real options evaluation" model (Sullivan 1999). Design Experiments: Bayesian Analysis and Decision Trees
  10. Manuel Vidaurre - @mvidaurre – Paul A. Strassman “The proper

    measurement of the success of software investments requires more than compliance with models of technical perfection. Technical excellence of programming code is highly desirable but clearly insufficient. Nowadays the most profitable and popular software is notorious for its bugs and glitches. Economic utility and independent measures of customer satisfaction must be the ultimate arbiters of all judgment about the utility of the software” 10 Uncertainty and the value of flexibility in the face of uncertainty are at the heart of both software design and finance – Kevin Sullivan
  11. Manuel Vidaurre - @mvidaurre The Problem: value communication/knowledge gap (1)

    11 How Projects Really Work (version 1.5) http://www.projectcartoon.com/cartoon/2
  12. Manuel Vidaurre - @mvidaurre 12 There are known knowns and

    known unknowns but also there exist the unknown unknowns that neither the customer/user or the developer known and the unknown knowns that the customer/ user known but the developer doesn’t The Problem: value communication/knowledge gap (2)
  13. Manuel Vidaurre - @mvidaurre 13 Shu - Follow Ha -

    Break Ri - Trascend The Problem: value communication/knowledge gap (3) Dreyfus model of skill acquisition
  14. Manuel Vidaurre - @mvidaurre 14 Cognitive Biases that are another

    barrier for closing the communication gap: Availability heuristic, confirmation bias, congruence bias, endowment effect, framing effect, functional fixedness, hindsight bias, hyperbolic discounting, IKEA effect, loss aversion and not invented here, among others. The Problem: value communication/knowledge gap (4)
  15. Manuel Vidaurre - @mvidaurre – Helmuth Karl Bernhard von Moltke

    “the Elder” (1800–1891) “No battle plan survives contact with the enemy” 15 – Programming as Theory Building, Peter Naur, 1984 “(…) it is concluded that the proper, primary aim of programming is, not to produce programs, but to have the programmers build theories of the manner in which the problems at hand are solved by program execution.”
  16. Manuel Vidaurre - @mvidaurre A Solution: Value/Domain Driven Design (1)

    16 Software Development as a Science Software Development as an Art/Craft Software Development as a Cooperative Game ! A meta-methodology for designing and evaluating methodologies
  17. Manuel Vidaurre - @mvidaurre A Solution: Value/Domain Driven Design (2)

    17 Customer Development / Lean Startup Minimum Viable Products (MVPs) Pareto Rule and Net Present Value of Options Minimal Marketable Feature (MMF) is the smallest piece of functionality that can be delivered that has value to both the organization delivering it and the people using it. Minimum Marketable Release (MMR) a set of features that are coherent as a set to the customer and useful enough to justify the costs of delivery
  18. Manuel Vidaurre - @mvidaurre A Solution: Value/Domain Driven Design (3)

    18 Requirements what your program should do. Determine the needs or conditions to meet for a new or altered product, taking into account the possibly of conflicting requirements of the various stakeholders. Specifications how you plan to do it. They provide a precise idea of the problem to be solved so that they can efficiently design the system and estimate the cost of design alternatives.
  19. Manuel Vidaurre - @mvidaurre A Solution: Value/Domain Driven Design (4)

    19 Dependency management: High cohesion and Loose coupling Modularity creates options. Modular designs evolve as the options are pursued and exercised — the modules — can be modified after the fact at low cost. Software design and engineering activity is one of investing valuable resources under uncertainty with the goal of maximizing value added (Sullivan, 1996)
  20. Manuel Vidaurre - @mvidaurre Design by Contract 21 A Solution:

    Value/Domain Driven Design (5) Abstract Data Types, preconditions, postconditions and invariants Protocols, APIs, and Interfaces
  21. Manuel Vidaurre - @mvidaurre Principles, Practices and Patterns 22 A

    Solution: Value/Domain Driven Design (6) Connascence, Uniform Access Principle, Command–query separation, SOLID, Inheritance vs Composition Agile modeling, Lean UX/UI, BDD/TDD, Lean Software Development, Theory of Constrains, Refactoring, Quality Assurance, Issue Tracking and Retrospectives, Configuration Management and Automatization, Continuous Integration and Deployment Smells, General Responsibility Assignment Software Patterns, Design Patterns, Architectural patterns, Anti-patterns, Implementation Patterns, Configuration Patterns
  22. Manuel Vidaurre - @mvidaurre – Alistair Cockburn “The mystery is

    how to construct a different methodology for each situation, without spending so much time designing the methodology that the team doesn’t deliver software. You also don’t want everyone on your project to have to become a methodology expert.” 24
  23. Manuel Vidaurre - @mvidaurre Minimum Viable Product 31 31 The

    minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. Minimum Viable MVP Crappy Products that nobody wants to use Products build by companies better- finance than you Build Measure Learn Ideas Code Data
  24. Manuel Vidaurre - @mvidaurre Value Creation Software Development 36 Software

    by Numbers: Low-Risk, High-Return Development. By Mark Denne, Jane Cleland-Huang. Prentice Hall PTR. October 10, 2003
  25. Manuel Vidaurre - @mvidaurre Pareto Rule 37 80% of the

    business value is in 20% of the processes 80% of the defects are in 20% of the processes Software by Numbers: Low-Risk, High-Return Development. By Mark Denne, Jane Cleland-Huang. Prentice Hall PTR. October 10, 2003
  26. Manuel Vidaurre - @mvidaurre late-learning sequence of product development (2)

    They need to learn four things: 1. How to work together, and indeed, whether these people can get this job done at all. 2. Where their technical ideas are flawed. 3. How much it will cost to develop. And finally: 4. Whether they are even building the right thing. 50
  27. Manuel Vidaurre - @mvidaurre Disciplined knowledge acquisition during product development

    How can we learn what should get built? How can we learn how much it will cost (time, money, people)? How can we accelerate the team learning how to work together? How soon can we correct the mistaken assumptions in the design? 51