This post is the 5th and final post of
the series co-authored with Michael Podvinec where we write about the exercise and some of the insights gained:
1 -
Intro
2 -
Sense-Making
3 -
Categorization
4 -
Our exercise
5 -
Key learnings
Michael is a molecular biologist by training, and is convinced that agile methods have a place in all domains where we're commonly dealing with complexity and uncertainty, such as biomedical research.
He really promises he will soon publish more regularly on topics like these on his blog. Until then, he suggests you to follow @mpodvinec on twitter.
Cynefin & Agile, learning from the exercise
About Cynefin and Agile
Cynefin and social complexity
provide a theoretical foundation for many of the Agile practices, they explain why agile practices works. This exercise put together the practices with the theory because of this I got a better and deeper understanding of Agile. Putting theory together with the practice can also help to advance the practices and spot false progress.
This exercise
also improved my understanding of the Cynefin framework and of what are the appropriate approaches each that domain.
Key learning
Agile practices are dynamics
in the sense that they are designed to move things between domains. For example to move away from the chaos domain or move from complex to complicated domain, or i.e. to move away from simple or move from complicate to complex. So some movements would decrease the constraint to increase innovation and uncertainty while others would do the opposite. Other movements will add or remove connections.
It is not possible to remove complexity
, complexity can only be absorbed or released (i.e. in the team structure, in team's habits and practices and skills in use, in team's ability to process information and generate meaning, in team's ability to manage conflict and generate consensus).
More learning from the exercise
From this group exercise
I understood the importance of accepting ambiguities, giving space from multiple different points of views and personal experiences, recognize the existence of incomplete information and fragmented realities. All this is necessary to understand complex problems.
I also had the opportunity to get some more insights about Agile:
- Relaxing and adding constraints is one of the main ways for Agile practices to move a problem between domains. For example having the Standup meeting at the same time and place everyday eliminate the need to re-organize daily the meeting, this means that 2 additional constraint reduce the complexity. Another example is a green build that enable to get the latest sources or to check-in in every needed moment or the Continuous Delivery practices give the possibilities to release or rollback a new version every time it's needed: the constraints added by these two practices move problems in the directions from complex to complicated domain.
- Reducing the number of connections is another way to reduce the social complexity, for example the Product Owner is a single connection between the team and all the stakeholders and the Scrum Master is the single connection between the team and the rest of the company when dealing with obstacles
- Adding the proper connections is a way to add complexity to move away from the cliff between the simple and chaotic domains where there is the risk to fall over the edge with catastrophic consequences.
That translated from the Cynefin language means that when the project is complex but the adopted approaches are the ones suitable for the simple domain this can cause irreversible events that move the project into the chaotic domain. While adding complexity really means here add the capability to deal with complexity in the team structure.
For example the Agile practices of releasing early and often and getting feedback from users add the connections between the team and the users, this help to avoid underestimating problems that could otherwise be extremely expensive if detected late. Or for example the Agile practices Collective code ownership and Shared responsibility increase the connections and interactions between team's members and teams.
- Reducing the number of people involved is another way to reduce the social complexity and Agile practices enable a small team of skilled trained people to be more productive that a larger team
- Introducing a new Agile practice during a project can increase the complexity before reducing it, as it increases connections and interdependency between team members. Then, at a later point, the practice increases the ability of the team to absorb complexity. For example, agile practices like Collective code ownership and Shared responsibilities amplify the frequency and the scope of the interactions between team members and this can raise the social and technical complexity until the members acquire the technical skills and the team structure evolves to deal with the new situation. After that, the new skills and the new structure enable the team to absorb and so reduce the complexity inherent in the project.
- Because of the ambiguity of language, even people very experienced in Agile can associate different meanings to the same practice name (i.e. velocity, lead time, TDD, CI), here are some of the reasons:
- some people understand the practice as the convention the team agreed on and actually follows, with the exceptions and adaptations required to deal with practical circumstances, some understand it as described in a book
- different people have different backgrounds with different contexts and projects where they first learned the practice
- the complexity of some of the Agile practices that bring inherent ambiguities (congruent with this comments from Martin Fowler in Rigorous Agile definitions where he expands on how a lack of rigor in Agile definition is part of the defining nature of agile methods
- An Agile practice that involves a software tool can initially increase the complexity more than a practice that involve only people and no tools. For example, Continuous Integration means that every broken build affects all the team members just like a failing test does with TDD and requires an immediate reaction to fix the problem. In contrast, a practice that involves only people, like the Standup or the Planning Meetings can be easily adapted and regulated time by time (i.e. start and length of the meeting)
I recognize that different people use Cynefin and complexity models in different ways and different learning can come from that. So I'm curious to ear about your experiences.