Tuesday, 3 November 2015

Why do we cooperate lesser than what we should?

In social ecology, there is an interesting theory by Hamilton which discusses the relationship factor in the cooperation among individuals. According to it, we cooperate better with others who have closer relations with us. The theory says that we are more likely to help our siblings than our cousins; and our cousins, than say, total strangers.

I think the theory applies to a project team also. Many virtual species (biologically, all of us belong to the same species) co-exist in a project; as developers, testers, ops, architects and oh! not to forget, the managers. A member of each species is more likely to cooperate with another one from the same species. Thus, the developer collaborates better with another developer than with a tester or ops.

Why do these virtual species exist and why do we let them limit our cross-functional collaboration? Most of us would agree that better cross-functional collaboration would help us to be more agile.

The virtual species are created by the conventionally existing functional silos. The team members of each function are conditioned, and often provisioned to thrive inside these invisible, yet prominent walls.

We should bring down these walls; there is no other way for better collaboration.

Bringing down the Berlin Wall

Some innovative behaviors, like engaging the testers early, designing for Ops, continuous delivery, brainstorms, demos etc. may encourage the team members to scale their walls more often. Yet, until we remove the walls, the scaling would take wasteful effort.

Bringing down the walls need a more fundamental change in the organizational behavior. Let us find out how to.

Craig Larman proposed feature teams as a team structure better suited for cross functional collaboration. He has also mentioned how this would influence the organizational structure, line management and the learning and specializations. One of the characteristic of such teams is the balance between specialization and flexibility; which encourages the team members to grow as generalizing specialists.

I have come across project teams where the testers are encouraged to find more defects. It is often treated as a desired result of performance at work from the team member. With a performance goal as this, how would the tester be motivated for better collaboration by engaging early; early enough when the defects are not yet accounted for? The tester may rather wait for the opportunities later, for the defects to get counted. You may notice such behavior, which reinforces their respective silos, in other functions also.

Our message for collaborating as one team should be clear. One way is by doing away with such myopic goals and introducing shared incentives. Thus, the architect would no longer be rewarded for only better design, nor the tester would be measured with the number of defects found in testing. The whole team's performance would be measured on some key business results, like customer feedback, (lack of) delays or post-release defects etc. When the team achieves good results, reward the whole team.

Some of you may be asking now; are we being fair if we do like this? This would mean that every one in the team would stand to benefit when the team does well; seemingly with no difference in the rewards between the so called slackers and the heroes.