Decision-Making with AMMERSE
AMMERSE represents seven categories of concern for decision-making namely Agile (A), Minimal (Mi), Maintainable (M), Environmental (E), Reachable (RE), Solvable (S) and Extensible (Ex).
When making decisions, AMMERSE can be used to gather reasonable information. AMMERSE can help you formulate your value system, assign weights and help reason about problems and your actions.
Note: You will see in the headers, that you can ramp up your skills with AMMERSE from level 1,2,3 and 3.1, explained in the AMMERSE Maturity Index.
AMMERSE provides a system of enabling constraints which is a heuristic system, allowing complex, chaotic systems to move in a desired direction.
A quick background to decision making
In decision theory, there are three branches, Normative, Prescriptive and Descriptive. Normative decision theory tries to mathematically compare and provide a statistically better decision (optimal), whereas prescriptive decision theory is about reasoning enough about the real world to make a reasonable decision. Descriptive decision theory is the study of how we make those decisions.
AMMERSE fits all three theories. AMMERSE offers seven values which can be weighted and used against formulas like the Expected Utility formula. AMMERSE can also help you mine the problem and reason about it at a prescriptive level, where you can ask the right questions and gain deeper insights. AMMERSE can also describe the decision making process in abstract terms by reasoning about the values that people choose and the weights they apply.
The Prescriptive Guide
This guide to decision-making with AMMERSE will concentrate on prescriptive decision making. We are going to start at the most _open form _or _heuristic form _and then build into a more robust prescriptive process.
Understanding your values
There are a number of reasons why decisions can be hard, but AMMERSE answers one of these with it's emphasis on values. It is highly recommended that you first evaluate your own values. By creating your own AMMERSE Set for your own values, you can apply them as weights when making decisions.
For Example: If you value Extensibility, and the two choices has one which has Extensible options and the other does not, it helps formulate your decisions. ie. Write down what you want to get out of the choice, before you make the choice. Often we do not understand or commit to a choice, because we are uncertain as to whether it is a "good fit".
AMMERSE wants you to understand yourself, your team and your customers. We do this by creating AMMERSE Sets and conducting gap analysis.
AMMERSE Heuristic thinking: (Maturity Index 1)
Even though heuristics can provide inaccuracies and be perceptible to bias, it is an easy short-cut into thinking a little more deeply. We start here, because it is a reasonable short-cut, offering some easy wins. The disclaimer is this: we usually live with the consequences of our decisions. Relying on heuristic thinking for deep problems would be unprofessional and perhaps even unethical. Understand that a heuristic is an incomplete method, offering short-cuts to ājump to conclusionsā. It can help when time is of essence, as our brain has evolved with this capability (for good or bad), and we have it hard wired into our human operating system.
Given a problem in a choice between X and Y, we can ask seven quick questions and evaluate which value we prefer.
- Is X more reachable than Y? (Reachable)
- Does X solve more problems? (Solvable)
- Is X less complicated than Y? (Minimal)
- Does X suffer from more entropy than Y? (Maintainable)
- Can I live with choice X more than I can live with choice Y? (Environmental)
- Can I modify X more than Y? (Agile)
- Can I extend X more than I can extend Y to potentially solve a future C? (Extensible)
Very quickly without hesitation, make a decision after quickly evaluating each one.
Out of A and Y who wins?
You may answer it like this.
- X > Y - I can get it quicker, and it costs less.
- X < Y - It is inferior to Y A > Y - It is more basic than Y A < Y - Y will last longer and I canāt repair A easily
- X = Y - I can live with either for now
- X < Y - Y has parts that can be modified
- X < Y - Y can be extended
At this point, you may already know. For example, Reachable is a top priority, because it fits your budget and your impatience? These two things may override any other decision, but we can quickly do some axiology on the questions.
Domain Questions
Depending on what you are reasoning about, the questions of course change slightly to make more sense.
The baseline questions are
| A | Is it Agile? (eg. Feedback loops, Continuous Improvement, Adaptable, Responsive, Decisions) |
| Mi | Is it Minimal? (eg. Costs, Problem, Solution, Risk, Design, Process, People, Objective, Impact) |
| M | Is it Maintainable? (eg. Repairable, Repeatable, Cost, Quality, Performance, Growth) |
| E | Is it Environmental (eg. Sustainable, Inclusive Culture, Regulations, Stability, Safe, Secure, Ethical) |
| R | Is it Reachable? (eg. Skills, Time, Budget, Market, Geography, Sales, Growth, Objective, Capacity, Customers) |
| S | Is it Solvable (eg. Problems [now and the future], Innovative, Creates Problems, Meta Problems, Decisions) |
| Ex | Is it Extensible? (eg. Plug-in, Snap-On, Reusable, Context-Insensitive) |
Software Design
| A | Is it Agile? (eg. Convention over configuration, Abstract Factory, Liskov Substitution, Design-time change) |
| Mi | Is it Minimal? (eg. Template Factory, Perfect Abstraction, Low SLOC, Low) |
| M | Is it Maintainable? (eg. Logging, Exception Handling, easily upgradable) |
| E | Is it Environmental (eg.Naming conventions, Fits perfectly into the environment,Good Developer Experience, Good User Experience) |
| R | Is it Reachable? (eg. New hires can reach, QA, Designer Capabilities, implementable, good over/under engineering balance) |
| S | Is it Solvable (eg. Solves the problem, does not create new problems, solve meta problems) |
| Ex | Is it Extensible? (eg. Strategy Pattern, Feature Flags, Plugins, Run-Time change) |
Personal Growth as Developer
| A | Am I Agile? (eg. Am I open to change? Adaptable, willing to accept feedback) |
| Mi | Am I Minimal? (eg. Do I think properly? Can I create elegant abstractions? Can I avoid over-engineering?) |
| M | Am I Maintainable? (eg. Do I learn new things? Do I remember what I have learnt? Can I maintain my skills and the code I write?) |
| E | Is it Environmental (eg. Do I fit into the team? Am I providing good value to the team? Do I enjoy what I do in the team?) |
| R | Is it Reachable? (eg. Am I approachable? Am I reachable for feedback? Do I have reachable goals to learn or improve?) |
| S | Is it Solvable (eg. Am I creating problems in my solutions? Do I understand my skill set so I can prevent creation of additional issues? Am I solving user problems?) |
| Ex | Is it Extensible? (eg. Can I extend my skillset or my tasks? Can I extend into other roles? Do I create extensibility hotspots for the team, for the software?) |
Business Manager
| A | Are we Agile? What impediments are there? |
| Mi | Are we Minimal? What impediments are there? |
| M | Are we Maintainable? What impediments are there? |
| E | Are we Environmental? What impediments are there? |
| R | Are we Reaching? What impediments are there? |
| S | Are we Solving problems? What impediments are there? |
| Ex | Are we Extensible? What impediments are there? |
Organisational Culture
| A | Is our Culture open to feedback and change? |
| Mi | Is our Culture one of succinct minimal design? |
| M | Is our Culture one of diligence to maintain stability? |
| E | Is our Culture stable, fit for purpose? |
| R | Is our Culture open and approachable? |
| S | Is our Culture to be helpful and find real problems? |
| Ex | Is our Culture able to accept new members, problems well? |
Business Model
| A | Do we want agility in our product? |
| Mi | Do we want well designed products? |
| M | Do we want to maintain and allow our products to be maintained? |
| E | Are we fit for the market? |
| R | Can we build the products we need? |
| S | Are we solving a real problem? |
| Ex | Do we offer extensibility to our products? |
Business Model Gap Analysis
| A | Do they have agility in their product? |
| Mi | Do they have well designed products? |
| M | Do they offer good maintenance for their products? |
| E | Are they fit for the market? |
| R | Do they build products quickly for the market? |
| S | Do they solve real problems? |
| Ex | Do they offer extensibility to their products? |
Customer Centric
| A | Do we absorb feedback? |
| Mi | Do we ask the right succinct questions? |
| M | Do we maintain our customer relationships? |
| E | Do we fit their world? |
| R | Are we approachable? |
| S | Do we solve their problems well? |
| Ex | Can they solve their problems that we haven't? |
Project Management Iron Triangle
| A | Do we have a feedback plan? |
| Mi | Do we understand it enough to create a succinct design |
| M | Can we maintain the solutions? |
| E | What is the scope and how does it fit into the context? |
| R | What is the Budget, time-frame and capabilities requires? |
| S | Are we solving the right problems? Can we solve the problem? |
| Ex | Can we solve short and long-term problems? |
Further explanation:
Reachable, Solvable and Environmental would be similar to the triangle. The quality aspect in AMMERSE is much more defined when you also consider Agile, Minimal, Maintainable and Extensible.
Coming soon
AMMERSE also offers gap analysis, weighted decisions and even metrics for software. This document outlined level 1 of decisions making.
AMMERSE follows a Maturity Index, which has 4 levels of abstraction (level 1, 2, 3 and 3.1).
(Level 2)
Using weights
(Level 3)
Building your own Sets and formulas.
(Level 3.1)
Extending your decision-making with 3rd party decision making frameworks and AMMERSE
