One of the most interesting aspects of writing computer software, at least for me, has been the collaborative nature of what we do. I enjoy seeing the various ways in which a team can be organized, or organize itself, and the results of each of them. What makes software development effective, in the end, is an effective team that can deliver quality solutions to their customers in an efficient manner.
That’s why lately I’ve been absolutely fascinated with the affect agile practices have had on my team. The results have been absolutely amazing, but none of them come even close to comparing with the power of self-organization.
Self-organization has been one of the driving factors of the success of our team in the past few months, and I believe one of the most important aspects of our behaviour is our sprint retrospectives.
What does Self-Organization mean?
Self-organization is a process of attraction and repulsion in which the internal organization of a system, normally an open system, increases in complexity without being guided or managed by an outside source. Self-organizing systems typically (but not always) display emergent properties.
Self-organization usually relies on four basic ingredients:
- Positive feedback
- Negative feedback
- Balance of exploitation and exploration
- Multiple interactions
But what does that really mean for a software team?
Well it implies a state of flux and constant change. It also implies that outside forces will eventually affect the team and influence its growth. However, these outside forces are not allowed to guide or manage the growth of the team. The team will, instead, react to the pressures of the outside world and adapt to them in order to operate more effectively. It really is a powerful statement, but how on earth does it work?
Positive Feedback/Negative Feedback
One of the easiest concepts to understand is feedback, both in positive and negative form. In fact, this is why retrospectives are as powerful as they are.
The purpose of a good retrospective is to look back at the previous sprint or iteration, and identify what things contributed to the successes and failures of the team. Often teams will identify many positive driving factors which helped them, as individuals, feel as if they were doing a good job. They will also identify negative factors which slowed them down, or made them feel as if they could have done better.
For a team that’s attempting to self-organize, this feedback is absolutely vital. Without it, the team would push forward, often missing out on key practices that lead to extremely effective behaviors. They would also miss out on identifying what practices are preventing further success.
As an example, in a recent retrospective the team I am currently on identified that team professionalism has been declining. While we are still producing high-quality results each week, we’ve allowed bad habits to enter our daily workflow. For example, because we felt so comfortable with each other we had begun to use of sarcasm and off-humour to illustrate our points, instead of more professional and intellectual alternatives. While in small doses this can be an effective stress-relief, our retrospective allowed us to identify the fact that team meetings were staring to actually take longer because it often harder to reach a team consensus.
However, the same retrospective identified something else far more illuminating. Occurrences of the unprofessional behavior actually seemed to be directly related to team frustration, which was often because we had failed to “fail early” on difficult tasks. Since identifying this pattern, we’ve started to be able to identify problems our short sprints (1 week) as early as the second day, when it would normally take until “crunch time” on the fourth day to realize the danger.
Balance of Exploration and Exploitation
Identifying positive and negative aspects of a sprint is an excellent way to exploit the knowledge and experience the team has gained, but another key factor of a healthy self-organizing system is a balance between exploiting existing knowledge, and exploring new alternatives.
This is where another key part of retrospectives comes in: “Things to Try”.
Identifying what went wrong in a sprint is an excellent starting point, but that knowledge would be of little value if the team didn’t have ideas for how to fix the problems or prevent them from occurring in the future. Perhaps even more importantly, if the team isn’t aware of ways in which it can repeat the positive factors of the sprint, the benefit from them may quickly be lost.
After discussing what we felt went right and wrong within a sprint, my team shifts its focus to what things it can try in the future to continue to achieve excellent results. However, keep in mind that this is a balance. We can’t try all of the ideas we have every single week, the effort would overwhelm us and we would spend all of our time exploring new disciplines while failing to exploit our existing habits. The practice on my team is to allow each team member to vote on any two of the ideas presented during our “things to try”. From there, the items with the top two votes are adopted as team discipline until they become habit, or are found to be of little value.
The last of the ingredients defined is the existence of multiple interactions. For clarification on this one, I actually decided to dive down to the source article:
Swarm intelligence: from natural to artificial systems, Page 11:
(Self Organization) generally requires a minimal density of mutually tolerant individuals. Moreover, individuals should be able to make use of the results of their own activities as well as of others’ activities.
This, perhaps, identifies the most important part of the sprint retrospective: the team! What makes agile, self-organization, and a good retrospective all so successful is a good team full of intelligent and talented individuals who truly care about their work. The retrospective is one of the many ways in which the team interacts. Daily scrum-meetings, for example, are extremely valuable for ensuring continual progress, but are designed to identify roadblocks. This isn’t the type of information that members of the team can easily make use of, but it is something that should be acted on.
The primary artifacts of a successful retrospective are knowledge and action. The team is empowered with knowledge of what works, and what doesn’t. This way each team member can learn from the experiences of their teammates. The team takes action based on this new knowledge, in order to help become more effective and efficient.
While there are many aspects of the agile mindset that make a team effective, I believe that one of the most powerful tools we have available is the retrospective.
A team that is empowered to self-organize is empowered to remove its own roadblocks, and do what it takes to build better software faster.
A good retrospective identifies common problems, key positive practices, and encourages the team to change, grow, and adapt based on those realizations. By doing that, the team can become more efficient, produce high-quality software, and achieve excellent results. Without that, a team will get bogged down in “the rules” without ever stopping to figure out if they are being helped, or hindered.
“I have but one lamp by which my feet are guided, and that is the lamp of experience. I know no way of judging of the future but by the past.” (Edward Gibbon)