NLJUG – Nederlandse Java User Group NLJUG – de Nederlandse Java User Group – is opgericht in 2003. De NLJUG verenigt software ontwikkelaars, architecten, ICT managers, studenten, new media developers en haar businesspartners met algemene interesse in alle aspecten van Java Technology.
Mob programming is a software development approach where the whole team works on the same thing at the same time, in the same space, and at the same computer. It is similar to pair programming, where two people collaborate with lone keyboard, and Mob Programming extends the collaboration to everyone on the team.
How could this possibly work?
While it might seem that a group of five people working on separate tasks will be more productive than having those same five people work together on a single task, in actual practice this we found this isn't always true. We discovered that some of the problems that typically plague development efforts simply faded away once we became good at Mob Programming. A lot of good things were happening.
For example:
- With all of us working on the same thing together, the best of each of us goes into everything we do.Where I am weak, another is strong.
- We engage our internal customers as team members: They come and sit with us daily as we work for an hour or two, and this provides rapid, meaningful communication resulting in code that gets delivered into production that does what the users want. We get quick validation of the usefulness of the code.
- We never put off cleaning up the code, so very little technical debt enters our code.When working alone it's easier to think "I'll clean that up later", but with the group, someone will say "we better clean this up right now". Almost nothing shady sneaks into the code.
- Another member of the team can quickly answer most questions that come up as we work. We have very little blocking and context switching due to unanswered questions.
- By working on one thing at a time, an idea goes from inception all the way to delivered, working software in just a few hours. Each product grows daily so we can validate both the value and correctness of everything we do as fast as possible.
- As a team, we have enough familiarity with anything we are working on so that when someone is out sick or on vacation there is no blocking due to lost knowledge.
- Onboarding new people happens instantly.There is no learning curve to be able to be productive. Whatever skill and knowledge you bring to the team is available to the team from the moment you arrive. They will quickly learn your strengths and put them to use.
- Everyone is learning and increasing their skills continuously.We are all exposed to what everyone else knows, and anytime we find something we don't know we all learn it as a team.There are no information or skill silos.
We have noticed that there is a great deal of overhead in managing the typical team and most of that overhead disappeared when we started Mob Programming. What if working together as a team actually eliminates the cost and work of managing software development? I think this has happened for us to a great degree.
The Basic Principles and Practices
On a Mob Programming team, everyone works together to do almost all the work a typical software development team tackles, such as defining stories, designing, coding, testing, deploying software, and working with the customer or product owner (who we also consider part of the team).
To make it possible to work together full time requires a rethinking of how we typically set things up for "solo" work. For one thing, it's necessary to reconfigure the physical workspace to accommodate a team, and even more important we need to find ways to make it easy to get along. We strive to accentuate and amplify concepts such as face-to-face and side-by-side communication, team alignment, collaboration, sustainability, whole team involvement, continuous code review, and self-organizing around the work at hand. Finding practices and techniques that allow us to interact well has paid off nicely for us.
While we have no rules and follow a very dynamic approach to our daily work, we do have a few basic principles and a few simple practices we use to make this collaboration go smoothly. I share these here as an example, and you are welcome to use them if you wish, but I encourage you to craft your own approach to uniquely address your team members and workplace situation.
Principles
Principle: Put "Individuals and Interactions" over just about everything else
Russell Ackoff said it best: “A system is never the sum of its parts. It is the product of the interactions of its parts.”
The first Value listed in the Agile Manifesto, “We value individuals and interactions over processes and tools”, makes it clear how important it is to find ways to make it easy for individuals to:
- Get work done
- Work on the right thing and
- Work well with others
There are plenty of great practices available, but not all serve as we would hope. We adopted the "Individuals and Interactions" value as a way to judge any practice we thought might be useful to us. I'll share a bit more about this under the practices section below.
Principle: Treat each other with kindness, consideration, and respect.
Working closely together throughout the day we are constantly communicating and interacting. We must be able to express ideas, discuss problems, explore possible solutions, resolve conflicts, and share thoughts all day long. This can be difficult at times especially when conflicts arise.
To help us keep our calm and handle the day to day interactions well, we crafted a simple principle to follow, which is this: "We will always strive to treat each other with kindness, consideration, and respect."
This seems straightforward, yet expressly acknowledging the importance of this principle to ourselves provided a foundation for our daily interactions which has served us well. It's amazing how quickly we can improve when we are all dedicated to this simple principle. I've noticed for myself that by working with a group of people who have all agreed to help each other follow this principle I have become a much better person than I had been.
Practices
Practice: The Driver/Navigators Model
An emphasis on the "Individuals and Interactions" Agile value becomes critical when 5 or 6 people are working on the same thing together. Making it easy for everyone to know what's going on so they can pitch in when they can be of help is of utmost importance.
The basic guideline is this: “For an idea to go from someone’s head into the computer, it must go through someone else’s hands.”
Following this rule requires that we get good at communicating our ideas verbally and at the whiteboard, and ensures that everyone has a chance to discuss and scrutinize everything we do. It exposes all ideas to the entire team and provides continuous design review.
There are two roles we use: the Driver and the Navigator.
The driver sits at the keyboard and types in the code. The navigators (everyone else on the team) express and discuss the problem and proposed solution, and give guidance to the driver about the idea to be coded. We rotate the driver every five to ten minutes so no one is at the keyboard for very long. We usually use a randomized list of each person on the team, starting over again at the top when we get to the bottom. Anyone who wants to take the keyboard has ample opportunity to do so, and those who don’t want to code can “opt out” from taking the driver role.
Working together the Navigators guide the driver in creating the code. The navigators are expressing their ideas each other and the driver in a metered approach so the driver only has to focus on the next thing to code at any given time. The driver listens to the navigators and focuses on translating ideas into code, asking questions as needed.
As we discuss and work out the possibilities, both verbally and at the whiteboard, everyone is gaining a full understanding of the current task and solution. This creates a collective understanding and intelligence across the team.
We generally speak at the highest level of abstraction that the current driver is able to understand. This can be at a very high level as when the driver is very experienced or understands the concept to be coded and can proceed without detailed instructions, but we can also navigate at a very detailed level if necessary—even at the level of keystroke instructions when needed. This will change from person to person and idea to idea.
Practice: Whole Team
Our approach follows the Extreme Programming practice of “whole team,” where every contributor to the project is an integral part of the team. We have all the skills we typically need for almost everything we do, including coding, designing, database, testing, business expertise, and documentation.
When we don’t have the skills we need within the team, we find someone who does and invite him to work on the team to accomplish the needed work.
For example, testing is done by the team in coordination with the business partners and application users in our company who will be using the software—that is, the testing is done as a team effort. The business people (product owners, end-users, expert users, etc.) join our team for any testing that needs to be done, and we work closely with them as first-class team members.
Several of us have extensive testing experience, and two of us have managed testing efforts as well. This is the idea of a truly cross-functional team: Someone on the team has the knowledge and skills required, and they can guide the rest of us in doing the work.
Practice: Reflect, Tune, and Adjust Frequently
We follow the Agile principle “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” We have taken this to heart and found it brings a great deal of value to us. We frequently evaluate what is working for us, what problems we might be having, and how we can improve on things. An important part of the principle is to “tune and adjust.” By simply paying attention and then tuning and adjusting, we have been able to choose actions that have led to tremendous improvements for us.
A few common questions
I have noticed that there are a few questions that come up whenever I share Mob Programming with people. Here are two of the most common:
How many team members is the right number?
This is perhaps the most asked question about Mob Programming. I'm not sure that there is a "right number". We use this heuristic: "Do I feel I am contributing sufficiently, or learning something useful working with the team today?" If so, we stay with the team and continue participating, and if not, then it might be a good time to split off and work on something solo or with a pair for a while. If the team needs you, they'll ask you for help.
We have typically worked with 5 or 6 people in our daily practice. It's not uncommon for us to have up to 7 or 8 team members, and a few times we've had 11 or 12 people actively participating.
How do you deal with conflicts?
There will often be conflicting ideas. That is both expected and welcomed. We are not worried about finding the "one best way" to solve any problem, but instead, we're looking to find "one of the many 'best' ways", get it into use, and see what we can learn. When conflicting ideas come up, we quickly evaluate them and steer towards the simpler one. We try it and evaluate the outcome, and then decide if we still need to try the alternative idea.
We found there are few situations where we don't quickly resolve the conflict. No one takes it personally when their idea isn't chosen, and we all understand that we can reverse any decision if we feel we went down the wrong path.
If You Want to Try Mob Programming
Mob Programming is the story of how one team learned to pay attention to the things that were working well for them and to amplify the goodness. A number of other teams at other companies are trying these ideas and finding similar results, but I suspect there are many teams and workplaces where this would not be a great fit.
If you decide to try it I suggest you spend a few learning sessions working on simple coding exercises until you've worked out the kinks. Make it fun, and focus on helping each other. You just might find it works for you.