Attention… Is Anyone Responsible for Your Codebase Quality?

In a pull system the workers pull in new work when they have capacity. They know what is on their plate and they manage and organise to cope. They make judgment calls when business priorities compete with engineering risks. Of course engineering risks are business issues on some level; but they tend to have longer term impact.

In a push system workers have less or no control over what they are asked to deliver. They may be doing their best and working hard but they are not taking responsibility for their work schedule. Whoever pushes them work is.

An agile team should be in a pull system but I’ve seen a lot that aren’t.

If you operate a push system ask yourself the following questions. Do the group allocating work and resources understand the current state of code assets? Do they appreciate the prevailing engineering risks and issues? All of them. Can they understand the cost of mitigating actions? Are they equipped to make judgment calls to prioritise those actions? Are they even measured against long term software stability and running costs?

In a push system engineering risks and issues need reporting by the team. Someone outside the team decides when to take action. It is possible that no one is adequately accountable for the long term codebase quality. Inside the team influence is lacking, outside the team knowledge and possibly motivation are. Don’t be surprised when things start to creek over time.

The fix is easy, just switch to a pull system and let the team know that code quality is their responsibility. If work has been pushed at the team over a long period there will be catching up to do. Technical debit needs paying off. A permission seeking culture may need breaking. Addressing both of these takes time.