While i expect this to be rare and unfamiliar to most of my readers, in some organizations there are managers that sometimes complain about teams, specifically about their productivity and quality. As an external, i often do not have the knowledge to really form an opinion about this, and as a developer i have my gut feeling and instinct, and to be honest, sometimes when i look at what the team is able to produce in a single iteration i think that: Indeed this seems like not a lot of functionality for 7 people to achieve in 2 weeks.

While this is all good and nice, this is not a good enough tool to analyze the dynamics that lead to the problem in productivity.

As we shall soon see, part of the reasons for not being able to deliver more is in-fact, not being able to deliver more.. Let’s look at a this (over-simplified) causal-loop diagram:

When creating the diagram i started with productivity, and went on to examine what would impact productivity and what does productivity impacts. Notice that a causal loop diagram is not meant to express an opinion but simply to examine in an objective (in this case me personal subjective objective) way the dynamics of a system. 
Some of the cause & effect paths are simplified and in a real example i would expand and elaborate on the connections. 

Dynamic #1 – The learning & improvement loop.

More productivity will increase functionality, which will increase ROI, which may provide more opportunities for investments. More investment sometimes mean more learning which in the long run will have a positive effect on productivity. Voila! Positive feedback loop… but a long term one.
This dynamic illustrates what many of us think and know: Companies with good productivity have a good opportunity for improving this productivity. How? By amplifying this dynamic.

Experiment example: Invest X percent of each increase in ROI in learning activities. 

Dynamic #2 – The pitfall

More productivity means more functionality which will have a positive impact on the # of defects (positive impact means more..), the number of defect have a negative impact on quality. reducing quality will reduce productivity. Oops. More productivity mean less productivity?
Yes. Given the assumption that more functionality will increase the number of defects, so an option to dampen this dynamic is to change the impact that “more functionality” has on “number of defects”.

Experiment example: Start using a zero bug policy.

Dynamic #3 – Technical debt is in the house

More productivity will reduce the amount of pressure to deliver, and since there is an amplifying relationship between pressure and “corner cutting”, more productivity means that there is less corner cutting that results in higher quality, which leads to higher productivity. We have another winner!
Another positive feedback loop that we want to amplify. We can ask ourselves, where does this loop normally breaks? The “pressure thingy” would make a reasonable guess… 

Experiment example: Whenever we are behind schedule, we will work on production code only in pairs to avoid corner cutting.

Note, this article is over-simplified, but demonstrates the power of systems thinking, and the power of causal loop diagrams. 

Image by Azmi Talib on pixabay