At the fifth ‘Agile on the Beach’ conference, held in Cornwall, UK, InfoQ sat down with Alex Wilson and Benji Weber from Unruly. Wilson and Weber presented 'Product Development in an Unruly Mob', and discussed how mob programming has helped get the best from the Unruly software delivery team.
InfoQ: Hi Alex and Benji, and thanks for joining us today! The company you both work for, Unruly, has quite a reputation within the software development industry for fully embracing an agile approach to your work. Could you explain a little about what you do, and why you believe the company works this way?
Wilson and Weber: Unruly is the ad tech company that gets videos watched, tracked and shared across the Open Web.
Unruly has always embraced Extreme Programming (XP) principles. In the Development team we have practised pair programming, continuous deployment and test-driven development from day one. Perhaps even more unusually, Unruly embraces the core XP principles of rapid feedback and embracing change throughout the whole organisation (even outside of product development).
InfoQ: Here at the 'Agile on the Beach' conference you both talked about mob programming. Could you explain a little more about how this works, and what you see the benefits being?
Wilson and Weber: Mob Programming is “All the brilliant people working at the same time, in the same space, on the same thing, at the same computer.” (Woody Zuill) . We think of it as the next level up from pair programming (which we were already doing).
Woody Zuill credits Llewellyn Falco with the inspiration for Mob Programming. He believes, as do we, that it’s not about getting the most from the team but getting the best from the team.
At Unruly, we’ve been regularly mob programming in groups of between 3 and 6 people over the last year. We work at a regular workstation with a large desk and plenty of space for everyone to sit or stand around. We use a 50” TV so everyone can see the code, and have a second monitor for the driver
Wilson and Weber: Through the mob we learn together and bond over our shared experiences - in our Agile on the Beach session we covered Patrick Lencioni’s book “Five Dysfunctions of a Team”, and Mob Programming both helped tackle existing dysfunctions within our team, and exacerbate any latent issues we hadn’t noticed (so we could tackle those too!).
Mob programming helps us be a more effective team. We are all involved in building every feature that we mob on, so the design is better and we’re able to support it more effectively. We’re also able to complete tasks quicker as interruptions are less disruptive to a mob than a pair.
InfoQ: Do you believe that there are prerequisites (technical, process or social), before mob programming should be considered a viable approach within a team?
Wilson and Weber: This is a question we get a lot - certainly this stems from the typical question posed to XP practitioners “What if people don’t want to pair?”. It’s been theorised that mob programming is easier than pairing because it’s less intimate than 1-to-1 pairing, which can be intimidating, especially for new joiners.
Our highly collaborative practices are the first thing we mention in our job descriptions, so we’ve already selected for people who are happy with this kind of highly collaborative working environment. I doubt you’d persuade everyone to try mob programming. However, we do have a range of personality types, you certainly don’t all need to be extroverts.
As for technical practices - it’s hard to effectively work in a group if the feedback loops in your development process are slow. If your test suite takes more than a few mins to run, or your code takes a long time to compile you might have a group of bored people looking at their phones for half the day. However, mob programming can also help you to improve your technical practices. For instance, mobbing gives you implicit collective ownership and continuous integration - because you’re all writing the code together.
The most important thing by far is not to enforce a particular way of working, but to provide an environment which is both safe and enabling, and allow the team to evolve on its own - Woody often quotes: “The objective is not to create art, it’s to create an environment where art is inevitable”.
With such an environment, all members of the team should feel like they can contribute to the mob without fear, shame, or that they won’t have a fair say in the direction they are going. This is why we felt secure when we experimented and then adopted mob programming, and it’s an aspect of Unruly’s culture that we try hard to nurture.
InfoQ: I know Woody Zuill, a strong proponent of mob programming and the 'no estimates' movement, has been quite influential to you both - has he helped you explore better ways of working?
Wilson and Weber: We were originally inspired to try out mob programming on a regular basis after hearing Woody Zuill talk, after which we decided to give it a go. We have since experimented to find an approach that works for us.
In fact, we were recently honoured to have Woody visit us and join in some of our mob programming sessions.
We’ve not been persuaded to give up estimates yet. We do not have traditional project teams at Unruly. Rather we have product development teams that are responsible for looking for new value they can add to the products they own, in various areas. We find that understanding the cost of the next experiment that we could run in each of these areas is quite useful to us, and we avoid the antipattern of long, dull, sessions estimating items on backlogs that will never see the light of day.
InfoQ: With your successful implementation of mob programming within Unruly, what do you see as the next area for improvement within your design/development process, or what new technique are you keen to try?
Wilson and Weber: We had plenty of time to wax lyrical on the four-and-a-half hour train down to Cornwall. It feels like the next step for Mob Programming could be “Flash Mobs” (we talked about these in our Agile on the Beach session). Rather being wed to the idea of core teams, we are experimenting with being much more fluid and empowering developers to move where they can provide the best value rather than being stuck on one team. This takes the form of ephemeral “flash mobs”, which convene to achieve specific tasks and then disband, or freely joining other teams to pair/mob in order to learn/create. Not just self-organising teams, but self-forming teams.
We find the core principles of Open Space (if you’re not learning or contributing where you are, find somewhere else where you will be) are a great yardstick for facilitating this kind of environment.
We have, however, still to fully resolve this way of working with our preferred approach of teams owning the full product lifecycle from inception through to keeping products running in production.
InfoQ: Thanks for your time today. Is there anything else you would like to share with the InfoQ readers?
Wilson and Weber: If you’re based around London and interested in both discussing and learning about cutting-edge XP practices, we have a meet-up once a month called Extreme Programmers London, where we talk about XP from more a technical point of view than a process standpoint - our meet-up page is at http://www.meetup.com/Extreme-Programmers-London/
The video for Wilson and Weber’s 'Product development in an Unruly Mob' can be found on the Agile on the Beach YouTube channel.