ThoughtWorks University: Retrospective Coherence
I recently came across Joseph Pelrine’s blog post where he describes the way that you might go about organising a great party.
He describes a party that a friend of his hosted and all the things which contributed to it being great, such as the people you invite, the music that is played, the food and drink that are served and the conversations that are had.
If you then wanted to replicate a 'great party' you might think that you could just replay his friend’s party, with the same guests, same music, a script of the conversations had and so on.
Pelrine points out this sounds ridiculous and suggests retrospective coherence can help us understand why:
One thing that makes complex systems complex is their causality...in a complex system, though, the causality emerges as the system emerges. As the party goes on, the reasons for its success become established. After it’s over, you can say that a party was a success, and that these people were there, this music was played, and this much beer was downed — but you cannot say that the party was a success because these people were there, this music was played, and this much beer was downed! ...at the end, you can say how you got to where you are, but you can’t guarantee that by doing exactly the same things, you’ll get to the same place again — and you probably won’t. In complex systems, we say the causality is retrospectively coherent.
We’ve been having a similar problem in trying to understand what makes a ThoughtWorks University term run successfully and trying to summarise what we learnt for the trainers of the next term.
In our case it’s more clear that just copying what we did probably isn’t going to work because some key factors are going to be different.
To start with, the trainers for ThoughtWorks University 22 are going to be completely different from the ones for ThoughtWorks University 21 since none of the trainers are staying on.
This automatically makes a difference because the people leading the training are going to be completely different, will have different strengths, different ideas about how to teach and so on.
The number of people attending will also be significantly different - there are planned to be two groups of 25 attendees whereas in the last TWU there were only 13 attendees.
This means that doing coding dojos the way that we did probably isn’t going to work as well because the group is much bigger and there’s more chance for people to get bored.
When we were doing a trainer retrospective a couple of weeks ago we found it quite difficult to know exactly what we should be documenting for the next group.
We eventually came to the conclusion that it wouldn’t be enough just to outline what we did but that we should also explain why we did that and also include the feedback that we got from the attendees.
Jim suggested that it was probably necessary to train 2 or 3 universities before you would be able to see a common theme across them and have some idea of what seems to work each time.
The learning for me is that although it’s been much more obvious that copying an approach won’t work for ThoughtWorks University, I’d be more likely to advocate copying an approach I’d seen work before on a delivery project!
While discussing this with Frankie he pointed out that it’s still useful to start out with a set of 'rules' that we think will work but then be prepared to change our approach based on the feedback that we get.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.