At Agile Africa 2013, I presented a session about lessons learned living through apartheid to democracy and how this manifest itself in teams in which I found myself during those times. Each period has many little stories, all relevant to the way we behave when we work together, especially in quite diverse teams. I’m not going to focus on these stories, but rather on the main theme of that talk. The slide deck for this session is available here.
The first time I spoke about this publicly was in 2010. It’s taken me a while to articulate this particular aspect. This is the first time I’ve written about it and I want to share that. It is my take on a concept that I find is handed out too easily in agile software teams – collaboration. I have chosen specific words to describe different kinds of relationships. My usage might differ from their dictionary meanings.
Now let us start with the first period – the days of apartheid.
In the apartheid years of S.Africa we had a distinct “us and them” political and social structure. It was whites holding a superior position over blacks. It was only beneficial to one – those that held the superior position.
I call this kind of relationship contempt. There is no trust between people and no shared values too. The only value system that matters is that of superior. This is a case of oppression. It is the oppression of another’s values and identity and of freedom of choice. Hence, we feel imprisoned. The consequence of this is the under development of the oppressed.
When have contempt, there is no chance of working for mutual benefit in any kind of way. It is just enslavement. In software teams, I’ve experienced this overtly, without any facade or subtleties. Some have been extreme cases, reflecting the bitterness of racism entrenched in our bigger society. More common, though, are subtle situations of contempt. For example, a developer considers another developer as less skilled – stupid to be precise – then we have relationship of contempt. Architects and developers, managers and team – these are instances of “us and them”. We can have such titles, but it is the attitude that arises when we build a culture where one holds themselves superior to others.
In the early 1990’s South Africa entered a period of transition. We were dismantling apartheid and building a new political and social system that ensured that we never go back to subhuman bondage. This required enemies to find a way to work together for the survival of both.
I call this a co-operative relationship. It is when both sides still retain their own values, but find a way to fulfil a common objective. To achieve this common objective requires them to build trust. I imagine trust as the payload carried in every action.
I sometimes explain it like this. If we were renovating a kitchen, then the brick layer, the plumber and painter need to co-operate in order to complete the kitchen on time. Each of them have their own work ethic, which is largely tucked away and insulated from the rest. They need to agree on certain things like the bricklayer will complete the kitchen before the plumber can put in the taps, and the carpenter waits for the plumber before building the cupboards. Should one not honour their commitment, then trust is destroyed because it affects the integrity of the others as seen through the eyes of the home owner.
This is the most common type of relationship that the majority of software teams practice. We only need a co-operative relationship to build a reasonably efficient cross-functional team. Unlike contempt, people are no longer treated as inferiors. Instead, everyone stands on their own pedestals of similar height. The only thing that binds the team is the trust that comes from executing specific actions to achieve the common goal.
Most people call this collaboration, but I call it co-operation. I can understand why we consider this collaboration. It is the degree of trust that is necessary for this to emerge. It is also reinforced by giving a team a name as a sense of common identity. For me, that kind of naming leads to tribalism. We gather to paint our faces in familiar markings, exhibiting the same brand. Our behaviour becomes one of exclusivity than inclusivity. It reminds me of the tribes that formed in the somewhat controversial book Lord of the Flies. Pretty soon, we have intertribal tension. This actually pops up quite quickly in multi-team Scrum implementations where all teams are working of a common backlog. That backlog introduces real or invented dependencies between tribes, and so the tension starts emerging; just a shadow of first but easy enough to envelope all in darkness.
So, what then, do I consider collaboration?
After South Africa ushered in a new constitution, and successfully held its first democratic elections, the cracks started to appear. We heard words such as “we need nation building”, “we are a rainbow nation”, and more recently “everyone can lead S.A.”. All these words refer to one thing – we need to share a common identity. That is what collaboration is for me – we have trust and now we focusing to share a set of values that exposes a powerful new identity. It does not mean that we ignore or assume the presence of trust. Our actions still carry a high payload of trust. That never stops.
Building a shared value system is not easy, nor quick. It is a challenge because each of us in this collaborative relationship have our own hierarchy of values. Now we are being challenged to reconfigure personal hierarchies to overlap. When we identify those intersections, then we are standing on the same pedestal.
When we work of a common platform – of even just one common value – then our basis for existence changes. We stop becoming exclusive and starting behaving inclusively. When a “stranger” walks in, seeking participation, then we look for that tiny tendril that allows them to plug into our shared values. Over time that tiny tendril grows stronger, and deep roots are planted. Sometime the new person enlightens us and we expand our value system too.
What happens if that new person does not have that thin tendril that we can plug in? This maybe a meta-value. The one value that is necessary for collaboration to take root is that we respect all values; being prepared to explore the adoption of any value. If we don’t have this single meta-value then we can’t bootstrap collaboration. Without this meta-value we are unable to explore any value. Collaboration comes to a halt.
The good news is that the each person does not have to have deep roots into the value system. Tapping in lightly is enough. The depth of the roots that are grown is tied to each person on that platform. Those with shallow roots will move on to other teams that allows them to grow a deep root. The period of time when they planted that root so shallow is still a wonderful time because we shared an identity. That we cannot take away. Inclusion is a way of growing.
When people anchor themselves deeply into the value system, we will find that those teams have a longer life. This is because we have a pathway to succession. Having strong roots means that we create sufficient time for others to grow strong roots too. In this collaboration, our sense of tribe is meaningless because the values will nourish and support generations of people. Having a name becomes a label for the values that define us.
A closing thought agile adoption
I’ve tagged this with XP (extreme programming) as well as agile, and ubuntu – the zulu philosophy. XP is what made me aware of the power of values in a team. In my ignorance, I often attempted to instil values very early in a team. I thought that I needed to build from a solid foundation. It never worked. I found that building a collaborative team is inverted. We build the walls and the roof before we build the foundation. The walls and the roof is trust that is needed, and the foundation is the values that are nurtured.
A collaborative team, as I describe it, is rare. It may take years to establish that foundation, with lots of corrections along the way. That is ok. That is the journey. Enjoy it for exactly that.