Many teams co-operate, not collaborate

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.

Extreme Programming is as relevant now as before

Extreme ProgrammingLast year I met a few people that had never experienced a waterfall project.  Their first software project was with Scrum.   What stood out for me was that these developers had not read Kent Beck’s Extreme Programming.  I also discovered the same for several that were years into their agile development journey – never read the XP book.

Perhaps we are past the sceptical stage, and the notion of working in 2 to 3 week cycles is not considered so extreme any more.  XP may not be as popular as Scrum and Kanban at the moment, but it is still intrinsic to successful agile software development.

I confess that I find a lot of the XP practices are difficult and I have certainly not mastered any.  I think it might be simply that software development is just difficult.  Another reason may be that XP warrants that I change my approach, shifting my attitude to software development quite fundamentally.  That is the extreme part of XP for me, not the 3 week cadence.

Here are a few aspects of XP that I have grown to appreciate over time.

XP makes being a decent human explicit

XP has a lot to offer for the welfare of each person, and for our collective welfare too.  In a software world where we are learning to embrace our diversity, these insights are valuable for nurturing what is still a comparatively young sector.  Certainly, XP offers values.  However, just declaring a set of values does not mean that we live our values.  That’s where XP’s principles and practices kick in.  These exist to nurture those values.  Having a shared set of values and principles is essential in a team, because we use these to help us eliminate options and make decisions.  Value based decisions always seem like choosing the harder option, but the payback is often greater.

XP is about fine grained feedback

XP introduced me to the idea of feedback and made me aware of the theory of constraints – that we just shift problems around when we introduce or remove constraints.  Now we see the rise of lean which focuses on one piece flow, not short time cycles.  That is a different constraint and we have new feedback points like pivoting and waiting until  the last responsible moment.  All these require explicitly designed feedback paths.

Producing a piece of software with one piece flow means that we must bake the feedback into the software we produce.  For example, if we redesign the landing page for a web site, then we need to bake in measuring page views and time spent on the page as part of the release.  Without explicitly thinking about how we receive feedback, we just end up producing a chunk of software that has very little value.  Once we have feedback loops baked in, we are back to observing the shifting of constraints.

XP practices such as continuous integration, collective code ownership, simplifying vigorously, small and frequent releases all aid in building precise feedback loops.  These practices directly support one-piece flow, devops, and continuous delivery.  Yet, most people are unaware that some of these practices are there to increase collaboration.  For example, when there is a problem in the build pipeline, then people will swarm to fix the problem.  It is the high signal conversation after the failure that is valuable.  XP helps increase the signal to noise ratio in our feedback  loops.

XP is not just process centric

As a developer, I am yet to find a set of practices that appeal directly to my work at the most basic level – working with code.  I’ve noticed that many teams that embark on an agile journey tend to focus more on an agile process, than their code base. After a while their code base becomes their biggest bottleneck.  Not obvious is that the potential to regress to a waterfall-like development process is high.  When we have little control over the code base, then we may well reach for more grand planning upfront, less frequent and larger releases, and longer testing cycles.

The code base becoming a bottleneck is not an event that suddenly happens.  It is an accumulative effect.  It sneaks up on us.  Some symptoms are a drop in throughput; it becomes more painful to build, release and deploy; and introducing a new feature needs design contortions.  I’ve referred to this before as “trying to sprint in mud”.   We expend a lot of energy, without going far.

The consequences of a code base out of control is the real kicker.  The code we write affects everyone, not just developers and our customers.  It introduces stress to everyone associated with the software – analysts, managers, customers, family and friends too.  That’s why in XP there are practices that help us keep the code malleable, interwoven with practices that deal with our collective welfare.

With a code base out of control, we can forget  about one piece flow, lean style.  The same goes for continuous delivery and devops too.  Even with the best build pipeline tools, a badly managed code base will not make life easier.  It is like using really bad quality ingredients to make an exquisite meal.

XP keeps a focus on design all the time

XP introduced us to test driven development and continuous refactoring to keep our code bases under control.  Some people use test coverage as measure of that.  I don’t subscribe to coverage as a measure of control.  I prefer weighing up the cost of defects against cost of releasing late.  For example, if getting a feature out means securing a market position, then I would go for lower coverage because releasing late will hurt more than releasing early with defects.  This might be a controversial statement but it is still a viable feedback option.

By the way, it is worth noting that TDD does not yield good designs.  Instead, it raises warnings of problems with our design.  Good design comes from another XP practice of always aiming for simple designs.  Simplicity comes when we gain deep insights into the domain.  Acquiring knowledge takes time – it is a slower feedback loop.  Consequently, achieving a simpler design occurs slower than churning out software at the end of each cycle.

XP allows for code first agile adoption

I prefer to emphasise getting the code base under control as my main target in an agile adoption.  I lean on XP heavily for achieving this goal.  Along the way, the people and process aspects slot in quite naturally.  As the code base is brought under control, it creates breathing room to introduce other non-technical practices.  I’ve found that it is less painful to focus on the code base first, XP style, and slot in other practices along the way.

When I’ve tried it the other way – process before code – I’ve experienced a kind of agility that is only skin deep.  The reason is that the act of adopting the code centric practices requires significant change in developers.  Until developers embrace changes in themselves, in the way they approach coding, the agile adoption will remain superficial.  By “superficial” I mean that it does not penetrate down to the code itself.

Superficial agile is not a bad thing.  I know of some organisations that will benefit from this approach, but only for a while.  For some, that is sufficient.  If we really want to go beyond skin deep agility, then I think it is necessary to reach for XP’s practices that deal with code.  There really is nothing else that deals with writing code in short cycles or one piece.

Should you read Extreme Programming?

My answer is a resounding yes.  It is a wonderful book, written with a lightness and easiness.  Yet is dense with deep insights in every sentence.  The one last aspect of XP that I cherish is that I could ease into to it slowly and deliberately.  I did not have to apply the entire body of work instantaneously, in one huge swoop.  And I am still easing into it.

Stay in bed or come to SGZA

I will be hosting a 3 hour session at the South African Scrum Gathering titled “Live your principles or stay in bed”.  You can read the abstract here.  In my opinion, there is far too little focus on software development itself in Scrum.  So, this is unashamedly a developer session.  I will be present various snippets of code, and we will “live our principles” to transform the code into something that is less messy.
I often hear developers, and managers too, saying “It’s so much easier without, so why bother?”.  Well, design is hard.  Applying principles for life is harder.  But if you are professional developer and have a conscience about your design, your code, and your product then “an easy life without principles” is not an option.

If you are planning to come along, bring your laptop with your development environment.  I will likely have code samples in Java, C#, Ruby, Javascript, and even, yup, Basic (well, maybe).  All the samples should be very readable and you could easily translate them to something equivalent in your language pretty easily.  Better still, bring some of your own code along, that you want to share.

In reality, this is stuff that Scrum does not teach you, but need to know to avoid Scrum burnout.  Looking back, I should have done something like this sooner.

The politics of software delivery

Software is all about delivering something useful to a customer.  That’s it – nothing else.  Politics is about acquisition of power.  Nothing else matters.  Now mix the two together.  How often have you heard a developer say something like “It’s not my problem, it’s just politics”?   That poor developer doesn’t stand a chance.  Imagine trying to deliver software while there is a raging power battle going on.  I don’t think software delivery stands any chance of success in that battle.  In fact, software delivery just becomes a tool for the politicians.
When someone is plotting for power, nothing else matters, not in the least software delivery.  I’ve been there and done that.  It’s just messy, soul destroying stuff.  These days, I look for the power battle and try to focus on software by raising the delivery stakes to higher than the power battle.  If I can’t do that, then the software was never the focus in the first place.  Then I recommend pulling the plug.  Regardless, that’s my cue to leave.  Not because I am a coward, lacking courage, but for the simple fact that those power grabs are completely meaningless, except for the power-hungry.

As long as there is a political game being played, you simply won’t deliver software on time, on budget and keep customers happy.  BTW you can just forget about collaboration too.  That space will always be filled with contempt.

Let me put it another way: Any attempt at being agile in a political environment will always lead to failure.  While you are trying to learn, others are trying to gain power.  It doesn’t work!

I wanna hold your ha-a-a-a-a-a-and

Do you remember that catchy Beatles song?

Oh yeah, I´ll tell you something
I think you'll understand
When I say that something
I wanna hold your hand
I wanna hold your hand
I wanna hold your hand

So what made me think about this?  That frustrating construction of the new M5/N1 interchange in Cape Town!!  When you’re sitting in traffic, you can’t do anything but look and think.  And I’ve seen this scaffolding get taller and taller and wider and wider and longer and longer and more and more people appear on it each day.

I know that one day, they will remove the scaffolding and the concrete will just hang there in mid air on those massive pillars and walls that they’re busy building, and I won’t be sitting in traffic any longer, and it will all just work.

What a shame that software is not like that !!  So many people get turned on by scaffolding.  And The Beatles sang on …

And when I touch you i feel happy, inside
It's such a feeling
That my love
I can't hide
I can't hide
I can't hide

And just like the M5 construction, so much scaffolding gets built, and so many people climb on.  But then, they don’t climb down.  And they don’t tear down the scaffolding.  And it just stays there mashed in with the concrete bits.  And then they ask people to use it.  And it takes strain and then it’s a performance problem, or a load problem, or it just crashes down.

I do use scaffolding, but most of the time it’s in a spike and more often it’s in a test, just to get me over my point of fear.  Deploying software with scaffolding is just dangerous and negligent.  I really don’t want to drive my car over the M5 interchange while those thin steel pipes are holding up the concrete slabs.

But above all of that, the most important scaffolding is social scaffolding.  It’s better to provide human scaffolding to support each other on a team that is focused on delivering quality software.  It’s worse to plug in weak struts in the code base that will just collapse when the next developer builds on top of it.  Very un-ubuntu!

So, the Beatles song still holds true, but only for social scaffolding.

Yeah you, got that something
I think you'll understand
When I say that something
I wanna hold your hand
I wanna hold your hand
I wanna hold your hand
I wanna hold your ha-a-a-a-a-a-and

Two Angles to Sustainable Pace

At the Scrum User Group South Africa meeting last night Marius de Beer did a really good talk about Software Development Practices.  It’s been a long while since I saw anyone attempt to draw so much from such widely spread corners of wisdom.  In one slide Marius mentioned the practice of Sustainable Pace.  Many take the view that this is about cutting back on working overtime and that it supports the principles of energised work, and work-life balance.  Marius did make the same point, and it is correct.
But there is another angle to Sustainable Pace.  As a developer, you need to build a rhythm, or flow.  It’s a cadence that you establish as you are writing code.  It’s a cadence that TDD helps you establish itself.  This cadence is also sustainable pace.  And one thing that kills this cadence and your pace in a flash is a mid-stream meeting.

In the panel discussion afterwards, there was a question at the end regarding ways to reduce the number of meetings which I just glossed over.  If you schedule meetings with developers for only the first hour in the morning, you not only reduce the number of meetings but, also, you don’t destroy the sustainable pace built up from the morning.

So, don’t think about pace as just working 7 hours a day, it’s about what you do in the 7 hours that matters.  Get the rhythm going and be anal about things that can kill your flow mid-stream; especially meetings.