How Developer Contributions Affect Team Productivity - Cape Of Good Code

"Individual performance does not directly predict team performance. And if it’s not possible to deduct team performance from individual performance in a domain that’s as easy to measure as sports, then we can expect even less success in software engineering.”
        
Kent Beck and Gergely Orosz

“Developer contribution patterns DO influence team productivity and these can be identified and measured.” 

Egon Wuchner

Aiming at developer productivity AND team alignment

I have elaborated on the contradiction between team productivity versus team illusion in the first blog. This was in response to Kent Beck and Gergely Orosz's response to the McKinsey article on measuring developer productivity. They argued that developer productivity is hard to measure and stated that one should instead look at team productivity and derive metrics for that.

On the other hand, by referring to Jan Bosch's post on the team illusion, I pointed out that there is no such thing as a "team", as team members do compete with each other for positions in the official organizational hierarchy or the unofficial "reputation hierarchy".

As a conclusion, I draw the following:

1. on the one hand, to strengthen team alignment in order to mitigate the effects of team illusion and thus implicitly promote team productivity.
2. on the other hand, to give each developer the opportunity to get time alone to work productively on things alone and to complete them, and in doing so getting into the enjoyable flow of getting things done and also to receive recognition for good individual achievements to which they can refer.

This raises several questions:

1. How can we prove, make visible and incentivise the individual developer's contributions to team alignment (which would increase team productivity)?
2. How can we show the individual work of a developer for which he can claim sole "authorship" and be proud (which would increase individual flow and developer productivity)?
3. How can we achieve a good mix of both aspects and keep them in balance?

Well, the best kind of knowledge sharing and team building is bidirectional collaboration. So not three, or four or possibly more people "collaborating" on one thing, but EXACTLY two. Let's call these pairs "Knowledge Balances" (KB) or "Contributor Balances".

For this purpose, there are the following arrangements between two developers:

• Pair programming is the 100% ideal incarnation of such a collaboration. Unfortunately, in my experience, this is rarely practised.
• A common intersection of code on which exactly TWO developers work simultaneously over a certain period of time. This way they get to know each other's code, understand each other's way of thinking, practices/principles and they automatically exchange ideas. 
• Code review of the work of one developer by a second developer.

Complementary to this, let us call the individual work of a developer on separate code areas "Knowledge Islands" (KI) or "Contributor Islands". This would be a metric of the individual's sole, productive work worth acknowledging.

The aim now is to achieve a good mixture of the two knowledge islands and balances in the code. Of course, the islands must not be too large, otherwise there is a risk of knowledge loss. And the balances should not be too small, because otherwise there is no sufficient exchange between the developers.

The ideal picture could look like this:

• 50% developer effort in Knowledge Islands and 50% in Balances
• The code areas and developers behind the KIs and KBs should vary over time.

Now, the ideal picture is just an ideal picture and difficult to achieve. Therefore, we set somewhat softer requirements:

• a sliding KI-range between 40-60% would be a good guideline
• a realistic range of KB-values between 20-40% as a minimum

• a recognisable amount of KI/KB clusters over time

The following charts from our analysis using Cape of Good Code's DETANGLE®  tool show the KI and KB percentages of the Lines of Code (LOC) value of each source folder of the Django Web Framework over the years 2019-2022:

The x-axis shows the KI percentage and the y-axis the KB percentage of LOC per source folder. The files that were changed in the respective period for the development of new features or the processing of cleanup/optimisation tickets are counted. Maintenance work to fix bugs was explicitly excluded from this evaluation (we will come back to this in the next section).

The lower left quadrant shows the critical folders that have neither a good Knowledge Balance nor a good Knowledge Island share, i.e. folders that correspond neither to the KI nor the KB ideal. The upper left  quadrant shows the folders with a high Knowledge Island share but a small KB share. The lower right  quadrant generally represents the good case where the Knowledge Balance share is higher than 30% and the Knowledge Island part is not overwhelming.

In general, the closer the folder is to the intersection of the two values of 50% for KI and 30% for KB, the better the mixture of KI and KB shares.

Observations

It can be observed that the number of critical folders in the lower left quadrant decreases over the years and the amount of folders in the "good" lower right quadrant strongly predominates in the development of the Django Web Framework. 

It is also noticeable that more and more folders move in the direction of the diagonal from the value (KB=0%, KI=100%) in the upper left to (KB= 100%, KI= 0%) in the lower right. This means that on more and more folders only the work of single AND two-person teams of developers is being done, albeit in different mixing ratios. This development is very positive, as it makes it much easier to change this ratio even further in the direction of KI=50%, KB = 30%.

The general goals and derived measures could be the following:

1. Allow only very few folders in the lower left quadrant, because they are neither conducive to team alignment nor to developer productivity. The team must discuss how responsibilities can be clarified and which two-person teams will mainly work together on which of these folders in the near future.
   
   
2. Only a small part of the folders should be accepted in the lower right-hand square. Here, some of the individual developers behind them should agree to more bidirectional work with other team members.
   
   
3. The overall goal is to find the overwhelming majority of folders in the upper left quadrant over time. The measures suggested above to achieve these goals could be explored and incentivised.

So far so good. It looks like the balancing act of team alignment and developer productivity is being achieved generally quite well in the development of the Django Web Framework.

But until now we have not mentioned the shown bubble size of folders. It represents the respective maintenance effort (ME). And this may even be the most important aspect, which I will discuss in the last blog on the Positive Impact of Developer Contributions. I claim that it can also be used to measure the impact of a good or poor mixture of KI/KB shares. An impact that is also noticeable to the customer.

Links

[0] Photo by Andres Ayrton