A decade ago, a Scrum Trainer called Krishan Mathis explained in a simple what agile means to him. Agile is “Inspect & Adapt”, treat people like adults, ask the team and delivery each time. That mantra is still haunting me a subtle way.
Ask the team and “Treat people like adults “is about coherence. It makes no sense if you want to control and micro-manage a self-organized team. It sounds like an oxymoron.
Inspect and Adapt is resilience. You accept new things because it makes sense. And you leave old stuff because it makes sense too.
Delivering each time is resilient. It is about accepting that the work is done without the need of over-engineering. It is about agreeing to maybe being wrong and criticized. Delivering addresses a crucial part of a complex system it gives the sense of dynamics and impact.
From a flocking behavioural perspective, agile is using all the six principles in its core:
- Point to the destination: goal, roadmap, true north, vision. That destination must be “obvious” for all participants in that system called team or project.
- Avoid a collision: this alignment. In scrum, the ceremonies or “inspect-and-adapt” opportunities or meetings are calls for alignment.
- Non-necessary planning skills: here is one pain point. On my way to set up scrum or any agile models, the planning sessions are not about planning. These sessions are about having a conversation and get aligned. “Wisdom of the crowd” is the estimation coming out of a “planning poker” session. When the critical part is not the numbers but why one team member think that is complicated and why another think it is simple. The discussion that the team has is the cornerstone moving from “Poiesis” to “Praxis”.
- Follow the line: Scrum is particular for the edges. The scrum meetings are the new routine giving the cadence of a team: the sprint. The sprint length is fixed like every meeting are time-boxed. That discipline gives, curiously, more freedom to manage your time.
- Emergent behaviour: The purpose of the Retrospective is not only to collect the lesson learned or to detect new tools or techniques. The objective is to improve the space for the team. It is based on how the team members behaved and for what reason. A great agile coach with System coaching background can identify such outcomes and guide for smaller or larger space for the team.
- Separation: A team is not planned forever. You have to give the option for termination. The consequence of not taking departure into account are crossover activities or dependencies and scaling issues. If you provide the teams with the possibility to separate, then they adjust to the new destination.
How does scrum look alike when applying Agile Systems Dynamics then?
You take the basic rules defined in the Scrum guide and improve it with these eight principles:
Set the stage
The sprint is a safe-to-fail container because it is protected. Nobody is allowed to disturb a Sprint.
In the beginning, the most critical step is to start the journey. Here, the Product Owner will meet the customer and ask him what he wants.
Then there is the kick-off where the whole team is meeting the customer. The purpose of that meeting is indeed to create the project system. But it is more likely the momentum when the team tries to understand what the customer wants.
Then the Product Owner gathers with the team and asks what each individual has understood. And, together they are building a couple of prototypes as options.
At the next meeting with the customer, the review, the team is showing up these options.
Everything is not an option
During the review meeting, the customer look at every options and he has to decide which options are close to his aims. Here the customer can’t keep all options open. The non-selected are removed from the team´s backlog.
During the next sprint, the scrum team is working on the previous options by refining them.
Then, at the next review, the customer shortlists that list of options again.
“Decide” is a two-ways resilience — one way the customer has to select. The second way, the team has to let go something maybe more technically impressive.
Avoid never ending stories
Sometimes, the team keeps stories (items) forever in their backlog. That is not a good idea. Some topics become obsolete or no longer needed. Then you remove them.
A story like a user story has a one sprint deadline, an epic (a big story) has a quarterly timeframe. That approach helps to sharp the development. And it forces to rethink from a different perspective of the nature of the work to complete.
Human relations is vital in agile. It is all about the interaction of “agents” in a system. That interaction is measured thought the level of communication. A sprint runs in a “Complex” mode, and it is protected from external interferences threatening that behaviour.
Keep the balance
The agile dynamic is all about the balance between “doing the right thing” and “doing it right” or between “demand” and “development”. That balance is a permanent negotiation between function and technic, business value and knowledge value. It is the domain of “Praxis”.
What do you really want?
Burndown charts are useful tools that emphasis how a team behaves. That chart must ideally burn down to see progress and allowing shifting to another customer-centric topic.
Burnup charts are interesting for the R&D part. R&D has a different dynamic switching between “Complex” and “Complicated”. The purpose of the research is to deliver innovation or options for the development teams.
The “traditional” step graph represents “agility” where the tools are not properly used and understood. Usually, you will find the chaotic behaviour of individuals working for another person in parallel of the project. “No, pigs here.”.
Set the pace
A sprint is a beat, the pace of a team.
The sprint length remains the same until the team separates. The range is always depending on the complexity of the work and how the organisation is set up.
As a conclusion, I didn’t address how to build a system in this post and nor what a system is. One thing for you to take into account that the system works when decisions are bringing into the system and not outside-in. If you are a scrum practitioner and your Product Owner isn’t part of the team. He or she is not in the system.