AMMERSE can be used to create a Pattern Language or be added to an existing Pattern Language as guidance for usage.
A Pattern Language is a list of related patterns which describe problems and solutions. The patterns are repeatable solutions and are written down in a common form, which includes headings like Pattern Name, Intent, Problem Description, Context and Solution.
Many groups are creating patterns. These patterns are mainly singular ideas (problem/solution), written as tools in your toolbox. Many problems can manifest.
- Lack of guidance on how the patterns work together
- Whether the solution has unexpected consequences and negatives (especially when used together)
- The complex behaviours arising from relationships between patterns
- What organisational values it promotes
- What personal values do they align with
- What measurement types can you use to evaluate their effectiveness
- Gap Analysis before and after using a pattern
- Forces (inputs/outputs/feedback loops) on patterns and the environment they are used in
- Cataloguing patterns from various pattern languages, including their relationships
The following will outline the guidelines for creating a Pattern Language using AMMERSE.
Include the AMMERSE Pattern Language to reason about the problems above and create AMMERSE Sets listed within the Pattern Language and Pattern as a guide to adoptors for what to expect.
Research the patterns and apply AMMERSE values to guide adopters on all the forces involved with the patterns.
With AMMERSE, pattern creators and adopters can declare expectations, limitations and intents against organisational values.
At the heart of a Pattern Language is the notion of a problem and a solution. Often, patterns are difficult to create because the problem needs to be clear and the solution stripped from a context that will render it useless in other contexts. At the heart of a pattern is a common problem and a repeatable solution. Adding AMMERSE, you will also see values as Inputs and Outputs, Relationships and Sequences to Patterns, and targets.
Patterns for Pattern Creation
It is difficult for the adopter to gauge the target values. This is not the expected output but rather the targets the Author sets that could be achieved if pursuing the pattern. The adopter does not understand the target values and what to expect.
Add AMMERSE values that act as a target for the Pattern. The Pattern declares what it aims to increase or reduce.
If the pattern is expected to bring an increase in agility, we would declare it as:
Your pattern does not have Second Order thinking. It is difficult for adopters to gauge the values that act as forces on the pattern.
Add the AMMERSE values that act as input forces on the Pattern. Input forces are challenges and problems that need to be addressed.
Using an AMMERSE Set to declare the input forces.
Each of the seven values is written with their symbol and the value in brackets. The heuristic values of 0, 0.5 and 1 can be used for simplicity.
Input: A(.5), Mi(0), M(0), E(0), R(1), S(.5), Ex(0)
A textual summary of why you came to the values should be included. This could appear in the pattern heading named "Problem".
The values are to be read as what forces will always be against the pattern by the environment. If the pattern is SwitchToAgile, then the Input forces would include A(1), Mi(1), M(1), E(1), R(1), S(1), Ex(0)
This means that for the SwitchToAgile, you would have many forces against it. The value of 1 shows the weight of the value. The above could be reduced to the following:
- A(1) You will need to prove adaptability and agility
- Mi(1) You will need to keep it Minimal, or else risk losing the audience
- M(1) You will need to show that it is more Maintainable than the existing
- E(1) You will find the Environment and the minds of established mindsets
- R(1) You will find it difficult to measure and reach
- S(1) You will need to solve real problems that they face
- Ex(0) There are no Extensibility forces to be concerned with
Your pattern does not have Second Order thinking. It is difficult for adopters to gauge what the forces will be on the system.
Specify the AMMERSE values which will be increased or decreased if using the pattern. Output values can be positive or negative.
Add an AMMERSE Set with values to specify what the Pattern will influence when used.
Output: A(.5), Mi(0), M(0), E(0), R(1), S(.5), Ex(0)
A textual summary of why you came to the values should be included. This would appear in the pattern heading named "Solution".
In a pattern named SelfOrganisingTeam, you may declare outputs as
A(.5), Mi(.5), M(.5), E(.5), R(.5), S(.5), Ex(.5)
All the values are 50/50, meaning the values have an equal chance of being 0 as it does 1. This means that a Self-organising team does not magically gain value.
For example, the Environmental is 50/50, as the team members may not be happy with the setup. Individually, some may feel that they cannot really accept the joint responsibility and would prefer a leader or a mentor within the team.
Even though you have listed input and output forces in terms of AMMERSE values, it does not make clear the many positive or negative feedback loops that can exist in the system.
Specify values and their positive and negative feedback loops that are in play when using the pattern.
Understand the pattern and how it relates to the seven AMMERSE values.
Specify whether the value is a negative or a positive feedback loop.
An async communication pattern, as an example, may produce the following.
Async Communication adds Positive Feedback loops to the messages. The more it is used, the more messages there will be. The more messages, the more replies.
We can say that it will have a positive feedback loop to Minimal as content grows, making it less minimal. We use ++ for the positive feedback loop.
This is written like this Mi(++), MI(--), or Mi(+-)
It also has a relationship with accountability and history as it is documentation of all the conversations.
There are also negative feedback loops; as fewer people respond, a decrease in engagement can occur.
This, therefore, would Solve fewer problems, especially communication, so that we can write Solvable(-+). We add -+, because it can go in either direction, depending on how it is operated.
It is difficult to move from one Pattern to another or use different patterns together because the contexts can vary. A pattern may have a dependency or a temporal or environmental condition.
Organise two or more Patterns into a sequence so that guidance is made on the order and linear nature of a set of patterns.
Create an AMMERSE Set, which describes the aim of the sequence if you decide that a sequence requires two patterns and the order matters, you will create two AMMERSE Sets, naming them A and B. Each set is assigned values.
Patterns A and B are now concerned with the values that are assigned. The sequence of A->B is now listed to the adopter. Seeing the two sets, they understand that the pattern sequence starts with A, and has they achieve A, they can move to B. This allows a sequential dependency to be created, together with the benefits of understanding the Target Values.
This diagram shows four individual patterns, where A and B are in a sequence. The other two are no within a sequence.
The Maturity Index is a sequence.
A Pattern should be implemented when the conditions are right, and the expected outcomes are high, but depending on the conditions, a pattern may not be suitable. There are also patterns which lend themselves better to certain conditions, and this needs to be stated. A similar problem is the idea of switching from one pattern to another, either by design or by necessity, which pattern languages do not readily declare.
Create Modes which enable or disable certain patterns across the pattern language. For example, if the Mode is "Emergency", we could use the pattern "EmergencyServerDownResponse" and not the "TeamBuildHikingTrip".
Consider and create modes of your choice. A mode is an AMMERSE Set with weighted values. When declaring your pattern, ensure it is clear that it operates in one or more modes.
The diagram shows Sets, Sequences and Modes. A pattern language can consist of singular patterns for all occasions, patterns that correspond to a sequence and patterns that belong to a mode. All the while, forces, feedback and targets are listed to demonstrate the context, tradeoffs and considerations.
SIDEBAR: This section gives a few examples
How AMMERSE adds to the existing pattern language approach
AMMERSE is centred around values. Solutions are also centred around values. For example, if you value direct communication, openness and collaboration, the answer to a problem like "We dont know what the other person is doing" or "We didn't know about the other task", may have a solution of "Talk to them". This may formulate into "talk to them daily". This may lead you to declare that communicating in person and daily is a worthwhile activity. You may conduct experiments and practice this, gathering positive feedback of the experience.
You may write this as a pattern for others to use. If you value the same things, you may follow this pattern and benefit from it.
However, if you do not care for meetings, or collaboration is something you do occasionally, or you prefer to catch up with people in a "one on one", you may not enjoy this kind of solution. Your solution could be "write what you are doing in a common channel in IRC". It may be, do it often, but dont tag me to everything, I will read it when I get a chance. However, if anyone is blocked, arrange a meet one on one. No problem should go without a conversation for more than 4 hours.
Two solutions, two approaches. AMMERSE can be used to describe the two patterns.
Daily Face to Face Meetings with team
A(0), Mi(0), M(.5), E(.5), R(.5), S(.5), Ex(1)
Async info, with on-demand meet
A(1), Mi(.5), M(1), E(.5), R(1), S(1), Ex(1)
You can see the weights assigned, but this is a subjective set of weights, so how should you start to score the values?
How to score values in a pattern
We only want to declare three states for patterns without empirical and complete understanding. We cannot measure the exact agility created by one or the other, but we can say it is not Agile with a zero; it is very Agile with a 1 or it's 50/50 declared as .5.
Here are some general guidelines for thinking about the value. The guidelines are based on AMMERSE value questions.
- Is there a rule/constraint? Agile--
- Does the solution change with feedback? Agile++
- Can it be changed? Agile++
- Does it clash with the environment it is used in? Environment--
- Does it fit seamlessly into other environments? Environment++
- Is it Reachable to everyone? Reachable++
If any value gets a ++ or a --, then it must be declared as 0.5, if it only gets ++ values, it is a 1 and only -- values, then its a zero.
In Agile2, they list values like this
- Thoughtfulness and prescription.
- Outcomes and outputs.
Let's evaluate these with AMMERSE.
Agile2 describes Thoughtfulness as
"Thoughtfulness means considering context, and taking action only after one has attempted to understand the situation."
This maps to the Environmental value. The Environment in which you operate, otherwise known as "the system", is important as the context dictates and influences everything in that system. Being thoughtful can be Agile, but being agile is more than what thoughtfulness can do, it is about what decisions are made from the thoughts.
Stop at traffic lights when they are red
(Unless a runaway truck is hurtling towards you at speed)
Understanding the situation is also Environmental, as it cares about the context enough to evaluate it and take note of the details. Being thoughtful is not Minimal or Extensible. It could be Maintainable if you had a means of being thoughtful that was always Reachable. ie. It takes time to be thoughtful and study the environment, and there is no guarantee that you will understand it. It could be Solvable if your understanding is better informed, but it is also no guarantee of aiding in finding a solution.
We may think we understand our natural resources, the earth and how to use our resources sustainably, but it's quite a different thing to know how to accomplish this with the many complicated tradeoffs.
According to Agile2,
"Prescription means following predefined steps, as in a framework, unchanged and not tailored to the situation, without necessarily understanding or being thoughtful about those steps or what they are for."
This is not an Agile approach, as it follows a set of prescribed activities. This could be Minimal, as the prescription could be small in size, but there is no guarantee of the prescribed being Environmental (although there is always a chance). It is not Maintainable as following a prescription forever that does not foresee the future needs will most likely be rendered irrelevant. Prescription can be Extensible and Environmental, Solvable and Reachable, provided the steps are actually useful to achieve the outcomes, but there is no inherent guarantee.
Amplio has several principles:
"We can complete smaller items faster than larger items."
A(.5), Mi(0), M(0), E(0), R(1), S(.5), Ex(0)
This principle states that we can complete smaller items. It is unclear as to whether it is suggesting that smaller items are better than larger items.
It is not clear that reducing larger items into smaller items is better for the solution. If you value Reachable, you may agree with this principle. If you favour Solvable, you may think this principle may not be the best way to solve a given problem. From a holistic point of view, decomposing (reductionism) does not equal the whole (Holism).
Smaller items do not suggest outright agility. The context of the smaller items may not be usable until they are complete. It could be that when you complete several smaller items, it is enough, and you have saved time. Agility is therefore given 0.5.
We cannot manage what we do not see.
A(.5), Mi(0), M(0), E(.5), R(1), S(0), Ex(0)
The idea of "managing" brings in a fundamental set of values. This is a Reachable value. You are trying to reach the information, reach the learning and reach the information. It suggests that you should either go out and learn more so that you can manage it, or you should not manage it because you don't know what you don't know.
The principle pertains to Reachable and Solvable with some Environmental values.
Make learning a habit.
A(.5), Mi(0), M(0), E(1), R(1), S(0), Ex(0)
This principle is concerned with Reachable and Agile. You want to learn more iteratively to reach more. It relates to learning within your Environment.