I was doing some training with middle managers the other week. We were exploring ways that they can help support their teams and organizational change. The topic of agile team co-location came up and we dove right in.
For them, co-location was a hard problem. They had little control over where their team members were located. Members of any given team might be in the same building, even on the same floor, but company policies made any moves difficult. One manager regaled us with the story of his efforts to move one team member closer to his cubicle. That team member was on the same floor but the opposite side of the building. In the end he successfully got his “move of convenience” approved but only after much effort. Seems moving people around is strongly discouraged to keep everyone from moving too often.
At first we all thought this policy was silly. How hard could it be to just have someone trade a cubicle or even move to an empty cubicle that is more convenient to the people someone needs to work with? Why would there be such a policy? Surely moving someone is not so expensive that pinching those pennies is a mandate!
Logical Policy
Company policies are not created to make our lives miserable. They are put in place for a reason that someone thought was beneficial. We had to think about this policy and imagine how it could be logical. I brainstormed a bit on what would be the logic for such a policy.
- Moving often is disruptive to people outside a particular team.
- Moving a person does incur some costs in administration of the network and phone system, as well as some lost work time.
- People may want to move for non-work reasons, like wanting to change because one building is personally preferred over another.
- Any one person might be on multiple teams and multiple projects. Moving around for each team membership is not practical.
Wait. Did you catch that last one? That is the big hint!
Multiple Team Membership and Co-location
At this particular company they are still in the initial phases of using Agile. It is common for one person to be on several teams and be assigned to multiple projects. You know, the usual “Spend your time 30% on Foo, 45% on Bar and 25% on Apollo, along with the maintenance work of the legacy stuff.” Given that one person can be on multiple teams, moving to be closer to any one team does not look very valuable. And to which team would you move closer? Barmight be your “top” priority for now, but not for long. And when that ratio changes, should you move yet again? No, since one person is on many teams, it makes sense to stay put otherwise everyone would be moving around all the time!
Image CC by jfcherry on Flickr
Don’t Fight Symptoms
In this case, the managers could decide to take on the fight for co-location. They could burn up their goodwill with their managers and customers, fighting to have their teams’ members moved close to each other. They could make presentations and have many lunch discussions on the benefits of co-location. And all that work would probably be rebuffed. Why? Because in an environment where one person is on many teams, assigned to split their time multiple ways, co-locating is not logical. The policy against moving people is a symptom of the way people are given work. And no amount of arguing to solve the symptom will overcome a policy based on a different problem.
Before you take off on a long effort to “do agile right,” dig deeper to see where your effort could be better placed. Solving the real problem will fix the symptoms more sustainably than fighting for a righteous cause.
Good post. I agree the lack of co-location and the difficulty moving is symptomatic of a much deeper problem. You comprehensively address the last brainstorming point in this post, but not the other three. I’d like to take a go at that…
—Moving often is disruptive to people outside a particular team.
I’ve worked in cubicle environments where people were moved about frequently. The disruption factor kicks in when people either don’t understand why they or others are moving (another reorg!) or don’t care. When people clearly understand the purpose and see the value the “disruption” becomes excitement, and people (even those not being moved or being moved away to create team-space) will become engaged in the solution. The symptom here is disengagement.
—Moving a person does incur some costs in administration of the network and phone system, as well as some lost work time.
This cost is known to be minimal when compared to the benefits of co-location. The difficulty is that company’s never having worked with true teams do not know of this value. There may also be a fear of loss of control from some management types, following the divide and conquer (need-to-know) rule of managing people. The symptom here is fear of change, and hanging on to old ideas.
—People may want to move for non-work reasons, like wanting to change because one building is personally preferred over another.
Yes! Why not? People work best when they are comfortable in their environment. Of course, there will be problems if one building or space is vastly better equipped than the others, or has more beautiful views or facilities. The symptom here is short-term thinking and mistreating of employees. All buildings should be equally compelling spaces to work in. management need to work with their employees to understand the needs of the workers, rather than (as often happens) keeping new/junior employees in crap spaces and pandering to the superstars. The symptom here is also inequality.
Thanks for getting me thinking this morning!
Some interesting follow-on answers, Tobias. I learned from your ideas.
In the case tha triggered this blog post, the last point was the situation. And it was an interesting realization for me.
Nice post. I think that this symptom is often found in transition phases, where the old hierachical team setup is still in place and the managers want their ‘teams’ to sit together. So, the idea that people from this ‘temporary project team’ should sit together doesn’t seem worth the effort to the managers of the team. So, in my book, a middle manager not actively pushing his team members to co-locate with his project team is a middle manager not having fully embraced his role as a leader in agile context. If, as you’ve described here, the middle managers try but fail to help co-location, this really hints at larger problems with the organization in going agile. The only thing that might help is trying to make the problems visible and working on the small details (e.g. trying to get mobile phones instead of wired ones and getting laptops instead of workstations, in order to lower the ‘moving’ around costs).