Patterns of Collaboration for Collocated Teams

Collaboration is one of the most important aspects for successful Agile teams. However, after working with many Agile projects, I realized that collaboration goes beyond simply working together. True collaboration means asking the question, “How can I help you?” As in, “How can I help reach your/our goals? How can I help remove your roadblocks?” I feel the simple phrase “How can I help you?” should become part of the default culture of Agile teams and organizations. Focus should shift from reaching “my” goals to “our” goals.

In this post, let’s take a look at some key collaboration patterns for collocated teams that are helping many teams worldwide.

No Hierarchies

Collaboration prospers in environments with no hierarchy. I still see teams that have evolved from a deep hierarchical cultural background. Agile has no specific team roles, and everybody works in a generalist style. But in teams and cultures with an hiearchical mindset, it’s not uncommon to see junior team members calling their seniors as sir, madam, etc. An hierarchical mindset almost always kills a collaborative mindset. Remember, hierarchy has nothing to do with team culture, but has more to do with an organization’s culture.

Swarming

Irrespective of whichever Agile framework you work with, it is frustrating to have a team looking very busy — with lots of items in the “In Progress” column — but nothing with a DONE status. This is one of the natural repercussions for teams that use standup as a status update meeting.

One of the key tenets of Kanban is to reduce the cycle time of user-stories (i.e., move user-stories to the DONE column as soon as possible). As I discussed in a previous blog, “stop starting, start finishing,” is the famous Mantra that needs to become the anthem of every team.

By embracing this philosophy, many teams have moved towards a culture of Swarming. In this approach, instead of only one developer working on one user-story, multiple team members focus on finishing a single user-story as soon as possible. Swarming is not limited to certain ceremonies like standup, either; it is a team culture.

Pair Programming

Although statistics show that high-performing teams almost always pair on tasks, in reality, many candidates in the Shu state (Shu Ha Ri – ?) of their Agile journey outrightly reject the pair programming approach altogether. Their argument seems to be logical: isn’t it a waste of effort or so-called “resources” to put two people on the same task?

The fact is that pair programming is not just about a pair of typists, but much more. “Evolutionary design” refers to a design that is well thought out and that evolves continuously. It provides the bare minimum functionality but can still be achieved at runtime. This being said, pairing discussions help programmers move towards evolutionary design.

Furthermore, pairs don’t get distracted as a normal solo programmer would. This may be surprising to people who never practiced pair programming, but it’s entirely possible for any team member to resume any user-story at any point in time — like a relay race member. There are no more hidden islands of knowledge. This approach also enables key developers to move on to new projects instead of getting stuck in a project just because they are key team members. So as you can see, pairing is an important pattern for collocated as well as remote teams.

Team-Driven KPIs

During one of my presentations, a member from the audience told me a very interesting story. He said, “I worked in a team that followed all these cool ideas and principles of working together as team collaboratively. Personally speaking, they all make a lot of sense and work well for teams. Our team also worked in close collaboration among developers and testers. The bug count was tremendously reduced because of how we helped and supported each other. However, when it came to performance appraisals, I got pulled by my manager just because of the same reason — the number of defects coming out of the project were very low. My KPI was driven on the number of bugs extracted.”

Doesn’t that sound shocking? And yet in many organizations, that’s the ground reality. Teams move on to Agile, but the organization somehow does not. This disconnect can have an adverse effect on collaboration between team members. Agile is a cultural change and cannot be limited to just a team-level; it must be embraced by the entire organization. However, in this particular scenario, it’s important to have team-driven-KPIs instead of individual driven KPIs.

Cardwalls

Many organizations in India work as outsourcing service companies. Since most customers are located in the US, Europe, or other parts of the world, it becomes important to use electronic tools like Jira, Trello, or Rally to transparently look at team progress. That’s important for the customers and makes a lot of sense.

However, electronic tools are more like refrigerators in that you need to open them and then look for relevant information. Using cardwalls can be a much more effective way to keep track of a team’s work. Of course, the obvious objection is, “Why use cardwalls when we already have electronic tools?” And to be honest, I never used cardwalls or saw them being used before I worked with an onshore customer team.

However, while working with physical cardwalls, I realised their importance. They significantly change the way a team collaborates because members have discussions around them, and the standups start looking real. Team members can move cards around physically, everyone can understand what other people are working on, and standups become sync-up forums rather than just status updates. Standups also become shorter, and the team focuses on sprint progress rather than individual progress because they can actually see this progress on the wall.

Shrikant Vashishtha is the Director of Engineering for GlobalLogic’s CTO department. He has over 15 years of experience in the IT industry and is currently based in Noida, India.