In short Samman coaching consists of two parts, a learning hour and working in an ensemble. The learning hour is interactive and tailored to the needs of each team. It is a way to explore new skills and concepts in a safe and well prepared setting.
The ensemble working is done in production code and is coach facilitated. I have several posts on working in ensemble and its benefits
I claim that this is far more powerful than it initially seems, at least when done right. I want to compare it to regular courses, since I think they are the closest alternative.
Samman technical coaching is done with your team. No more returning from a course and trying to convince the others of the value in what you learned. It is also adjusted to the knowledge level of your team and facilitates learning and teaching within the team. Samman technical coaching provides new knowledge, a learning culture and tools for learning together.
Learning how to deal with complex problems is hard. You need a complex problem to solve, understand that complex problem and still have cognitive capacity left to learn a new tool or method to solve it. When working with problems found in your production code, you already understand the domain. That leaves more room for learning the tools, without having to use an unrealistic and limited problem. (The coach needs to know the material well enough to teach it in any codebase.) This brings more confidence in the tools and skills, since the team can see that they can be applied in their reality. (If the tools do not work in the current production code the coach will have to adapt the plan for the learning hours. That feedback is not possible with traditional courses.)
Happy families are all alike; every unhappy family is unhappy in its own way.
– Leo Tolstoy in Anna Karenina
The goal is code that is dependable and easy to change. How to get there is different for each team. As a Samman technical coach you listen to the team and read their code. The goal is to provide as much value as possible in a digestible way. All topics are presented one hour at the time, often in small steps. That way new concepts have a chance to get repeated and to stick. As it is directly tried in the production code (it does not have to be producing value, but it can) the team can try things out at their own pace. This creates an offer of knowledge that can then be pulled into everyday use. Change is best done without fear. Samman coaching provides the specific tools that your team needs for change, but in a way that is safe and fun.
Samman technical coaching brings the team together. By using familiar production code it can teach more complex topics. As the content is tailored to the needs of the team, and proven useful to them in their codebase, it sticks and provides value in the everyday work for a long time.
]]>IQ is a measurement widely used, though problematic, due to its history and how it has been used. (I recommend this series by RadioLab)
For a group working together the same phenomenon is called “collective intelligence factor”. Just like individual intelligence, it aims to describe why some teams have consistent better performance, independent of the nature of the task. Research by Woolley et al. shows that there are two major factors that contribute to how intelligent a group of people is.
- Correctly reading the emotional state of others
- Equal contribution in conversations and turn taking
Compare this with aspects of ensemble programming.
Regular retrospectives create a place for learning about others experiences. Retrospectives are a great way to improve your work, and one aspect is practising empathy. It creates a forum for sharing your perspective, including how you feel. An ensemble session ending with a short retro builds a feedback system for the team interactions.
Talking on a timer creates a framework for distributing contribution. We are not very good at judging how talking time is actually distributed. Strict ensemble working, with a timer, helps us get input from everyone. It could also help us get a better sense of what equal talking time feels like.
The interactions of a team is more important for the result than their individual intelligence. That is good news. It is hard (or even impossible, depending on definition) to improve ones intelligence. The dynamics of a team, and how we read and regard others emotions, can develop.
If you want to improve the general performance of a team, help them:
One way to do this is through ensemble working, ending it with a short retrospective.
]]>In ensemble programming we can use the same principle, but for a forest of developers. Everyone in the team does not have to be good at everything. The important thing is that the team has enough psychological safety so that all developers are “independent” and can add to the total result.
This is one way to understand the power of ensemble programming.
]]>In this text I will try to explain why this is so awesome by talking about processing units in a computer.
Why would you use more than one processing unit in a computer?
I will use the answers to this question to show some of the things I like with ensemble programming.
Processing units have limitations, but if the code is written in a way that let them collaborate, you can let them join forces. Threading will also allow a process to go do something else, without the rest being blocked. The same way that computations are distributed in a GPU, cognitive load can be distributed in an ensemble. Also — if you need to look something up, one person can “spawn” and consult their laptop, returning with more knowledge when it is their turn to navigate. The ensemble can solve another part of the task at hand during that time, not being blocked.
Having both a CPU and a GPU in a computer is standard today. They are good at different things, because they work differently, but need to collaborate. In an ensemble you can bring a differentiated group of people together, and thus solve problems better.
When put in an airplane, or voting machine, a computer needs to have protection against bit-flips. (Radio Lab has a nice piece on it here) Basically you let two, or more, systems perform the same task and that way, you can see if one of them has been influenced by cosmic rays. People make mistakes without cosmic rays, so multiple people validating what is happening in the code is a good thing.
Having a backup system is always nice. For software today there can be an orchestrated cluster, that is making sure that there are always “computers” available serving the customers, even if one, or more, instances are down. Coding in an ensemble is tiring, since there is so much action. But it is ok to take a break. And to be home sick or take vacation is not such a threat to the productivity of the team as it might be otherwise. Both leaving the ensemble for a shorter time, or a longer, will be fine, since the structured collaboration transfer knowledge.
So, this is my try to explain some benefits of ensemble programming with hardware metaphors. Hope it helped.
]]>So what if we made all time touch time with total disregard for individual productivity? If we instead optimize for the groups productivity, making sure that a feature never has to wait for information needed to be completed.
With a batch size of one and only one workstation, where would we end up?
And people are surprised that using ensemble programming can be a competitive advantage.
]]>