Scrum & Cynefin & Retrospective
Scrum forces to reduce and simplify the work (problem) that tends to enter the COMPLEX environment in a Sprint path of less than a month. In this way, it allows work to be carried out in a COMPLICATED environment.
By requiring every Story to return to a value-creating increment (vertical fragmentation), it also tries to prevent the team from keeping the work in COMPLEX by dividing a big job into phases (analysis, design, development, etc.) (tricking the Sprint).
It also recommends Daily Meetings to tackle work that is still COMPLEX despite being divided and downsized. Daily meetings allow for trial and error to resolve tasks that still have a high COMPLEX level.
While the work within the Sprint is COMPLICATED, the way the team interacts internally and with stakeholders, the path it takes, the processes and standards it applies to carry out the work remains COMPLEX.
Interaction, process, standards and practices remain COMPLEX and need to be learned by trial and error.
Retrospectives are the nodal points of trial and error cycles to work well, effectively and efficiently together. For this reason, the agenda during Retro’s should always be:
What was the controlled experiment? What were the results? What will be the controlled experiment in the new sprint?
Teams that have not developed an awareness of experimentation tend not to do the retrograde after a while. The Scrum master should observe the experiment performed during the sprint, take notes and design a few experiments to suggest to the team.
On the other hand, since every change in the team composition (mission, members, etc.) will change one or more variables, additional experimentation in those sprints becomes pointless, the new conditions themselves become an experiment, and a lot of what has already been learned can go up in smoke.
In retro meetings, the words experiment, hypothesis, theory should be used liberally. Retro resolutions can never be laws, codes or rules; at most they can remain theories or general principles.
Applying a Scientific Approach (Complexity Buster) to High Performance Teamwork
Step 01 — Identifying the Problem
The problem should be stated clearly and unambiguously, in understandable terms. The problem should be experimentally investigable.
Problem: Failure to Work in a High Performance Team
Step 02 — Collecting data related to the problem
The information obtained about the problem through observations and experiments is called data. At this stage, data are collected.
Data: Performance Results, Beliefs, Attitudes and Behaviors of People, Themes of Interactions within the Team, Themes of Interactions with Outside the Team, Events During Work, Themes of Manager Interactions, Themes of Stakeholder Interactions, System Interactions
Step 03 — Hypothesis Formulation
It is a proposed temporary solution to a problem. A good hypothesis should be appropriate to the available data, should be open to questions and predictions, and should be able to make connections between the data.
Hypothesis: The manager attending the Daily meeting makes the team nervous and reduces transparency.
Step 04 — Forecasting
Explanations based on a hypothesis.
The template for predictive sentences is “If …….. is …….. , then it is …….. .”
Hypothesis: The manager attending the Daily meeting makes the team nervous and reduces transparency.
Forecast: If my hypothesis is correct, Ahmet will not mention yesterday’s incident with Mehmet in the Daily Meeting.
Step 05 — Conducting a Controlled Experiment
These are experiments conducted to check the accuracy of a hypothesis. In a controlled experiment, only one of the variables affecting a problem is changed and the others are kept constant. In this experiment, two groups are used, a “control group” and an “experimental group”. The control group is the group in which the property under investigation is most ideally realized. The experimental group is the group in which the characteristic under investigation is tested.
Controlled Experiment: Calling the manager to the Daily Meeting or ensuring that he/she does not attend the daily meeting
Control Group: Meeting not attended by the manager
Experiment Group: Meeting attended by the manager
Step 06 — Drawing Conclusions from Data
In the process of experimentation, some hypotheses are strengthened, while others lose validity. Two situations arise as a result of controlled experiments.
Hypothesis correct: A hypothesis is true if controlled experiments prove it to be true.
Hypothesis is wrong: If the hypothesis is wrong as a result of controlled experiments, the hypothesis is changed, a new hypothesis is established and the above steps are repeated in order.
Step 07 — Developing Theory
Hypotheses that are continuously supported by new data are called theories. Theories are ingrained hypotheses. Although theories are close to reality, they can be refuted.
Step 08 — Law (Code)
A scientific law is a proven assumption. The laws of physics are usually expressed in mathematical relations. Laws usually describe a single event, while theories take into account an event and many related events. It is very difficult to derive laws from retrospectives.
Conclusion
The team needs to treat working as a team with stakeholders and creating high performance as a problem and try to solve this problem through hypotheses and theories throughout the Sprints.
The architect of all this work is the Scrum/Kanban Master.