Home » Posts tagged 'colocation'
Tag Archives: colocation
I don’t think I can fully communicate the value of co-location.
Any time I have been asked to help a company in recent years, the engagements have started out with an assessment. I don’t believe that I can provide sound advice unless I understand what the problems are and what the organization’s capabilities are.
One problem that EVERYONE has had so far is the absence of an effective place for their teams to work. Software development is a highly creative endeavor that requires (usually) a significant amount of collaboration between teammates and it constantly surprises me how organizations build terrible places for teams to try and achieve this!
When we started out with the client whom all of these Success Factor posts are about, the development team was spread out across ½ of a floor in an office tower and there were 2 members in a different city. Check out my hand-scribbled floor map with the initial, planned layout of the team members.
This is actually not bad compared to many companies I have observed, but this is far from optimal. The deficiencies that aren’t obvious from this floor map include:
- No team-specific collaboration space. Had to book meeting rooms and hope one was available.
- The Devs and PM have no whiteboard space. They are in cubicles.
- The BA, TW (Technical Writer) and CSM (ScrumMaster) were packed into a large office with minimal whiteboard space.
- PO (Product Owner) and HW (Hardware guy) were alone in their offices.
- There was no place to have daily stand-up meetings or to have our card wall up where everyone could see it.
- The sponsor was on the opposite side of the building.
For a team that is intending to collaborate frequently and intensely, this is a very poor setup. Our sponsor was spending in excess of $100k/month on the team in that room and he wanted to make sure we had every advantage to maximize that cost. So before we even kicked off the project, we made a rather bold request to have a board room near the sponsor converted into a team room. And our request was granted!! The facilities people were a little scared that we’d damage the boardroom table that was in there, so they had that taken out quickly, but the resulting floor plan looked like this:
Now we were excited! We had a room that could hold everyone. There was room for everyone but the PM and HW guy, due to the nature of their roles, didn’t need to participate as intensely as the rest of us, so they maintained their offices. And since our PO was also maintaining some business workload, she maintained her office as well. But all three team members attended all the meetings that we had in the team room and would often drop in to see how things were going. Let’s take a look at the team room.
I have to say, this is the best team room I’ve ever had the pleasure of working in. We had wall-to-wall whiteboards on the West and South walls, and the North and East walls where covered with large PostIt notes. The SE corner of the room had a projector screen and the projector sat on the SE corner of the team table. The computer on the East wall ran Skype and TeamPulse, the Agile Project Management Tool that we used on a daily basis (from Telerik). The room had a Skype account that was always logged in and you could call up that account and it would always auto-answer with video and put the caller on the projector. There were two microphones in the middle of the big table that would allow everyone to talk from where they were sitting with whomever called in.
I can’t say enough about the sheer wall space in this room. It was fantastic. On the wall-to-wall whiteboards, we had everything from architectural diagrams, to class diagrams, server layouts to retrospective results. We had everything on those whiteboards and they would be able to stay up for as long as needed for the team. We would write our retrospective notes up there, and leave them for the entire next sprint. Then the that sprint’s retrospective notes we be put up, and compared, and discussed. Then the former sprint’s notes would be erased. We had a constant rolling reminder of how important continuous improvement was to us.
The PostIt notes were used to keep less volatile things like our value statements right up in front of us. Also, team policies like our Definitions of Done, or our Prioritization logic where up there for everyone to see. There was never any doubt about how we wanted to work when you were in the team room.
We were creating a mobile system that included on-board tablets in trucks and we had our QA station right there behind our QA professional team mate, our PO and our BA! They could check specs, and then turn around and try it out right there in the QA environment. And if there was ever a problem, the developers could (and usually would) hear about it right away. That was one great aspect of our room that allowed our quality process become pervasive of everything that we did in that room.
I can tell you about a time that our QA lead was working on a test script in Microsoft Test Manager. Then he turned and tried the test step on the tablet and discovered a bug for a feature that was in the iteration. He called the developer over, who saw the defect right away. The QA lead logged the bug and the developer, whom had luckily just finished up a task, was able to pick up the bug and fix it right away. Our QA process was such that we could fix a bug, submit the code, all the automated quality checking mechanisms would run and then we could push the passed build up to the QA tablet where the bug had been fixed. In this particular case, the whole process took less than 1 hr. Discovered, Logged, Fixed, Built, Deployed, Re-tested, Passed. It is very rare for me to see a team perform this well.
But I totally believe that a big contributor is the team room that we’ve built for this team. Every team member feels the others pain when something doesn’t go right. This causes us to behave differently. Less selfishly and with a much more holistic approach to building the software solution.
And that was a known feature. The benefits of having the Product Owner, Business Analyst and Sponsor all within 20 feet of the developers is unbelievable. When anyone has a question about a feature or an idea that we’re trying to make real, the entire stack of business-focused people are right there, immediately available to answer the question. The only time that this team ever builds the wrong thing is when we are building something for someone who isn’t in the room. And you can bet that we escalate that immediately to our sponsor. Because he is 15 feet away.
And he just drops in all the time!! If he has a problem, he tells us. If he is curious how we are doing, it pokes his head in. He will see us working on a problem with our process and lend a hand if he can. And you can bet that this closeness has made the team much more aware of his concerns and challenges. It never feels like Big Brother is watching because there is so much transparency on the team that it is always about trust and helping to get the job done.
I could probably go on and on about all the benefits of this team room but I’ll wrap it up for the moment and leave the rest to your imagination so that you can think about what the benefits of this team room would do for your team.