Waste, and other issues, seems to be associated with delivering a technical solution without tackling key risks > In modern teams, we tackle these risks prior to deciding to build anything. > —Marty Cagan, Inspired ## Some risks/areas related to a technical solution - **value risk**: will customers buy it or choose to use it? - **quality/reliability risk:** how accurately and correctly does it work? - **usability risk**: can users figure out how to use it? - **availability risk:** is it available to users when they need it? - **performance risk:** is it fast enough for users? - **interpretation risk:** do users interpret presented information correctly? - **cost risk:** how much do users need to give up to use it? - **security risk:** is it secure from malicious parties? Is the solution compliant with any required privacy regulations? - **feasibility risk**: can engineers build what we need with the skill, time and technology that they have, considering their own career goals? - **business viability risk**: does it work for various aspects of the business, such as sales, marketing, finance, legal, business development? - **financial risk:** can we afford this solution? - **business operation risk:** does it simplify business operations? - **legal risk**: is this something we can do from a legal or compliance perspective? - **modification risk**: can we modify it in a timely manner? - **architecture risk**: does the architecture enable developers to make changes fast? - **team risk:** is the team that works on it functioning well? ## Some risks excluded from the list - political/organisational risk - see [[it appears that one might cultivate agency even when the work environment doesn't support it]] - Ethical risk (is this solution something we should do?) - FIXME: align with the Nine Economic values ## Some thoughts and observations - these risks seem to apply to both *creating and operating* a technical solution - it appears that, interestingly, those risk don't mention the actual technical solution or the technology used or how company is organized or who has which role - the success might come from *emotion* as well, that is not included in the risk, see [How to Build Products Users Love (Kevin Hale)](https://www.youtube.com/watch?v=sz_LgBAGYyo) - seems to cover the four flow items from [Project to Product](https://www.goodreads.com/book/show/40679042-project-to-product) - without clarifying the goals, the effort put into a product might be wasteful. - For example, one might optimize for the high speed of new features, on the expense of future maintenance costs - Or one might focus on improving reliability and correctness, while that might not be a priority for end users - it appears that usability could be a significant business factor. For example, employees are not able to handle the [[Cynefin framework|complicated]] user interface, and so an organization decided to build an application (that cost money) with simpler interface. seems related to [[Buy vs. build|buy vs. build]] ## Examples - problem: team of 3 engineers spent 4 month building a product under tight deadline. part of the product hasn't been used for 2+ years, because of the legal reasons. - seems to be related to business viability risk - problem two engineers and one data-scientist worked on a high-cost maintenance scheduling application. the app hasn't been used because there has been no buy-in from the customers - seems to be realated to value risk - four developers spent 6 months building a specialized monitoring platform. the platform hasn't been used at all, because there was no one found to buy. - seems to be related to value risk or business viability risk - a requested automation rule was delivered only to be discovered that it is not needed anymore because meanwhile the physical product in question got out of stock - seems to be related to value risk - information from an internal application had been interpreted inaccurately by a business stakeholder, leading to business steering based on incorrect input - seems to be related to interpretation risk - tickets being build and delivered, only to have their specification changed immediately later, requiring immediate rework - seems to be related to value risk - code has grown in complexity and became hard to understand and modify and new features and bug fixes required more and more time - seems to be related to modification risk ## Further reading - [Inspired by Marty Cagan](https://www.goodreads.com/book/show/35249663-inspired) - [Economic Values - The Personal MBA](https://personalmba.com/economic-values/) - [Why we always end up with waterfall even with Scrum](https://www.amazingcto.com/why-we-always-endup-with-waterfall-even-scrum/) - [Manifesto for Agile Software Development](https://agilemanifesto.org/)