On the 13th/14th of October 2023, I attended my first open-space conference: CitCon
CITCON (Continuous Integration and Testing Conference) is the Continuous Delivery conference that pre-dates the term "Continuous Delivery". CITCON brings together people from every corner of the software development industry to discuss Continuous Delivery and the practices (e.g. Continuous Integration and Testing) that go along with it.
TL/DR: It was so much fun. The energy of ~50 like-minded people coming together, talking about things they are passionate about - it’s difficult to put into words. I’ll be back and I will bring colleagues.
What is an open-space conference?
It’s a bit like lean coffee on steroids.
There is no agenda until the attendees create one.
The topics are proposed by attendees who are willing to run a session and added to a scheduling board. Over a beer or two, the scheduling board is then arranged by all attendees (because one facilitator can’t run two sessions in the same time slot, some sessions require display equipment for a presentation - or chatGPT access etc).
For a full description, including the law of two feet, have a look here.
Sessions
These are the sessions I attended - I’m not going to do a full write up, for that you can visit the citcon wiki.
Pros and Cons of Radical Candor feedback approach
This is where it gets interesting. I was going to attend the ‘AI for real’ session, but started to chat about the meaning of certain words in the Radical Candor matrix with the facilitator (the attendee who proposed the topic) over breakfast. While I had heard of Radical Candor, I didn’t really have a full picture of what it’s all about, but our conversation got me interested. So I went to this session instead. And boy am I glad I did. It was such an interesting chat about giving/receiving feedback, about Radical Candor in general, and examples of where attendees had worked in a ‘Radical Candor’ environment and how they perceived it.
My key-takeaway, aka ‘Aha!’ moment, was that positive feedback is often less useful, because it is often generic (“good job, keep doing what you’re doing”) vs negative feedback, which is more often specific. So, give more specific positive feedback (“The test coverage of this new service made it really easy to update when you were on holiday, well done!”)
Also, giving (useful) feedback is hard.
How to learn from frustration
I was really looking forward to this one. As a longtime fan of Troubleshooting Agile and the book Agile Conversations, doing some conversational analysis guided by @jtf himself, was a real treat. Jeffrey was talking about how getting frustrated in a conversation can be (should be!) a trigger to change our own behaviour to become more curious and transparent. Also, being wrong about something feels awesome. In fact, it feels exactly the same way as being right. Until the moment where you learn that you are wrong.
Hallway track: Why most companies don’t do CI
I was surprised that this topic didn’t get enough interest to really warrant a session, so I spoke to the person who had suggested the topic and we agreed to talk about it over lunch instead. Great chat, covering several topics like what prerequisites you need to enable true CI, how to slowly remove impediments like async code reviews (see my other article on pair review ) and how to deal with engineers who refuse to adhere to even the most basic work ethics. Since CI is a practice on the path to the end-goal, Continuous Delivery, we also looked at https://minimumcd.org.
Speaking of hallway track - talking about true CI, we also had a quick interlude with @jtf about this where he drew and recommended the book Crossing the Chasm, in reference to why people don’t adopt true CI. In the picture below, ‘Better’ are the innovators and some early adopters. In software development, these are the guys doing XP. FOMO, aka early majority, can be seen as ‘Scrum’ and “Standard”, aka late majority, can be seen as “SAFe” or similar. The chasm in this case, is to be overcome to adopt true Agile (including CI). The difference (the chasm) is here the motivation. The innovators and early adopters care about improving and by doing so, getting better business outcomes. Where the FOMO crowd doesn’t want to be left behind so they are looking at the quick win (“those guys over there are getting good results with Agile, we should do Agile, too”). Welcome to the Cargo Cult.
Is Agile completely obsolete? What’s next?
Here we came to the conclusion that Agile is not dead - quite the opposite. It’s just that many companies realise that ‘Scrum’, ‘SAFe’ and other ‘by the book’ implementations are just cargo cult and don’t necessarily produce better business outcomes. Instead, the ‘Agile toolbox’ is becoming more popular and so are XP practices. Maybe our view was/is skewed by the conference demographic of people who are really passionate about continuous improvement, but several people reported similar observations, so we can only hope!
St Pauli School of TDD
Loved this one. I had no idea there are that many schools of TDD - In fact, I didn’t know there were any schools of TDD. I really enjoyed learning the history of some of those schools and seeing the Diamond TDD Kata, using specifically the St Pauli School of TDD. Something I will try to practice at home to improve my own coding.
If you speak/read German and want to know more, have a look here.
Systemic Improvement
Here we spoke about thinks like value stream mapping, local vs system improvements (systems thinking), learning/improvement in general and OKRs (and their pitfalls) as a specific method to measure improvement over time. Key Aha! moment for me: To improve, you need to start with a baseline and measure against it - otherwise, how do you know if you have truly improved? (And don’t make the mistake of tying performance reviews/bonuses to your OKRs - otherwise you’ll create incentives that will skew the results).