… something on Mob Programming with Woody Zuill
On Monday, having met Woody Zuill a couple of times at conferences, I was able to arrange for him to come in and run a day’s workshop on Mob Programming. In the evening he gave a talk at Cambridge Agile Exchange, a local meetup group, as well, this time on ‘Beyond Estimates’.
Woody’s visit was arranged at relatively short notice, and I was quite conscious that I was sending mostly a load of developers (amongst others, but I’ll come back to that) invitations for 3-hr+ long workshops; a group who very often see meetings as a Bad Thing. I was also taking entire teams away from their work for an entire day — this thing had better be good.
I needn’t have worried — for a start Woody is an engaging, entertaining speaker, which is why I invited him in the first place. Secondly, the subject, Mob Programming, struck home.
For the morning session I circulated to as many as I could, whilst also trying to judge how big the room was. I was keen to involve non-developer roles as well, so I made sure I invited Product Managers, Product Designers and our Quality Coaches.
Product Managers and Designers were important due to the nature of Mob Programming in itself. The point is to have the ‘Whole Team’ working on one problem, and this includes those around the Team, especially Decision Makers, the absence of whom may cause delay in waiting for them.
Quality Coaches were important in their role of spreading practices such as Mob Programming around the company. After all, it may well be them who help teams who haven’t been on the course to implement Mob Programming.
Morning Session
First of all, as with any good workshop, Woody asked what learnings people wanted from the day, or questions they wanted answering.
Then Woody posed the question; Why would we want to work like this?
The overwhelming response from the group was Knowledge Sharing, but I often see it terms of minimising Work In Progress and having a laser-like focus on a single problem. Which we’ll return to.
Woody uses a lovely slide (his wife does many of the illustrations) which quotes:
“The object is not to make art, it’s to be in that wonderful state which makes art inevitable” — Robert Henri
Woody describes how he came to Mob Programming, how well it can work, and many examples of companies using it.
He explores the need to keep away from Mob Programming (or indeed Pairing) becoming a Driver and Observer situation, but how the Driver should be a Smart Input Interface between the team and the computer.
Afternoon Session
The afternoon session started with a demonstration of rotating the team members through the different roles. This involves a slightly theatrical ritual of moving the whole team round, including someone away from the keyboard — which can be jarring.
The attendees then formed teams for a hands on session that ran most of the rest of the afternoon.
Woody gave an interesting exercise and some rules, which he varied over the afternoon. A few times, he gathered everyone together and got people to share their experience, including frustrations, in short retros.
Some of this was ‘training’ for people on how to work effectively in the Mob situation —being polite and respectful, allowing everyone to contribute, and to keep rotating the driver. He kept the teams to strict TDD (Test Driven Development), which could be an added bonus side-effect of the training.
For the final session, the teams were doing Mob Programming as you might in the wild. But Woody wasn’t finished there.
All the Perspectives
I mentioned earlier I felt it very important to get different roles in the room. I was really pleased that one of our Product Managers came along for the whole day, engaged, and here he is hands-on on the keyboard, driving.
Round up and Retrospective
Woody had a final short talk, exploring why Mob Programming is so effective. The short answer is that it enables three different types of Flow —being ‘in the zone’ personally, and also as a Team, but also in the Lean sense — single-piece Flow; working on one thing at a time until it is done.
Finally, we all got together as a group and had a retrospective on the day. This is a technique Woody evangalises for every day — focus on what worked well and how you can do more of it:
Turn Up The Good — Woody Zuill
The Aftermath (in a good way)
Apparently one of my fellow Tech Leads came away from the day and said “We’re doing that”. Just like that.
One challenge is to have a screen that everyone can see clearly enough. We lent them our Team area large screen and away they went.
I had various other bits of vox pop feedback on how engaging the day was, I’m currently putting together a survey to garner wider opinion, but certainly from the temperature of the room I’d judge it a success.
Let’s see how widely it’s adopted.
Conclusion
Coincidentally, this week at Redgate there is also an effort to highlight what makes working here so good. Having the opportunity to attend a workshop like this nicely answers the question in my mind.
We’ve actually been using Mob Programming in my team since it formed at the beginning of this year.
But even then, I felt I took away quite a few things from the day that I felt I learned.
And I haven’t even got on to the evening event yet…
