I’m trying a slightly different style this week, let’s see how it feels!
Four Things That Happened
One
It’s the end of ProDev’s quarter, and we celebrated with a … science fair. We’ve done one of these before and I absolutely love the creativity that comes out of a such a simple proposition. Each team prepares a “stall” that we take into our clubhouse meeting room and we can go around and see what each team has done during the last quarter.
We had:
- Super-detailed artwork on movable wipe-boards
- Large monitors showing off new reporting capabilities
- Kahoot quizzes about our data platform’s learnings
- And more …
We themed ours on our Opsgenie integration and had “3 Wishes” that we’ve fulfilled during the last quarter.
These events are a great way to down tools (kind of) and create something to show off what we’ve been working on - a side-effect of Agile/XP that I’ve observed is that working in vanishingly thin slices and focusing on incremental delivery removes a lot of the sense of progress as we’re only taking small steps.
Events like these science fairs give us a way to take a step back and recognise an entire quarter’s worth of work.
Two
Shift have been informal adopters of the Occupy Hand Signals as a way of self-moderating group conversations and making sure everyone has opportunities to speak whilst avoiding the “loudest person wins” degenerate case.
We learned this technique from observing another larger team (their team lead wrote about it here) and found ourselves picking up the very basic signals like “I would like to speak” and “I have a direct response”. Over time we’ve gotten pretty good at the self-enforcement part, such as calling out “X first, then Y” when two people put their hands up to speak.
One of our working agreements in our last retrospective was that we would formally adopt this for meetings of more than two people - a largely ceremonial action but it’s now encoded within our working practices.
There’s also a great GDS blog-post about using these signals.
Finally, I read a brief Twitter thread about conversational interactions, the seed of which was this article - I like to think that over the last few years I’ve become more a member of the Church of Strong Civility than the Church of Interruption.
DOCTRINES OF THE CHURCH OF STRONG CIVILITY
Thou shalt not interrupt. Thou shalt speak briefly. Thou shalt use physical cues to indicate your understanding and desire to speak.
Definite food for thought, and a reminder that conversations about how we have conversations are often vital preludes to making conversations themselves productive.
Three
We resumed work on improving our log-aggregation/query platform - our initial assessment of the AWS hosted ElasticSearch was that it was missing key features for our usecase, and that we would be trading off too much configurability for reduced operational overhead.
We’re now looking at Elastic’s own cloud offering and we repeated our investigation workflow that we used for our incident management application trials:
- Identify use cases and trials to run (with input from our stakeholders)
- Get our ducks in a row to engage a free trial (i.e. set up infrastructure ready for it)
- Commence the free trial and evaluate our criteria
My use of the word trial rather than experiment is deliberate, and comes from our CTO’s most recent fortnightly ProDev all-hands session - paraphrasing Linda Rising, there’s no null hypothesis or statistical validation going on, so what we’re performing are trials and not experiments.
This is not a bad thing, but if we don’t have the resources to do proper experimental validation we should at least keep our trials short, effective, and frugal. Our free trial is temporally capped at 14 days, and has no revenue cost, so provided we’re effective with the criteria we evaluate this is shaping up to be a good trial.
Four
We now maintain a number of tools to orchestrate production systems that have historically been un-loved - a Shift developer, Stephen, took it upon himself to spend a bit of time to spike a cleaner version with more user-friendliness.
Shift are lucky: if we scrunched up a post-it and lobbed it a few feet, we’d hit one of our stakeholders.
The original XP book (Extreme Programming Explained) talks about the benefits of having an embedded customer for validating work quickly - we’ll go and user-research stuff that we’re building with the users that will be using them by embedding and watching them use the tool, whether it’s a senior developer, a new hire, or one of our experienced Site-Reliability Engineers.
The tool he spiked, to improve our puppet node management workflow, opens up a lot of opportunities for us to try new technologies. Now that we know there’s desire for the product, we’re umming-and-ahhing about whether we:
- Keep it in Bash
- TDD it from scratch in Python, a language we’re familiar with
- TDD it from scratch in Go/Rust, languages we’re not familiar with.
We’ll be invoking the Improve, No Change, Worsen workflow (outlined in a previous blogpost) to establish pros and cons of each approach - (2) and (3) are almost certainly slower, but (3) gives us the opportunity to broaden our horizons.
Will (3) be worth the overhead of learning a new language/toolchain?
Stay tuned to find out!
Reflections
I’m starting to meditate again, once a day for 15-20 minutes if I can. My mind is full of stuff right now, both at work and in my personal life so I am trying to get better at taking time for myself.
I’m basically being hit in the face with my own oft-repeated quote
If you don’t take time, or make time, how can you ever have time?
I finished Killing Commendatore and have downloaded an audio-book of A Wild Sheep Chase, another Murakami book. There’s something relaxing about his prose that takes me out of myself for a bit.