When I started as an Agile coach eight years ago, my only relative and somewhat debatable “agile” experience was some iterative development we did on a very large product over nearly 19 months. This was a project where we worked with 6-week iterations for 14 iterations!!
One thing that project taught me was the value of getting two engineering teams – development and testing – work together without the usual wall separating them. Having been involved with heading an independent test team, I can tell you how difficult it is to change the mind-set of test engineers from working independently validating products to working collaboratively with the development team, in building quality into the product as you develop it. The same is true of the mind-set of the development team in accepting the test engineers as part of their team.
The first team I coached on Agile had the development and test team sitting in separate floors of a building. When I brought the subject of co-located teams and recommended that the development and test engineers sit side by side on the same area in the same floor, I was given a haughty look by the concerned test manager.
Fortunately for me the Delivery Manager was very open and pro-agile and helped me convince the test manager. After a huge reluctance the test engineers (about 5 or 6 representing two separate scrum teams) moved to the same location close to the development team.
You could really see the cold war that existed between the two teams at that time with neither side talking to the other in the first few days. The test engineers continued to go for lunch with their friends in the other floor while the development team continued to be together.
Things started changing after a couple of weeks. The test team needed clarifications from the developers for writing test cases and the hitherto mail route for clarifications was abandoned for a quick face-to-face chat. Subsequently the development engineers felt free to approach the test engineers for trying out a developer build on their machine and slowly they started interacting more and more.
Over time I could see they developed a mutually healthy respect for each other – something that is not so common in traditional set-ups.
My recent experience with another large enterprise was quite similar. The only difference here was that the development and test teams were already co-located but both had to work with another team – the database team – for implementing stories.
The database engineers were part of the scrum team but were sitting separately as a functional group. They attended the scrum meetings but not very regularly and even when they did, they often would give their updates and walk out citing some reason or the other. The development and test engineers used to grumble about the database engineers not feeling part of the team. While I brought out the importance of having the DB folks co-located with the Scrum Master, he wanted me to help broach the subject with the DB team manager.
Fortunately I had no difficulty in getting the DB manager accede to the move to co-locate the DB engineers with the rest of the team. This actually worked wonders within a month. There was a much quicker resolution of issues involving the DB team, a good working relationship built with each other across the entire team and needless to add, the team productivity and morale improved.
Before concluding let me deliberate one important point. It is true that co-location of teams usually improves collaboration but are we saying that effective collaboration is not possible without co-location of teams?
Certainly not, because we have seen many open source software development teams collaborate brilliantly across virtually all time zones without having ever seen each other. What then is the reason for their successful collaboration?
My two cents on this is that it has got to do with sharing a common purpose, goal and the passion to ensure that they succeed as a team. The overarching culture of the open source movement, the do’s and don’ts for individual contributors and the rewards system are all well-accepted and act as the “norming glue” for people working on the same open source product across distant lands.
The role that you play, the contribution that you make as an individual etc. don’t matter as much as what the team working accomplishes. Co-location helps improve this significantly but basic tenets and norms of effective team work are far more important and cannot be understated.
So, to me the first step in Agile transformation is to ensure that the environment is right in terms of culture and teaming (through vision, goal setting, communication, collaboration and co-location as far as possible). And I am sure you would agree with me that it’s usually not such a baby step! While I would be sharing my own experience on this in one of the future blogs, here are some questions that would promote an interesting discussion in this forum and I am keenly looking forward to it.
- Do any of you have any experience to share on this?
- How important was co-location of teams in your project?
- Have you seen any patterns that reduce the stress of distributed teams?
- Do you have any quantitative results to share in terms of improvements when you moved from distributed teams to co-located teams?
