This post is about learnings and reflections of our mob programming teams from an enterprise perspective. Not so much about the benefits for the team itself, but the impact on the organisation and its processes, the obstacles that may appear, and the ways to navigate around those obstacles.

My first post, Risk Management with Mob Programming describes one clear benefit for business that I thought wasn’t highlighted enough compared to its importance.

Some of the following characteristics are true for other teams as well. Mob programming just emphasis them.

ITIL and Change Processes

This is definitely an obstacle to take care of: a strongly implemented change process will probably ask for name of individuals responsible for different approvals. Changes need to be traceable: who did what and who approved it?

Mob programming teams act like one unit and don’t use personal accounts. There will always be the team’s name.

This also means that there is a shared responsibility for any production issues. No blame game, nothing falls between the cracks, which is one area the change process tries to attack. Ask: what are we trying to solve with our policy: is there really a conflict?

Chat & Collaboration

On the same theme as above mob programming teams also usually appear as one unit in conversations. They use their team Slack user, so conversations usually happen team to team instead of individual to individual.

This can sometimes cause some confusion for coworkers outside the teams: who am I really chatting with here? Especially if the tone gets harsh: go and chat in person instead to avoid misunderstanding. (Always!)

Internal Audit

Tightly connected to policies we have internal audits. For us this happens every or every second year. A team of internal auditors visits for 1-2 weeks to deeply and thoroughly investigate a certain area. Often they investigate the change process.

Auditors really want to find out whether we have “control” or not. Everyone expects that the agile teams will have tough times, while the large projects with all their documentation and beautiful plans, will not.

However, I have found that’s not the case. The auditors see the difference between speculation and facts, between words and actions. Just provide a lot of facts: we do have that. A mob programming team doing continuous delivery needs a lot of “control”, we just chose to avoid that word. We use the word “automation” instead. But let the auditor join and follow the automated processes and you will definitely pass the exam.

Budget and Financial Forecast

An organisation with teams owning their own products has already moved budget resource granularity from individual to team. Mob teams are no different in this aspect. The budget will tell what capacity you think you will need for different products, but it will not care about the way of working.

On-boarding and Off-boarding Team Members

What about the process when an employee leaves a mob programming team, the off-boarding? Well, isn’t this wonderful: it’s a non-applicable concept. What used to take planning, documentation and handover is not needed anymore. And even when you had done a thorough planning, documentation and handover you would still have that slight worry, that maybe some secret knowledge walked out the door with that person who just left the team.

Handover is usually also so demotivating for both parties involved: the person who just wants to leave, and the person who gets to take care of someone else’s stuff.

While recruiting to a mob team is at least as difficult as to any other team, the on boarding is smoother. Working together with your team from day one is a fast way to learn.

Performance Management

Oh, perhaps I had better skip this sensitive topic… but it’s there: and how to handle it when a team does everything together? When being that only one knowing the most complex solution isn’t valued anymore.  But rather sharing, inspire others and enjoy working together.

I hope to see a lot more happen in this area, but to start with we keep performance plans and goals shared and reviewed mainly on team-level. To move forward in this area you will need a high level of trust in your mob teams. You can’t have a mob team where the team members have hidden goals. 

Office Space

Obviously, there will be very specific and different needs when it comes to office space and working environment. What worked in our office was to occupy corners that would give the teams their own space but not disturb others. There’s also room for stake holders, other team members or anyone who needs to meet with the team.

While we want the mob corners to be inviting, they’re sometimes a little too inviting. Co-workers looking for a short break choose to join the cosy corner, not noticing they’re actually disturbing the team. A single developer can put headphones on or go somewhere quiet to signal “Please, do not disturb”. What’s the analog for a mob?

Transparency!

I’ll end this post by relating to one of the Kanban values: transparency.  Can mob programming really get more transparent? Work in progress, the process, the code, the people, the tools and all the conversation completely in the open. Love that!