01 Dec 2017
Imagine you give 2 people a problem and 2 weeks to solve it. They decide that each of them would do nothing for a week. They also agree a handover for passing whatever findings from the first person to the second on the 7th day.
That’s how design ahead feels to me.
To be specific, by “design ahead” I mean when the design team works ahead of the development team in order to “explore” or “validate” possible solutions to a problem. “A problem” could be as big as the whole product and most people would recognise this as waterfall development. But you can do design ahead for a problem as small as a specific feature. In this case though a lot less people recognise it as waterfall even though the only difference is the size of the problem and the timeframe to solve it. The process is pretty much the same, as I was trying to illustrate with this slide a few years ago:
The main source of concern that pushes teams to do design ahead is developers having to change something already implemented because it wasn’t the right thing to implement in the first place. This is understandable if anything because deadlines and budgets are always very tight.
But why wouldn’t design be right in the first place?
Sometimes the product has a stakeholder that “needs” to sign it off but is not involved in the day to day. To avoid the potential waste of having to redo something design seeks sign off ahead of implementation.
Sometimes designers are not sure that the solution they have in mind is adequate. Sometimes they don’t even have a solution in mind! So they want time to properly look at the problem in order to find something that they are comfortable works. Maybe run a couple of user testing sessions to get early feedback from users.
Sometimes design and development can’t work closely together. Maybe there is no relationship between the teams, maybe design and development are done in different rooms, floors, buildings or companies.
Sometimes design and development simply don’t want to collaborate. It may sound harsh but there are many individual contributors that struggle as part of a team that requires constant collaboration. They are easy to recognise because they constantly complain when required to step away from their own computers. They are more worried about their own performance than the team’s performance.
In the worst possible version of design ahead designers have no contact with developers when they are coming up with their solutions. In this case design and development have no option but to do pure waterfall: handover of software specifications in some format.
In the very best version the whole team gets together for sketching and / or example mapping sessions in order for all disciplines to be able to contribute and gain shared understanding of what is coming down the line.
In most cases designers informally seek some sort of input or validation from someone from development, maybe a tech lead, in order to reduce the risk of designing something that is not feasible or very expensive to build.
Note that in all of them the problem is not the team exploring and validating solutions, the problem is when it’s an activity carried out by one single discipline.
The problem with design ahead approaches is that they have a limited impact on actually reducing the risk of waste. Sometimes design ahead will actually increase the risk of waste.
Informal check-ins between the disciplines tend to be very shallow because everyone’s desperate to go back to the work they have committed to, effectively nodding away the person asking without much consideration for the question at hand. To make things worse, by the definition of design ahead, designers and developers are working on different things, hence their context at the point of someone asking a doubt is completely different, decreasing their ability to answer properly and increasing waste by having to switch context twice (once to answer the question, once to come back to whatever they were doing).
And because there are technical issues (and opportunities) that do not surface until developers get down to implementation, there’s always going to be certain amount of questions or doubts arising. The problem is that at this point designers are busy preparing what comes ahead so either:
By having designers and developers working on different things we artificially put them out of sync.
But there other problems too. Any solution thought through by only one discipline (design in this case) is unlikely to be as rich as one put together by a group of people with a more diverse set of skills and backgrounds. Worth mentioning that I’m not advocating for design by committee. It means that designers have more sources to draw from when coming up with a solution. It means higher chances of covering critical aspects of a solution earlier in the process.
Let’s start by listing some assumptions, values and behaviours:
So, if you agree with the things above you might be willing to try mob programming:
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. This extends the concept of pair programming […] to the entire team continuously collaborating at a single computer to deliver a single work item at a time.
Everyone in the team working on the same thing, at the same time and at the same computer. Designers, developers, testers, data scientists, product owners… putting their brains and hands together to solve a problem. I think it would be amazing, even if it was “just” for 4 hours a day.
Imagine a team that has a product that has a vast catalogue and wants to allow their users to search it. Does it need search as you type? Filters? If so, which filters? Search queries are complex, do they allow users to save their search queries? What about saving the results of the queries in case something goes out of the catalogue? What happens then if something gets in the catalogue after the search that matches the query? Could we calculate ahead of time results for the 50% top queries in order to speed results? What’s the appropriate level of ambition for this particular feature compared to the rest of the things in the backlog?
Now imagine the whole team discussing these options, trade offs, how to quickly get to potentially shippable, sketching possible interfaces, uncovering opportunities… everyone in the same mental space, focused on solving the same problem, around a single whiteboard or keyboard. Whether the task at hand is sketching, UI design, getting feedback from users or coding (front or back!!!): One team, one focus.
You might wonder why 4 hours and not more or less? Absolutely arbitrary, but the idea being leaving individuals some alone time to have a little spike or exploration of a very specific problem, maybe developers need a very technical session to refactor something that was quickly put together during the mob session or simply allowing people to decompress because working so closely with other people tends to be very demanding from a mental perspective (more on this later).
The expectation is that mature teams eventually self-regulate and find the right amount of time they need together.
These are some of the benefits I would expect from a mob programming team:
Mob programming won’t come without challenges, some of which might be deal breakers for some teams:
I don’t have all the answers to these questions, I can only guess how I would approach some of them.
But there’s an interesting challenge I’d like to discuss in more detail: the pressure to come up with and implement solutions fast.
Coding or designing on the spot, in front of an audience so to speak, will be challenging for many.
Some of that pressure comes from the fear of making a mistake or not knowing something that maybe you believe you should know and doing so live in front of the team. The way to tackle this is with a set of shared values of respect, empathy, open-mindedness, humility, etc. Without those values in place some people might completely freeze or have a very painful experience with mob programming.
Now, there is another part of the pressure that comes from having the team “waiting” for you as the designer to design something or you the developer to code it.
I believe that that pressure is good, hoping it will lead to designing and implementing simpler solutions in smaller increments.
Personally I would love to find a team and a client at ustwo willing to give cross-discipline mob programming a proper go, but this is not easy.
In the mean time, I would love to keep hearing and reading everyone else’s stories and experiences with mob programming, good or bad.
Please send them my way at
es or gimme a shout on Twitter.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.