Software geeks know that registers fetch data roughly 10 times faster than the L2 cache, 100 times faster than main memory, and more than a million times faster than hard drives. Smart software engineers work hard to keep all the data for their inner loops in registers or at worst the L2 cache. They keep the rest of their time-critical data in main memory, and they only go to the hard drive when absolutely necessary.
Continually fetching data from main memory or the hard drive while in the inner loop of your most time-critical functions would be madness. I mean, why would anyone in the computer industry be so breathtakingly boneheaded as to deliberately distance data for the most common critical functions? Wouldn’t you want to shake such a person and scream, “What the heck are you thinking?!?”
What is the inner loop of software development? It’s a developer writing code. Placing developers’ keyboards and screens on a different floor from their desks would be absurd. What is the next most inner loop of software development? It’s collaborating with your cross-discipline feature team (Scrum team or feature crew). Yet cross-discipline feature teams are commonly separated by long hallways and entire floors. It makes me want to shake the managers and executives who arranged such seating and scream, “What the heck are you thinking?!?”
“Yeah, but I sat in a shared space once, and I couldn’t get anything done.” You are absolutely correct.
The worst place for productivity is a shared space amongst people working on unrelated feature areas. The chatter around you is noise—irrelevant, distracting, concentration-killing noise. Sitting in a closed office would be a big improvement—you’re isolated from your feature team, but at least it’s quiet.
The best place for productivity is a shared space amongst people working on the same feature area (typically three to 12 people). The talk around you is pertinent and essential—it’s the relevant information you need to avoid issues, save time, and arrive at the best design and code. That’s why after I created team rooms my development leads (who had individual closed offices) voluntarily chose to move into the team spaces—that’s where all the action was.
If you have developers in a team room who need quiet to get into a flow, have them wear headphones. Establish rules around interrupting people who are wearing headphones, and have focus rooms where people can make calls, do interviews, and otherwise make noise unrelated to feature work.
As for the ideal team room setup, I let the feature teams configure their own space. It gives the teams more buy-in and lets them arrange the room to their preferences. The only essential is to restrict the space to feature team members. Even one outsider is enough to be a distraction and introduce noise instead of value.
What difference does colocation of cross-discipline feature teams make to the inner loop of software development? I’ve come across many studies that indicate the benefit is substantial, but none from Microsoft. So when my group was scheduled for an office defrag a couple of years ago, I started collecting data for the six teams reporting to me. I compared the per-week average of feature work completed for the few months before the move (when people worked in offices or cubicles arranged by discipline or office availability) to the average completed for the few months after the move (when cross-discipline teams worked together in team spaces).
One of the six teams was stabilizing for a release and thus doing very little feature work. Even so, that team completed 10 percent more feature work per week on average than before the move. Three of the teams were 20–26 percent more productive than before. One team was 55 percent more productive, and the sixth team was 62 percent more productive.
So let’s recap my little experiment. The five cross-discipline teams of five to 10 people each that were actively working on feature development gained a minimum of 20 percent productivity just by sitting together. In other words, they gained an extra day of a development each week. One team got three extra days per week—and still had two days off for weekends. The teams have maintained those output levels ever since.
How did one team gain three extra days per week? The members broke down their work into smaller chunks, assigned work to team members on demand instead of in advance, and used the team space to stop and gather together to solve serious design issues whenever they came up.
Given the overwhelming advantage of locating cross-discipline feature teams together, why would any manager or executive be so boneheaded as to sit them apart? These are software managers and executives—people with intimate knowledge of computers, caches, and latency penalties for fetches to disk. Why would they deliberately place the data sources for the inner loop of product development so far from each other? Rather than claim these managers are imbeciles, I’d claim their reasoning is simply misguided by obsolete practice and out-of-place priorities.
The lean approach to software development—specifying, implementing, and validating a feature before taking on the next feature—is only a decade old at Microsoft. That may sound like a long time, but it’s recent enough to have missed when many upper-level managers were still actively developing software. Some parts of Microsoft still use a pure waterfall model instead of feature crews, improvement teams, Scrum, or Kanban.
Managers and executives without lean experience may think, “Developers mostly work with other developers—therefore, they must sit together to be productive.” That’s true for pure waterfall teams, but team members using any modern and efficient form of software development spend most of their time engaging with their feature team colleagues, independent of discipline.
Managers and executives may also think that engineers should sit with their discipline group for career growth. That’s a great reason, but career mentorship and guidance is part of the outer loop of software development. The inner loop is developing the product—feature teams. Feature team colocation takes priority. Feature teams go in the registers and L2 cache of the team room. Discipline teams can be in main memory down the hall or on a different floor.
If having feature team members separated by a hallway or floor slows you down like pulling data from main memory, then splitting your feature team across cities and time zones is like fetching that same time-critical data from the hard drive. What a disaster! Managers who organize feature teams with members across continents really should be forced to use US mail for all of their communications.
Distributed development is great, and it can be done well, as I describe in So far away: Distributed development. You just shouldn’t split the inner loop of software development across locations. Separate the work across multiple feature teams, and then locate those feature teams together in their local team rooms.
“Yeah, but what happens when the features or feature teams change? Now I’ve got to move people constantly!” No, you don’t. The best thing to do is keep feature teams together. Like any team, they get to know each other and work better together over time.
Of course, sometimes people come and go, and sometimes you need particular people on particular features. In those cases, keep most of the feature team intact, but alter a couple of the team members as needed. A healthy team will gladly absorb the new viewpoints and talents.
Over the years, I’ve gradually turned over the membership of multiple feature teams an individual or two at a time. People are happy to join teams that work well together—the team’s positive culture is contagious. My supervisors have always remarked on how my teams maintain their productivity, even when changing key members.
People aren’t computers with CPUs, caches, and hard drives. However, people’s productivity does depend on fast and easy communication with the folks they work with most. Microsoft managers and executives have long known this, which is why after every reorg, there’s an equal and aligned office reshuffle. However, those office reshuffles often focus on discipline and reporting structure, rather than on placing people closest to those they work with most—their feature team.
Yes, your discipline team helps you grow, but your feature team helps you ship. Mentoring is important, but it’s not the minute-by-minute central activity of your day. That activity is doing your individual work and working with your feature team.
Easy, cross-team communication dramatically increases productivity. I’ve personally seen it add the equivalent of one to three extra days per week—days we all could really use. There’s no excuse in this modern age of devices and services not get the most out of your time and teammates. Be together to ship together—make your team room the place where magic happens.