100% of the team in a mob for 12 months — taking mob programming a couple of steps further.
A Guide to mob development, benefits and challenges.
Working close as a team with 100% understanding of the task ahead and shared responsibility for achieving the goal is the big win.
For 12 months, I have been UX designer / researcher in a mob of 6 people who work with digital services for mainly SVT Sport (Swedish Television). (And before that 18 months at Bonnier News in a mob programming team, but I rarely actually sat in the ”mob”.) My current team does everything from discovery to delivery in the mob. It has been a year of challenges, a bit of a identity crisis every now and again, and above all the most evolving working method I’ve experienced.
So how has the year been? This post is about sharing my experiences. All wins as well as all the difficulties and how the team handles it. Our toolbox!
Disclaimer: this is not the recipe for all teams, just how we do it. And entirely based on my design perspective, based on my experience and different teams I’ve been apart of, with or without mob programming. A most personal reflection.
What is a mob?
In short, a mob consists of three or more (usually) developers (in our case, also UX designer, product owner and tester, plus a “guest” from time to time)
who all work on the same problem at the same time on the same device. The “mob” rotates and we take turn in being the ”driver” (sort of a secretary) in fixed intervals. In our case, rotations of 10 minutes. Everyone except the “driver” is thinking and navigating solutions to the problem and are called “navigators.” They act as “brains” while the driver performs instructions.
“Mob programming is a software development approach where (all the brilliant minds working on/) the whole team works on the same thing, at the same time, in the same space, and at the same computer.”
– Woody Zuill, founder of mob programming
When mob programming became mob development
At SVT interactive, we are several teams who work with mob programming. My team, SVT Sport is the first team to work 100% in a mob and “mobbing” other than code. We have simply taken mob programming one or more steps further. The sports team mob develop all parts of our mission, ie both discovery and delivery — from assumptions to hypothesis, exploratory phases, design, implementation and testing.
We can do this because the entire team is one big mob with several competences — product owner, UX designer (me), developers and tester.
Why mob develop more than code? What problem are we trying to solve?
Having the entire team’s competences in the mob means, in short, that you can take on more complex tasks without lead times. The competence we need is constantly present. Always ready to respond or act. No handoffs are needed between team roles, which for me as UX designer has always been the most frustrating part. Expectations become clear when everyone takes part the entire journey. The first spontaneous reaction after working in a mob is a sense of 100% understanding of the problem or task we are working on. The mob support collaboration. It’s not I, It’s we who solved this.
Shortfacts about us in the SVT Sports team and our mission
What are we doing? Working with SVT Sport services on digital platforms.
Team Background? We were recruited as a new team and with strong wishes to use mob development as way of working combined with Lean UX as a working method. To get started we had a really good coach.
Our mission? Our initial assignment was to move SVT Sport back to SVT (previously developed externally). We received great freedom and support in how we would take on our “mission”. After a few months of researching target groups, strategic work and other exploratory tasks, we had enough to set the goal we would aim at: “News and Sport — One Service, One Experience”. This meant that, unlike before, Sport and News should approach each other and follow our user needs while not conflicting with organizational goals or other teams’ assignments. The SVT Sport online services “moved” home to SVT.se just in time for the World Cup 2018. (A shift that went beyond all expectations, almost unpleasantly painless.)
So what are the benefits of mob development as a way of working for our team?
When everyone in the team knows and understands how our contributions affect the end product, we create better products. As long as the work is meaningful, we care about the outcome. Understanding how our contributions are important is central. For example, seeing how a user uses the end product regardless of role in the team becomes important for doing a better job. A result of all team members working on all aspects of a problem at the same time.
- 100% understanding of the problem / task within the team.
Everyone focuses on the problem, and can make decisions that take us towards the goal. Precise specification of requirements are no longer needed. The knowledge is in the mob. - Engagement throughout the whole process and an understanding of why we choose a particular course or solution.
Good products are made by people who care. - Easier to focus on one, “right”, thing at a time.
It helps us keep direction. Fewer irrelevant side tracks. We are getting better on prioritizing unnecessary fluff, or those that do not have top priority. No unnecessary fiddling … - Less explanatory and fewer misunderstandings when the team is involved all the way through the process and meet actual users within our target group.
Everyone gets an understanding of the problem we are going to solve. From an UX perspective, this is a great relief and involves much less frustration. I can trust the team. - Greater opportunities to influence the final result.
When you are in the mob you can create trust by creating an interest and understanding of other areas of expertise.
This makes it easier to influence and ask questions (e.g. “How does this solve the problem”, “How does this take us closer to the goal”, etc.). - Nobody in the team becomes completely “indispensable” when we learn from each other.
The mob can go on even when everyone is not in place. At least for a while. - Fewer surprises along the way when all competencies have taken part in decisions we take along the way.
It is easier to avoid unrealistic specs from designers to developers or requirements from the organization on features that users do not prove to want. Or developers who build solutions that are difficult to manage or further develop. - Nothing blocks the way forward within our own team when we all work on the same problem.
We do not have to wait. Of course, we can still be blocked by decisions that need to be taken in the organization, other requirements or other teams. - Competence development.
We share and learn from each other. - Onboarding of new or external competencies.
Onboarding new team members, temporary guests or experts into the mob is immediate. By sitting in the mob a few rotations you will catch up, learn, and long explanations are seldom needed.
Some things that helped us along the way
New recruited team, supported by immediate stakeholders. We were a brand new team when we started mob developing. We had nothing to compare with or any comfortable habitual pattern to fall back on. Testing mob development came from our closest stakeholders and we never needed to defend our way of working. It was in everyone’s interest to dare to evaluate this to a 100%.
Avoiding prestige in the team, otherwise it will be difficult. We develop together and build on each other’s ideas. Therefore, there is no clear distinction between mine and yours. Everyone owns the idea, the solution and the result.
In common motivation and driving forces. During various team exercises with our coach (e.g. moving motivations), we have learned that we are motivated and driven by similar things. This is the team that very much values curiosity and very little honors. Team recruitment and team composition becomes important and probably even more important in a mob.
Team agreement. A must for each team in order to know what is applicable and important. Something that is concrete and can be questioned. Not least by new team members.
Our own team coach. Coach, Martin Christensen, helped us become a successful team 💙
Everyone in the team is a “UX”. As the UX expert in the team, I facilitate more than engaging in design details.
Methods and processes. We use a mix of methods to find out what to build, for whom and why. Those that influence us the most are that we work according to Balanced Team to make decisions in the team and Lean UX to keep direction of what we’re working on.
A full day with Woody Zuill. To learn from the master himself, the founder of mob programming, made it much more real and exciting.
Our most important gadgets in the mob
Challenges in the mob — a guide to how we handle them
Close cooperation imposes other demands on team members in the mob. You can not hide from conflicts …
Challenge: different wills and ideas
To handle different wills, listen and compromise.
Team Processes and communication are essential to make mob development work. Mobb involves more interactions with each other in the team. To handle all interactions and close collaboration, we use Core Protocols, a communication tool for focusing, raising awareness, making decisions and getting better at incorporating what others say in the team (positive bias).
Challenge: Keeping focus
It is easy to fall into everlasting discussions, trying to find the perfect solution, or zone out when we are many. The more chefs the worse the soup …
Mob rotations in 10-minute intervals. We are strict about rotating within the mob. When we forget to rotate and one and the same person stays at the keyboard (usually stuck in the role of both driver and navigator), the focus and commitment is quickly reduced in the mob. We keep track of time using our mob timer. And for a quick change at the turn, we have a common computer.
Two “mob rules” that we above all stick to are the rotation within the mob and that everyone should take part in the mob, even if everyone does not do it full time. I can for example prepare some user research-parts outside the mob.
Mob-rules. We have agreed on a few mob-rules. These work a bit like team agreements but for the mob.
Daily Retro. We do not have a daily standup (except for a brief check-in to know if anyone will be away on meetings or leave early) since the whole team is working on the same problem and common goal. Instead, we have a short daily retro where we ask three questions:
1.) Are we getting any closer to the goal? 2.) Whatever, are we working on the right things? 3.) How do we proceed in the loop?
Good enough for now, safe enough to try. Try a solution instead of trying to discuss your way to the “best” solution.
Time-Boxing discussions. When we where new as a team, we had a tendency to end up in long (exhaustive) discussions about how to proceed. We had not embraced Good enough, safe two try but tried to discuss our way to the “best” solution instead of trying one hypothesis. The team is now more self-conscious. We know that we need to time-box our discussions, or park them if they are not relevant right now.
Challenge: Common understanding
What are we doing? Where are we heading?
Learning from each other’s areas of expertise. Stepping out of one’s comfort zone and feeling committed to what’s beyond ones expertise.
Visualize. Visualization of concepts, ideas and solutions will be important in order to explain to everyone in the mob. In order for everyone to follow where we are and where we are heading. Often on a whiteboard.
High level of abstraction. When we code, we keep it at a high level of abstraction. The navigator needs to articulate what she or he wants to accomplish to the whole mob, more than precise commands to the driver. This allows others in the mob to further develop an idea, addressing potential risks or problems with a proposal, at an early stage. In addition, as a designer who lack good code syntax knowledge, I will be able to understand and contribute.
Lean UX as a work method: Helping us navigate towards the goal.
Challenge: When shared responsibility becomes nobody’s responsibility
Still a challenge at the time of writing.
Guardians. We are good at sharing responsibilities when it comes to team processes and work processes. Other things that we need to do outside the mob are more difficult. However, action points from our team retrospectives are each assigned a Guardian, responsible for follow-up. Works most of the time …
Challenge: Ego and the need for control
Dare to let control over design details and gain control over the whole picture.
Facilitate rather then controlling design in detail. And what can I do now when I do not need to check every design implementation, when the team is self-going and focused on goals and usability? Take a vacation? I had to rethink my role. My role is now more about facilitating. There is more room for user research, better UX strategy and innovation that provide value and feels meaningful. But on and off, I still have to fight with uncertainty about what my role in the team is.
Challenge: Further development within one’s area of expertise
How can I be able to feel that I contribute in the mob although we sometimes work in areas far from my own area of expertise. Is there time to learn these areas as well, while maintaining my expert level in my own field?
Time for recess outside the mob. In order to maintain my UX perspective in the mob, I still need to be able to immerse myself in my field of expertise. It is no less important to stay up to date in one’s area of expertise in order to be able to contribute in the mob. (And the mob can make this time possible, but it is my responsibility to take it.)
Challenge: Motivation
To feel motivation even during periods when we do not work in “my” area.
Agile UX — to work in small “waterfalls” between discovery and delivery. Aiming for short iterations, so you’re never away from what motivates you the most for long periods.
Solo time. The hardest thing about working in a mob. Mob as a way of working does not suit everyone and it is important to be aware of this. To know if it works, the team needs to give it an honest chance, a period to be evaluated, in the same way you would try other ways of working. You do not know until you’ve tried! And if mob development does not work full-time for everyone in the team, create a more flexible way of mobbing. Do what works well even more. “Turn up the good”, Woody Zuill should say.
And the most important thing …
The mob creates courage to dare to innovate and develop together … and makes sure that you are always focused on what is important. The mob is shared responsibility, failures and successes 💙
