I started my first IT-company in 1997. Ever since, I’ve been working as a developer or an architect, building software. There has been many ups and downs, highs and lows, in my career. But all in all, I would say I’ve been coding professionally for 22 years now. The last 4 years I’ve spent doing mob programming, almost exclusively, 8 hours a day. With a short exception of one company where I first spent 4 months trying to set the stage for the team to mob program, before it finally happened.
It has changed the way I look at developing. In short; it has helped me stop trying to be the most clever developer and instead focus on helping the team build the software our customer needs. The reward in a joint successful effort is so much larger than the reward in admiring your own clever code.
It has changed the way I look at developing. In short; it has helped me stop trying to be the most clever developer and instead focus on helping the team build the software our customer needs. The reward in a joint successful effort is so much larger than the reward in admiring your own clever code.
So: Why on earth would we take a group of expensive developers and put them in front of a single computer to mob program?
Well: because software. During my years of developing software I’ve run into a multitude of issues. We tend to write complicated code even when not needed. We write bad code, maybe blaming deadlines and meaning to go back and fix it later. Or maybe because we have no code reviews. Or even when we have code reviews, they’re often done in a micro perspective, not seeing the whole picture.
We have dependencies to specific people; only Brent the Hero can understand and fix this. Or at least Brent has to look at it and tell the rest of us what to do. And approve it later. We are specialized; finding the task on the board that we know well, because it’s so much quicker if Joe does the CSS and Jenny does the database optimization.
And for some reason, we’re often under time pressure, which narrows our focus, makes us do less research and consider less options. Oh, and let’s skip the unit tests, just this once. Someone made an estimate and it magically turned into a deadline.
Let’s not forget the things outside the actual coding. The prioritization issues, where everything is equally important, forcing development of multiple features in parallel in the same codebase. Important information that is not reaching the people who needs it. The confusion of requirements in an agile world; too vague because of fear of doing waterfall, or too specific and time wasted because they’re not possible to implement that way.
Long testing periods, where feedback comes in much too late. Is anyone using the Acceptance Test Environment this week? Oh, we’ll wait then. And where should bugs be reported, as a subtask of the user story or on a specific bug board? Maybe we need an agile coach who can tell us we need a definition of done, or a Jira consultant to help us manage our agile tool?
And very importantly; don’t release on a Friday, because we don’t trust our software. Or wait, let’s make that Thursday to be sure.
So software development has issues with delivery and quality. Not really news. One way to come to terms with this was Extreme Programming in the late 90’s. The methodology is about taking practices that work well and applying them to an extreme level. For instance; since code reviews are a good practice, why not do them all the time by pair programming?
XP also advocate things as code simplicity, TDD, working tightly with customers and within the team, and not developing features until they are needed, thereby knowing more and understanding how and what to build.
XP emphasizes teamwork and has five core values; Communication, Simplicity, Feedback, Courage and Respect. The beauty of this is that these values stress the fact that the process of building software is not limited to the craft of designing the system or writing the code. The team creating the software consists of managers, testers, UX, developers, customers with open communication between these roles being crucial.
Still though, 20 years after the excellent book by @KentBeck on Extreme Programming came out, we have the same issues. How can we learn to work better together to deliver great software?
We have dependencies to specific people; only Brent the Hero can understand and fix this. Or at least Brent has to look at it and tell the rest of us what to do. And approve it later. We are specialized; finding the task on the board that we know well, because it’s so much quicker if Joe does the CSS and Jenny does the database optimization.
And for some reason, we’re often under time pressure, which narrows our focus, makes us do less research and consider less options. Oh, and let’s skip the unit tests, just this once. Someone made an estimate and it magically turned into a deadline.
Let’s not forget the things outside the actual coding. The prioritization issues, where everything is equally important, forcing development of multiple features in parallel in the same codebase. Important information that is not reaching the people who needs it. The confusion of requirements in an agile world; too vague because of fear of doing waterfall, or too specific and time wasted because they’re not possible to implement that way.
Long testing periods, where feedback comes in much too late. Is anyone using the Acceptance Test Environment this week? Oh, we’ll wait then. And where should bugs be reported, as a subtask of the user story or on a specific bug board? Maybe we need an agile coach who can tell us we need a definition of done, or a Jira consultant to help us manage our agile tool?
And very importantly; don’t release on a Friday, because we don’t trust our software. Or wait, let’s make that Thursday to be sure.
So software development has issues with delivery and quality. Not really news. One way to come to terms with this was Extreme Programming in the late 90’s. The methodology is about taking practices that work well and applying them to an extreme level. For instance; since code reviews are a good practice, why not do them all the time by pair programming?
XP also advocate things as code simplicity, TDD, working tightly with customers and within the team, and not developing features until they are needed, thereby knowing more and understanding how and what to build.
XP emphasizes teamwork and has five core values; Communication, Simplicity, Feedback, Courage and Respect. The beauty of this is that these values stress the fact that the process of building software is not limited to the craft of designing the system or writing the code. The team creating the software consists of managers, testers, UX, developers, customers with open communication between these roles being crucial.
Still though, 20 years after the excellent book by @KentBeck on Extreme Programming came out, we have the same issues. How can we learn to work better together to deliver great software?
Mob programming
@WoodyZuill expresses the essence of mob programming brilliantly:
The navigators constantly discuss design and code, review code as it’s written, google when the team runs into problems. If the team is building a public web site, the feature can be tested on different devices while being built. As in the metaphor of driver and navigator, the driver follows the navigators’ instructions. If you don’t know CSS and what to write, it doesn’t matter. The team helps you forward.
In my experience, when this works, it is career changing and an eye opener to how important it is to work closely together as a team – product owners, UX, testers and developers - to achieve flow, joint ownership and pride of what’s being built.
“All the brilliant people,
working on the same thing,
at the same time,
in the same space,
and on the same computer”
This means all the developers around one computer, one person at the keyboard, using a timer to rotate. Everyone does everything. If a task is about CSS and you’re the database girl, you still take your turn at the keyboard. The method is similar to pair programming where there is one driver at the keyboard and one navigator on the side. Here though, we have multiple navigators.
The navigators constantly discuss design and code, review code as it’s written, google when the team runs into problems. If the team is building a public web site, the feature can be tested on different devices while being built. As in the metaphor of driver and navigator, the driver follows the navigators’ instructions. If you don’t know CSS and what to write, it doesn’t matter. The team helps you forward.
In my experience, when this works, it is career changing and an eye opener to how important it is to work closely together as a team – product owners, UX, testers and developers - to achieve flow, joint ownership and pride of what’s being built.
Better quality
This aspect of mob programming is usually quite easy to achieve. More eyes, minds, diversity of thoughts and experience will make the team discuss and think about features and coding in a new way. The joint ownership of the code encourages refactoring and solutions that the team feel proud of.
- The team programs, analyzes, designs and tests at the same time.
- There’s more focus on creating simpler solutions that will be maintainable for years to come.
- Courage, we dare change code and ideas when needed.
- Thought through on all levels, from CSS to deploy scripts.
- Constant learning; technology, domain, best practices, keyboard shortcuts.
- Knowledge sharing, everybody does everything.
- With more eyes on the code, duplication and dead code is more easily discovered.
Better delivery
We often talk about high performing teams, meaning teams that are good at producing value. In a world where time to market can be very crucial for a company, being able to deliver often and with confidence is essential. One huge benefit of mob programming is the short lead times and flow it can create:
- With a working Continuous Delivery pipeline ->
- When everyone works on the same feature ->
- When the code being checked in is already reviewed and the feature is tested ->
- When there are no merge issues ->
- Then a feature can go from idea to production in the shortest possible time.
It takes time
Getting mob programming to work is not something that’s done in a day.
It’s exhausting. It’s a whole other level of focusing, verbalizing your ideas and listening to other people verbalizing theirs. You don’t take all those micro pauses you normally do. You don’t get stuck reading email, or browsing the web for weather or news. The mob keeps on, all day, like a bulldozer. The first weeks, you will feel drained.
But it’s not all about the developers. The process surrounding development needs to catch up with this way of working. When requirements are vague and only in writing, the mob can be very inefficient. Everyone, not just the developers, has to be more in the present, ready to discuss the details of the current or next task, be there for questions during development and approve it when it‘s done.
There’s also the need to find some structure and routines for the daily work. People get into work and leave at different hours, how will this be handled? What type of sync meeting do we need in the morning? Focus should be about what will be done during the day and who needs to be available. Clear goals for each day and feature is a must. To make sure everyone in the team, PO, UX, testers and the mob understands the feature, a short session at a whiteboard before starting a task is really useful. Not to set the details, but to make sure everyone knows what the team expects to deliver.
But it’s not all about the developers. The process surrounding development needs to catch up with this way of working. When requirements are vague and only in writing, the mob can be very inefficient. Everyone, not just the developers, has to be more in the present, ready to discuss the details of the current or next task, be there for questions during development and approve it when it‘s done.
There’s also the need to find some structure and routines for the daily work. People get into work and leave at different hours, how will this be handled? What type of sync meeting do we need in the morning? Focus should be about what will be done during the day and who needs to be available. Clear goals for each day and feature is a must. To make sure everyone in the team, PO, UX, testers and the mob understands the feature, a short session at a whiteboard before starting a task is really useful. Not to set the details, but to make sure everyone knows what the team expects to deliver.
It tests the team
All issues you normally have in a team gets multiplied in a mob. If you are in a team where you still sit and work by yourselves, you can avoid interacting with team members you don’t go well with. Here, you don’t have that possibility. When there’s issues surrounding trust, having a common goal, commitment, ego, status, ownership around the code, they will affect the mob much more than they will a regular team.
It’s all about mindset
- It’s not about making your own voice heard.
- It’s not about getting your own solution done.
- It’s about building an environment where the unique knowledge and competence of everyone involved is recognized and utilized to deliver the best software for the user.
- Stop being the best developer. Start being the one helping the team learn and move forward.
It’s all about learning
Mob programming is constant learning and sharing. If your suggested solution isn’t the one the team tries, be open about the other solution. Make sure everyone’s voice is heard and encouraged and view all suggestions as a basis from where you can build further. Each step in refining your code is a step towards learning more.
- Together we become the perfect full stack developer. See the possibility in learning CSS, or the database, or the other things that you didn’t think you would need to know.
- In sharing your knowledge with others, the team’s collective competence is raised. This allows individuals to sharpen their skills within special areas even further.
- No more person dependencies. Everyone does everything. No one has to work from home when sick because all tasks are handled by the mob.
- There is plenty of room for innovation in a mob. When the mob has a hard problem, we solve it. When we have an easy problem, we innovate or automate.
- We learn by discussing and trying things. No more meetings where the team has to agree on patterns, naming standards, or someone needs to explain to the rest about this new clever solution that has been implemented.
- A new team member will be productive from day one and quickly find her footing in the codebase with the help of the mob.
Quality is King, but Flow is King Kong
In my opinion, having flow, where the product owner is close by, questions can be asked and answered when they arise, and most importantly; tasks get done, tested and closed, is the key to almost everything else. When we can check things off the list, feel good about what and how they were delivered, so many other issues never arise. The fewer things we have to keep in our heads, the better we can handle the things we actually do have to think about.
I have been in mobs where this hasn’t been the case. The team has still had a huge backlog, never succeeding in finishing sprints, failing quality and a long list of bugs. Not working closely to the PO means that understanding and trust doesn’t get built, and the development process never adjusts to the mob. My biggest takeaway from mob programming is probably this; realizing how important this part of software development is.
I have been in mobs where this hasn’t been the case. The team has still had a huge backlog, never succeeding in finishing sprints, failing quality and a long list of bugs. Not working closely to the PO means that understanding and trust doesn’t get built, and the development process never adjusts to the mob. My biggest takeaway from mob programming is probably this; realizing how important this part of software development is.
- Everyone needed must be available and focused on the current and immediate features; PO, UX, Test.
- Since the team is working closely with the PO, there will soon be a common understanding on how big different items in the backlog are.
- The backlog needs maximum 5 prioritized and groomed items, ready to start working with. These should be revised every day. Still the most important = go on. Otherwise = move down.
- After development, meaning setting the requirements, developing, testing, feedback and refactoring, the item should be done. Preferably, testing is done during the development, or together in the mob and next task is not started until the previous item is done.
- Mob programming can be the driver to change the development process for flow, by forcing work on one feature at the time. If the people needed aren’t available, the mob and therefore all of development grinds to a halt.
And the tricky stuff
It’s not all easy breezy though. I’ve been in mobs where 3 out of 6 developers left the team because mob programming didn’t work for them. I’ve heard many comments about mob programming only being for people who can’t understand the code themselves. I’ve had teams next to us loudly declare that the management were idiots for letting us work in this inefficient and embarrassing way. So there are definitely some tricky bits I’ve run into during these 4 years.
- Mob programming has little or no status among many developers.
- It’s hard to handle a team member who doesn’t want to mob. As soon as the team is divided, lots of benefits of mob programming disappears.
- When management sees a successful mob programming team, they tend to push this method on other teams. Like so many other things, it has to be a decision from within the team. Mob programming is a huge change in working that needs to be taken seriously.
- If requirements aren’t clear, or no one can answer questions directly, the mob becomes very inefficient. Not having the right foundation for mob programming is a sure recipe for failure.
- Combining mob programming with traditional Scrum, using estimates beforehand to compose sprints, is not a good match. The power of the mob is the constant delivery and flow.
Some final advice
- Continuously review and improve the mob. Remember that mob programming is not the goal. It’s a way to achieve the goal: How can we work better together?
- Don’t set out to build a team that mob programs. Try instead to build a climate where cooperation can thrive. A place where anyone, anytime, can say “I don’t understand” without being sneered at.
- Make sure everyone’s voice is heard and appreciated.
