As you probably guessed the title of this post is ironic.
I want to spend few words to show the logic behind a certain kind of behavior and its consequences.
The behavior I’m referring to as: Challenge Driven Development is one that many of us are tempted to use when facing projects or tasks for which we are accountable while depending on others for the execution.
This is the case sometimes for Project Managers or Line Managers working with software development teams.
Basically I’m referring to the dynamics for which the manager perceive progress being to slow and believes that putting some pressure upon the development team will eventually gain more speed and productivity.
I tried to sketch a causal loop diagram to illustrate this belief and I stumbled upon a reinforcing loop, as shown below.
Reductio ad absurdum
Following the kind of reasoning called: reductio ad absurdum let’s make the hypothesis that the belief that pressure upon the team causes things to go faster and observe the causal loop diagram.
The logical consequence appears to be that following the self-reinforcing loop with should be able to obtain indefinitely increasing productivity simply by applying constant challenge and pressure to the team.
This does not appear to be the case to me or at least not in this simplistic way.
What’s behind the quick task execution
Inspired by the much more analytical and sound reasoning about mental models illustrated by Craig Larman on Less website I tried to expand the links in the previous causal loop.
The little circle close to an arrow represent an opposite relationship.
Here I want to represent that the most common way of speed up a task is to lower the quality of the work.
This causes an apparent increase in velocity, actually explained by the less things done. Eventually, on the medium to long term, this low quality work will impact all subsequent tasks.
This is represented by the external circle. Both the loops reinforce the need to put more pressure if the initial attitude was such.
But we do not end up having a constant increase in performance since the negative impact on the time needed to complete a task is always growing causing some sort of balancing effect on velocity if not pejorative.
What Quality is in software development
To cut a long story short when we decrease quality we leave behind us a messy piece of code if we are lucky, many bugs if we are not.
As I was mentioning in a previous post, it is unlikely that the decision to rewrite a messy piece of code is an unquestioned choice. The opposite is true, usually.
In fact it is perfectly reasonable that the persons involved are willing to evaluate pros and cons to take an informed decision.
But when Challenge Driven Development is in the air this calm reasoning is difficult to achieve.
Desperately Seeking Courage
In fact when you rewrite an unknown piece of code is really likely that you will break things in unpredictable ways. Among the strategies you can adopt to reduce the probability and the impact are: iterative development, being competent in the field of software development, using xp practices like TDD and pair programming and others.
Developers using such approach usually can succeed in rewriting a piece of code and if they fail they will be quick to recover.
But psychological safety is really important when such decisions need to be taken.
When a task is risky and tough it is true, as I said before, that the persons involved need the level of mastery adequate to the challenge, need the analytical skills to assess the risks and to figure out the impacts.
But most of all they need to be able to act with a little bit of courage.
If as a manager you don’t praise courage you will get quite often a reaction driven by amigdala: the fly option in the Fight of Flight response. No-one will dare to take a risky decision.
Is Trust a Value or a conscious act?
There are several common behaviors whose outcome is to challenge acts of courage:
- ask the developer a guarantee in the form of a cost-benefit analysis,
- ask her/him to estimate how sure she is about the outcome
- tell her that you will hold her responsible
- remind to the team the stake at hand and the risk they want to take and after these words leave the decision to them
All of these translate, in the minds of the team members in one of the following:
- Fear to fail and be blamed in case anything will go wrong…and it will;
- Rationalization of the facts to justify the decision not to act
The opposite is true if you abandon your challenge driven environment and build a safer one:
If you feel safe, trusted and supported, if you are competent, if the environment (in terms of tools and processes) is mature enough to make it easy to fail and to recover from your failures, then you will quickly fix what you broke and with almost no harm.
If any of the above is missing, the process will not work and you will fail catastrophically.
In my opinion all the things I cited above are under the responsibility of an organization’s management:
Safety, Trust, Support to people, Competence Growing, Functional and Efficient Environment are prerequisites for the good working of every organization.
When software development is part of the business (always?) these prerequisites become even more critical.