This post is the 4th 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.
The exercise with Cynefin as a categorization framework
The simple idea that started this exercise was to place each Agile practice firmly into a Cynefin domain. From this initial proposition to the finishing line, we learned many things while trying to overcome the obstacles faced during the exercise.
A first major obstacle
became evident almost immediately: Perspective. Some of us were looking at the problem of using an agile practice. For instance, when a team begins to adopt Continuous Integration, is this a challenge in the simple, complicated, complex or chaotic domain?
Some others were looking instead at how an agile practice can be used to move an existing problem from one domain to another (and hopefully make it easier to solve). For example, can the practice of having a 10-Minute Build move the problem of having the code base in a consistent state from the complicated to the simple domain?
After we had discovered and clarified this ambiguity, we chose to look at both aspects of Agile practices without confusion. We created a first list of Agile practices, selected one practice to start with and then continued the exercise.
As the practices were discussed
, another ambiguity surfaced: A practice referred to by name can signify different things to different people. As an example, when discussing about Continuous Integration as a practice, we discovered that for some participants, this practice included both the 10-Minute Build and One-Click Deploy practices. For other participants, these were three distinct practices.
Test-Driven Development was for some participants more about documenting requirements, and for others more a design practice.
This is enlightening, but not surprising. We come from different teams, different projects, organizations and cultures, and haven’t worked together before. One may say that this ambiguity merely reflects the semantic polymorphism of practices observed in the agile community. In order to build a common language and common understanding, we first had to describe and find a consensus on the main purpose of a practice.
Is it possible to categorize Agile practices?
This question popped up during the exercise and gave us the opportunity to clearly state that the goal was not to create a generalized categorization of Agile practices and that the views that were emerging from the exercise were representative of the specific participants points of view, their experiences in specific projects and contexts. Finding a definitive and generally valid mapping of the Agile practices onto the Cynefin domains is probably not achievable, and was not the goal of this exercise.
The exercise was recorded on a shared document, which was used to facilitate the discussions:
Agile Practices, purpose and domain