As an agile coach, I knew how self-organization manifests itself in various ceremonies. There is a brilliant blog by JV – one of my colleagues at PM Power – that elucidates the behavior of self-organizing teams in various ceremonies. I would observe the behavior of the team in many of these ceremonies and guide the teams directly or through the scrum master to influence the behavior where I thought a change was necessary.
I then came across the C-D-E framework by Glenda Eoyang on the conditions for self-organization. We will quickly take a look at it and explore some of my own experiences in that context.
- Container – this is the boundary within which the self-organization happens. In agile, typically, management puts a team together and gives them goals to achieve. A team cannot choose to add or remove team members and team cannot decide their own goals. They are expected to organize themselves within these constraints.
- Differences – in agile, this represents the diversity within the team. Differing skill-sets, experience levels, domain knowledge, gender, personalities, and location are some of the typical reasons for differences. These differences influence the way the team organizes itself.
- Exchanges – these influence how the team self-organizes. It leaves team members with new knowledge which should energize action through self-organizing. Examples of exchanges are interactions (dev-dev, dev-PO, dev-func manager etc.), recognition & reward scheme etc.
Experience #1 – Need more testers!
Here was a team that had 6 developers and 3 testers – team was in early stages of agile adoption with low level of test automation. One of the testers was dedicated to test automation and was not available for any manual testing during the sprint. Team could not complete the committed stories within a sprint due to lack of manual test effort. Team fell short of the committed stories. Product Owner was unhappy with the release progress. Test Manager said he could not allocate more testers for the team – no budget. As a coach, I intervened and asked questions during sprint planning – ‘how could this lack be addressed by the team itself?’ Some of the developers in the team volunteered to do test execution as long as the testers would write the test cases – basically re-organize themselves to address the imbalance caused by ‘differences’ in skill-sets. In spite of that, the team could not progress as much as they wanted to. As a coach, I realized that allocation of resources to the team was not within the influence of the team – the ‘container’ needed to be altered. As a coach, I (along with the scrum master) had to have conversations with the functional managers to find ways to pool their budgets and replace one developer with a tester. This change helped the team to organize themselves better and improve their throughput!
Experience #2 – Where is the design?
Here was an agile team which had done well to deliver on the last two releases beyond the expectations of the product owner. In the third release, team struggled and achieved only 30-40% of their committed stories in the first two sprints. Many regression defects started appearing and integrated code did not stabilize within the sprint. As a coach, I asked the question in the retrospective, ‘what is different about this release?’ After a brief discussion, it came to light that the earlier releases had enhancements to features while this release had couple of new features. After a few more probing questions, team came to the conclusion that the design of the new features needed more discussion within the team. A new process was established – step 1: team will flag stories that needed design discussions; step 2: there would be specific meetings held with the entire team to discuss the design of those flagged stories within the first two days of the sprint – essentially coach enabled the creation of a new ‘exchange’ within the team. This helped reduce the regression issues and helped the team to improve its throughput!
Experience #3 – Let us look at data
Let us look at another intervention that facilitated self-organization. This team, although new to agile, was doing reasonably well in delivering their committed stories. There was one issue though – some ‘done’ stories started showing some issues in later sprints. Team discussed the issue in their retrospective – without any conclusions. There was no finger-pointing but they could not figure out how to tweak their processes. When I asked the team “what data would help them work out a solution?”, then they realized there was hardly any data to discuss the issue objectively. Team decided to start capturing relevant data like ‘number of unit tests’, ‘number of tests by the tester’, ‘defect analysis to identify source of defects’, etc. When they reviewed this data in each sprint retrospective, they started figuring out suitable solutions. Essentially, coach enabled a new ‘exchange’ – sharing of quality-related information.
In conclusion, I feel that by influencing the container, differences and exchanges, a coach can facilitate the process of self-organization and improve the performance of the team!
