I’ve been following Woody Zuill on Twitter for quite a while. Woody is the author of ‘Mob Programming, a whole team approach’. You can read more about Mob Programming here. The basis of the approach is for a ‘Mob’ to be developing as a collective with only one computer. If you’re familiar with pair programming, the technique is adapted from Llewellyn Falco’s “strong” pair programming style: the basic rule being “for an idea to go from your head into the computer it MUST go through someone else’s hands”.
So instead of our monthly code kata session we decide to switch things up a bit and give Mob Programming a go. For this, I decided to pose as a typical client and send a small project idea through our website enquiry form as this is the most common first contact we have with our new business enquiries. I deliberately left the requirements vague and described what I wanted to achieve and why I wanted to achieve it so that the team had a good idea of what my goal was, as opposed to being spoon fed a specification or list of specific requirements. It’s much more interesting to see how a team interpret’s these sorts of requests and for them to come up with a strategy for answering the brief with the freedom to come up with their own solution to the problem. The initial request I made is copied below. There are some interesting nuances within the message that the team must do their best to identify and address. Can you spot the things that might be important to take into consideration?
We’re a small agency that run standups every morning to discuss what’s needed to progress our work. Each morning we gather around a Kanban board and it’s someone’s job to ‘walk the wall’. We try to be fair with taking turns but understandably this doesn’t always result in an equal sharing of the responsibility.
I thought it could be nice to have something that ensured an equitable sharing of the responsibility of walking the wall and began looking at things like spin the wheel. And then I thought ‘if I can’t even fix the f*cking toilet door in the office, how am i going to find the time to build one of these things?’.
Additionally, whilst a physical wheel kind of sounded fun I am not sure how practical it would be because all team members are not always present (some might be working from home whilst others might be at meetings or on holiday).
So that’s when I searched the web for ‘superdooper web app development agency, London’ and you guys came up as the go-to people to help me build something ‘cool and awesome’.
Unfortunately, budget is tight: I only have enough for an afternoon of your time. Can you help? If I’m being honest, my biggest anxiety is that you’ll get to the end of the day and ask me to pay more money to complete the work.
Love what you do, you rock
The best client you’ll ever have xx”
Most importantly, the Slackbot had to be named and in the style of Boaty McBoatface called our lovable new Slackbot ‘bottymcbotface’. After that, the Mob decided to develop a basic bot and then to iterate on it and refine the conversational UX. The work followed the general order of:
- Create a basic bot to randomly pick and return a team member’s name when prompted
- Persist who was chosen so that that the same person wasn’t chosen twice in a row
- Prompt the team just before standup to ask the bot ‘whose turn is it?’
- Allow someone to respond to the bot by telling it that the chosen person isn’t available. The bot then picks another team member
- Embellish the conversational language – provide random alternatives
- Post a fetching gif of encouragement ‘bring on the wall’ once a person has been accepted
- Accept different inputs (mostly swearing) to tell bot that someone is not available. eg: ‘not here’, ‘no’, or ‘fuck off’ etc. For some reason the swearing element seemed to please people more than anything else.
Here’s a screenshot of today’s conversation: