Once you only create rules when their benefits outweight their cost, you can start re-imagining how you work with your team. Mobprogramming gave us a new breadth of knowledge, but when we started, we were stuck in an open plan office.

When we started mobbing, there was only three of us, so it was manageable behind one computer. Very quickly, you realise that the monsters that are open-plans, with desks side by sides, with another row facing you, and a useless and harmful separator, are not actually helping communication with the rest of your team, they’re hampering them.

When the full team started mobbing, something else was needed. Unfortunately, open-plans are yet another cargo cult in some organisation. You see, I’m pretty sure it all comes down to this: managers, HR, head of departments do nothing and have no model to allow and foster communication and information flow inside the business, so they use open plans as the cornerstone of their lack of strategy. Remove the open plan and there is nothing left for them to hang on.

Nevertheless, we needed another solution, and the only rooms, beyond upper management, were the meeting rooms. So we did it Guerilla-style, we booked back to back a meeting room or another, and when a room change would occur, we would unplug everything, transport to the new room, re-plug everything and continue. This continued long enough that we were capable of moving 7 people and their stuff in a matter of 15 minutes.

We were very lucky to eventually see a room being cleared on a disused floor, for an impeding refurbishment. That floor had many rooms, and we took one over and installed ourselves in it.

I believe strongly that creativity is unleashed when people work in an environment they own, and where the environment is both a creative medium and a reflection of their occupants. Our team room gave us that. We added furniture that was recuperated from disused parts of the building, added some plants and decoration we brought in, pictures from the family and a few other tidbits. Our team was in their own room, that reflected their personality.

Unfortunately, this brushed many feathers and was seen by some as a desire to disconnect ourselves from the rest of the company. Yet, what we were trying to achieve was not to segregate ourselves, but to control our communication channels better, and allow the sharing and learning moments to happen willfully rather than through the medium of interruption.

Could other teams have invaded rooms themselves? Probably. Some even did for a few days here and there, but the practice only spread to one other team. I strongly believe that this wasn’t due to a lack of desire, but by the power of the norm. No one wants to be different, probably to avoid the difficulties that not following orthodoxy brings to a team in a sometimes hostile and often fearful environment. And yet, teams that do not feel afraid have the highest retention rates.

It is rare these days that I see developers working alone. Pairing has broken into the mainstream, and yet it is rare to find a pair you’re comfortable pairing with, and we still don’t quite know what is going on in other pair’s work.

So we have two problems, knowledge sharing is slow when you divide work into pairs, and it can become uncomfortable to pair with some people due to a skill difference, a coding speed difference, or a different way of thinking.

You can try to fix the first problem by rotating pairs often. Too often and no one ever finishes anything, too little and little pockets of styling and knowledge get created. As we all suffer from the inevitable churn rate of high-flying consultants, we also have to contend with changing that rotation speed often as the team evolves. In my experience, it is an extremely challenging problem.

Knowledge sharing, and it’s extension, norming of a coding style and practice in a team, is also very slow with pairs. You have to continuously re-argue, re-discuss, show again, and again, for each pair, for each concept, what you’d like to see happen, or what you know. By definition, if you rotate every other day in a team of 6, a simple idea will take 10 days to get around the team. Wow.

We decided instead to try mobprogramming. In this scenario, all of us sit together, with one keyboard and one mouse (for those developers that cannot get over the point and click…)

A big projector or a large screen displays the current coding session, and the guy with the keyboard does the coding, as we discuss our first specification to implement. Group discussion is involved at each step, going back and forth to the whiteboard.

One of the highest costs in development is not having known the simple way of doing something. How often have you had hours and hours on a problem, and while chatting with someone realised that all could be done in a few lines of that piece of code you did not know exist. By having everyone discuss the development of the current story, all brains are involved, and more often than not a better design evolves from the continuous mind stream we share.

Another very high cost is the continuous synchronisation teams that work in sub-groups have to do. Call them daily standup, code reviews, coding standard enforcement, these synchronisation primitives are expensive and wasteful. Because we all work together in one group, it becomes easier to norm, adapt each of our styles and ideas to one another until we become much more similar in the way we develop the code base.

As such, we save a lot of time. Synchronisation is no longer necessary, norming happens pretty quickly, we rarely chose the wrong design, and the code base has a nice unity to it that makes it more maintainable and reduces technical debt quite a bit.

Of course, mobprogramming is no silver bullet. You need a sense of decorum very specific to long-running conversations in groups. From notifying others that you are not participating due to emails, to letting people know where you are and for how long, to deciding who attends meetings, many little problems can come up. As we applied the null design idea, we started with no rules, and slowly added a few as problems were felt by the team.

Let’s not kid ourselves, even months of mobprogramming will not turn the less senior people in a team into replacements for the most skilled people in your team. But I would argue that the level of learning across a team is higher in a mob than it is in a traditional orgranisation. There’s no miracle but there’s a clear improvement.

We mobbed all the time. What did we do with those long hours of boring code that needed to be worked on? The answer is quite shocking, those never materialised, because we never wrote that code. Configuration was nearly non-existent, build scripts were written once and worked across all projects by convention, and so were deployments were as well. Each small task that felt like it needed a procedural, hard to maintain script and manual process would be automated,applying simple conventions, and just not boring. And for the little things that were left, you could do them in flight while the rest of the mob kept on going.

A couple of months in, I asked the team if they wanted to spend a little less time mobprogramming so they could practice coding on their own as well. There was an overwhelming feedback that this was not needed and not welcome. A surprising result that certainly confirms my belief that mobprogramming may well be the biggest advance in development since the original XP.

When agile practices are used just to be used, we’ve lost track of why processes and rules exist. Rules come with costs, and only when the benefits of having them surpasses their cost can they be justified.

To figure out how this new team could work together, and taking into account Conway’s law we started with what I call the null design.

To start with, you remove everything. Practices, code, knowledge, we start from 0. A greenfield team of newborns. This is chaos, as if you have nothing, no one has any idea of what they should do or how. If you let this happen, you end up with a bunch of babies crying all the time and soiling their underwear. Not a pretty sight.

While evolution took millions of years to evolve from single-cell organisms, and babies take about 30 years to become useful, we didn’t have that much time on our hands, so we started with what we knew.

First, we started with the development practices we wanted, and a rough idea of how we would build components. We wanted a decoupled cloud-hosted infrastructure, with microservices, a quick development iteration turnaround, continuous delivery and use VeSt to ensure we could build this and refactor it quickly.

What the software was to do, we knew. We were, after all, replacing an existing system. The existing system was a big fat mess of legacy code we had tried to massage into submission for many weeks before the reset, so everyone had some sort of understanding of what was needed.

And relying on this would have been a big mistake! Take an existing design, replicate it by not re-doing the analysis, and you’ll end up with the exact same existing design. You need to separate required complexity and the accidental one. You also need to make sure everyone on the team had the same understanding of how things should work.

So we forgot everything, and started with one user story. By the virtue of VeST being BDD, we knew we started by writing our first user story and our first spec.

Mind you, temporary amnesia is hard to do: it’s an iterative process by which each story leads to whiteboard conversations and a model being discovered. I annoyed my colleagues many times in such conversations by refusing to hear any discussion about “there is also…”. Not that existing knowledge is not useful, it is. What is not is looking forward many stories ahead and altering our understanding of the required behaviour by including concepts only half of the people had an understanding of.

Instead of optimising up-front design, we optimise for the capacity to change the design later, cheaply. Developing software is a journey, in which learning is the hardest part. By being voluntarily naïve, we got from segregated knowledge to rebuilding a shared understanding, one story at a time. And like pyramid builders before us, we started work after choosing the sharpest and best tools for the job.