In case of struggling with care for code quality (most likely with lack of time to do this) then high time to ask two below questions comes

  • Who is responsible for quality of code
  • Who decides how or when the team can find time for quality

Assuming the answer to the first question is obvious as code is written by programmes – so they should be responsible for it, the answer to the second question does not look so nice… At least based on what can be noticed in lots of companies.

The answers leads to 2 paradoxes

  • How can a programmer / team be responsible for quality of code (question 1) without  right to make decisions in this area (question 2) like spending time together in team refactoring meetings, code reviews or pair programming.
  • How a manager or business person can make decisions regarding scope of tasks together with time to fulfill them (question 2) without dealing with consequences of it (question 1)? This is because they won’t deal directly with Issues coming out of low code quality like increased number of defects or inability to extend / maintain the system.

Let’s assume we come to car mechanic with a request to replace brakes with new ones. After being informed it will take 1.5 hours we do enforce it must be 30 minutes. Even in unlikely case if it was done within 30 minutes (based on customer’s demand) would you like to drive such a car?

The solution to both issues is establishing autonomy of teams that is based on setting up boundaries of responsibilities. This entails giving right to make decisions within your own area of responsibility, and right to take part of discussions / decisions that pertain to your area of responsibility. This requires trust in both directions and clear communication of goals we want to achieve together rather that delegating things to be finished on given date.

I do really encourage you to ready a short book by Ken Blanchard “The 3 keys to empowerment”. One of these 3 rules says :

Create autonomy (of teams) by setting up the boundaries (of responsibilities)

Although this book is not about IT industry it pertains to each branch of business.

Spread the word. Share this post!