Successfully reported this slideshow.
Your SlideShare is downloading. ×

7 Deadly Sins of Enterprise Software Development V8

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 84 Ad
Advertisement

More Related Content

Slideshows for you (20)

Similar to 7 Deadly Sins of Enterprise Software Development V8 (20)

Advertisement

Recently uploaded (20)

Advertisement

7 Deadly Sins of Enterprise Software Development V8

  1. 1. 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 @kevinjmireles www.DontMakeMeWork.com 1
  2. 2. Adopting agile processes is hard. Adopting an agile culture that embraces change, trusts people to do the right thing and is focused first and foremost on satisfying the customer instead of arbitrary deadlines is much harder. 2@kevinjmireles www.DontMakeMeWork.com The cartoon is not an original Dilbert comic but originated from Luca Minudel in 2011 https://www.flickr.com/photos/lucaminudel/6059269914/
  3. 3. 3 Can create designs and plans that can be faithfully executed with little variation from initial specifications, scope and timeliness Layering Scrum, SAFe and other agile-development methodologies on top of a waterfall old-school operations-approach to software development works when traveling well trodden paths with low complexity and few unknowns. @kevinjmireles www.DontMakeMeWork.com
  4. 4. 4 But not when the road ends and you need to figure out how to get to the other side of the mountains without a map! @kevinjmireles www.DontMakeMeWork.com Impossible to accurately define, design and plan when unknowns exceed knowns
  5. 5. 5 Impossible to accurately define, design and plan when unknowns exceed knowns As a veteran mountaineer with plenty of project scars, I’ve put together these slides to help guide you as you scale the enterprise mountains standing in the way of your digital transformation. @kevinjmireles www.DontMakeMeWork.com
  6. 6. 6 Sin #1 The belief in our own omniscience & ability to accurately forecast the future @kevinjmireles www.DontMakeMeWork.com
  7. 7. 7 Are we all knowing gods? @kevinjmireles www.DontMakeMeWork.com
  8. 8. Do we have crystal balls filled with perfect insight? Roadmaps that tell us how long and how to get there? 8@kevinjmireles www.DontMakeMeWork.com
  9. 9. Or is what you can see only the tip of the iceberg, with 80% waiting to be discovered? And what happens when you base your plans on only the 20% you can see? 9 ? @kevinjmireles www.DontMakeMeWork.com
  10. 10. It’s easy to forecast the future when you have simple systems 10 1 2 @kevinjmireles www.DontMakeMeWork.com
  11. 11. But simple systems become exponentially evermore complex systems, as each system connects to other systems 11 10 5 N(N-1) 2 @kevinjmireles www.DontMakeMeWork.com
  12. 12. 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 @kevinjmireles www.DontMakeMeWork.com
  13. 13. That complexity is compounded by age as people move on, retire and pass on 13@kevinjmireles www.DontMakeMeWork.com
  14. 14. 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 @kevinjmireles www.DontMakeMeWork.com
  15. 15. 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. 15@kevinjmireles www.DontMakeMeWork.com
  16. 16. By outside forces that drive inevitable requirement changes 16@kevinjmireles www.DontMakeMeWork.com
  17. 17. And ultimately your customers and users’ acceptance based on their needs, perceptions, amount of change required by users and their willingness to change 17@kevinjmireles www.DontMakeMeWork.com 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.
  18. 18. 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 @kevinjmireles www.DontMakeMeWork.com
  19. 19. 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 @kevinjmireles www.DontMakeMeWork.com
  20. 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% @kevinjmireles www.DontMakeMeWork.com
  21. 21. 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% 21@kevinjmireles www.DontMakeMeWork.com
  22. 22. 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% @kevinjmireles www.DontMakeMeWork.com
  23. 23. 23 The ability to forecast the future decays exponentially making it impossible to accurately predict outcomes for projects that combine both uncertainty and complexity @kevinjmireles www.DontMakeMeWork.com (% 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%
  24. 24. 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. @kevinjmireles www.DontMakeMeWork.com
  25. 25. 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 @kevinjmireles www.DontMakeMeWork.com
  26. 26. 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* Probability of Successful 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 @kevinjmireles www.DontMakeMeWork.com
  27. 27. 27@kevinjmireles www.DontMakeMeWork.com Any complexity and uncertainty drives your ability to accurately forecast project scope and timelines to near zero quickly, so rather than start projects green, projects should start out red and only go to yellow/green after key hypotheses validated Probability of Technical Success X Probability of Successful Customer Adoption( )^N = Overall probability of project success 100% X 100% ( )^1 = 100% 100% X 80% ( )^1 = ~80% 80% X 80% ( )^1 = ~60% 70% X 70% ( )^1 = ~50% 80% X 80% ( )^3 = ~30% 80% X 80% ( )^4 = ~20%
  28. 28. 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 Probability = 80%-100% 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 How much experience does the team 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. How much experience does the team 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@kevinjmireles www.DontMakeMeWork.com
  29. 29. Technology Confidence Questions: Below are some questions to ask and probability ranges for determining confidence in technology to execute per their estimate. 29 Probability of Accurately Forecasting Success Low confidence Probability = 0-40% Medium Confidence Probability = 41%-70% High Confidence Probability = 80%-100% 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. @kevinjmireles www.DontMakeMeWork.com
  30. 30. Perceived Value Questions: Below are some questions to ask and probability ranges for determining perceived value. 30 Probability of Accurately Forecasting Success Low confidence Probability = 0-40% Medium Confidence Probability = 41%-70% High Confidence Probability = 80%-100% 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. @kevinjmireles www.DontMakeMeWork.com
  31. 31. Perceived Work-Required Questions: Below are some questions to ask and probability ranges for determining perceived work-required. 31 Probability of Accurately Forecasting Success Low confidence Probability = 0-40% Medium Confidence Probability = 41%-70% High Confidence Probability = 80%-100% 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. @kevinjmireles www.DontMakeMeWork.com
  32. 32. Power, culture, personality & other factors: What additional factors will increase or decrease your probability of successful adoption 32 Probability of Accurately Forecasting Success 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. @kevinjmireles www.DontMakeMeWork.com
  33. 33. 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. @kevinjmireles www.DontMakeMeWork.com
  34. 34. 34 Sin #2 Deadline Driven Development @kevinjmireles www.DontMakeMeWork.com
  35. 35. 35 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? @kevinjmireles www.DontMakeMeWork.com
  36. 36. Since timelines are impossible to predict on complex projects, then if you guarantee features, quality & delivery date, you are lying. 36@kevinjmireles www.DontMakeMeWork.com
  37. 37. And lies lead to more lying 37@kevinjmireles www.DontMakeMeWork.com
  38. 38. And when you have multiple teams, corporate chicken, or see who fesses up first 38 Uh… We won’t hit the deadline @kevinjmireles www.DontMakeMeWork.com
  39. 39. And when you have multiple teams, corporate chicken, or see who fesses up first 39 Uh… We won’t hit the deadline Yes! We escaped, somebody else is to blame for not hitting the deadlines @kevinjmireles www.DontMakeMeWork.com
  40. 40. Ultimately, fake deadlines have real consequences 40 Deadline- Defined Quality The Black Hole of Deadline-Driven Development @kevinjmireles www.DontMakeMeWork.com
  41. 41. Long design cycle results in high- fidelity model & specifications that can be turned into concrete plans with limited set of variables 41 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. @kevinjmireles www.DontMakeMeWork.com
  42. 42. 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. 42 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 @kevinjmireles www.DontMakeMeWork.com
  43. 43. Unfortunately, truly transitioning from waterfall to an 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 & iteration 43 From Beautiful 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! @kevinjmireles www.DontMakeMeWork.com
  44. 44. 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! 44 “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. @kevinjmireles www.DontMakeMeWork.com
  45. 45. 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. 45@kevinjmireles www.DontMakeMeWork.com
  46. 46. 46 Sin #3 Picking your horse too early in the race & embracing the sunk cost fallacy
  47. 47. 47 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
  48. 48. 48 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
  49. 49. 49 And the more you invest in the wrong thing, the greater differential between cost & perceived value Perceived Customer Value Being Delivered
  50. 50. 50 Ultimately if the mistakes are embedded into the core design and foundation, they may prevent you from ever achieving your initial goals
  51. 51. 51 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
  52. 52. 52 And that doing it right, usually costs more up front but results in time and cost savings in the long run
  53. 53. 53 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
  54. 54. 54 Run experiments in parallel “I have not failed, I’ve just found 10,000 ways that don’t work” Thomas Edison
  55. 55. 55 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!
  56. 56. 56 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.
  57. 57. 57 Ruthlessly discard what doesn’t work and keep only the knowledge gained And you people, are fired for hiding the truth!
  58. 58. 58 Sin #4 Confusing startup/departmental agile with enterprise agile @kevinjmireles www.DontMakeMeWork.com
  59. 59. 59 Difference between startup agile and enterprise agile is like the difference between building a custom home and a skyscraper.
  60. 60. 60 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?
  61. 61. 61 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?
  62. 62. 62 Startup agile enables you to deliver value to market much faster Great job! That was a quick win!
  63. 63. 63 But good luck scaling I can’t believe I fell for the quick win again!
  64. 64. 64 The higher you go, the deeper you need to dig! But the longer it may take to deliver the initial value
  65. 65. 65 Sin #5 Picking the wrong 80% to focus on @kevinjmireles www.DontMakeMeWork.com
  66. 66. 66 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?
  67. 67. 67 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?
  68. 68. 68 The 1% have such vastly different requirements from the other 99% that trying to transform a system designed for everyone else is almost impossible
  69. 69. 69 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
  70. 70. 70 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
  71. 71. 71 Sin #6 Confusing MVP with MVR @kevinjmireles www.DontMakeMeWork.com
  72. 72. 72 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
  73. 73. MVP G MVP F MVP E MVP D MVP C MVP B 73 Minimum Viable Replacement = Sum total of all the MVPs required to meet all customer needs required to transition existing customers and retire existing system Customer segment A Customer segment B Customer segment C Customer segment D Customer segment E CustomersegmentF Customer segment G Segment Revenue Opportunity Simplesttomostcomplex Smallesttolargest MVP A
  74. 74. Minimum Viable Replacement MVP G MVP F MVP E MVP D MVP C MVP B 74 Plus any additional enhancements/ inducements required to get stakeholders and customers to change and adopt new systems and processes MVP A Customer segment A Customer segment B Customer segment C Customer segment D Customer segment E CustomersegmentF Customer segment G Segment Revenue Opportunity Simplesttomostcomplex Smallesttolargest
  75. 75. Minimum Viable Replacement MVP G 1,2,3,4, 5,6,7, 8, etc. MVP F MVP E MVP D MVP C MVP B 75 And if individual customers are large enough to have customer-specific requirements, then an MVP/MVR has to be developed for each customer. MVP A Customer segment A Customer segment B Customer segment C Customer segment D Customer segment E CustomersegmentF Customer segment G Segment Revenue Opportunity Simplesttomostcomplex Smallesttolargest
  76. 76. Minimum Viable Replacement MVP G 1,2,3,4, 5,6,7, 8, etc. MVP F MVP E MVP D MVP C MVP B 76 The more customizations and changes required by internal and external stakeholders, the more difficult the migration will be MVP A Customer segment A Customer segment B Customer segment C Customer segment D Customer segment E CustomersegmentF Customer segment G Segment Revenue Opportunity Simplesttomostcomplex Smallesttolargest
  77. 77. Minimum Viable Replacement MVP G MVP F MVP E MVP D MVPC MVP B MVP A 77 Of course, since you are dealing with icebergs, you often have no idea what is required for each MVP Customer segment A Customer segment B Customer segment C Customer segment D Customer segment E CustomersegmentF Segment Revenue Opportunity Simplesttomostcomplex Smallesttolargest Customer segment G
  78. 78. 78 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
  79. 79. 79 Sin #7 Confusing In Market with Market Ready
  80. 80. 80 Do not confuse your internal desire to declare victory with the market requirements for a successful product
  81. 81. 81 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
  82. 82. 82 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
  83. 83. 83 So conduct testing early and often with your target users in order to truly understand whether the product is truly market ready!
  84. 84. 84 The End!

×