Measuring Code Quality

Code quality is vital for true continuous delivery in an agile environment.  Teams need to be sure that their code quality is at a standard that will not break the build in order to allow fast progression to live.  Teams also need to ensure they have a good quality continuous integration / continuous delivery pipeline.

In order to assess code quality across the business you will need to set a baseline.  From that baseline outline steps to show both the improvement of the team and of the business as a whole.

I used the grid below to work with my clients key service teams to create a code quality maturity baseline.

Code Quality Metrics

The example baseline table below gives clear indications of where effort was required for improvement  1.  In each of the teams (Viewing vertically) and 2.  where to focus effort across the business as a whole (Viewing horizontally).

Maturity Grid

Initially teams may be resistant, they may not want to discuss ‘code quality’ and have their service reviewed.  Work with Senior Team members to make it clear that the purpose of the review is not for reprisal, but to see where the business is currently and how the collective could improve and deliver benefit to the customer.  Combine this with a demonstration of the benefits of TDD (Test Driven Development), good Unit Test Coverage and the use of tools like stylecop and sonarqube through a working scrum team delivering shippable software on a two weekly sprint cycle to change attitudes.

In my experience, teams will began to look to the demonstration scrum team for ‘what good looks like’, joining the scrum ceremonies especially the retrospectives.

For my client, shippable code quality improved with the teams taking part in the programme.   Commits did not progress if they broke the build and acceptable test coverage was set at 80%.


Dealing with the Change Curve

ChangeCurveWhen you implement a new technology platform some people will be on board and excited at the prospect of a new and usable product, other will be worried that their knowledge and skills will become redundant and the new product will cause problems, slow things down and make their life more difficult.

It is normal to find more of the latter than the former in any business. So how do you deal with the problems caused by the change curve?

It is important first to understand the reasons people are resistant to change:

  • The change will reduce my power base!
  • I will not let the center tell  me how to run my business!
  • What does this mean for me/my career path?
  • How will this affect my ability to influence?
  • Who will win from this?
  • I do not believe the change will actually improve performance!
  • How will this work?
  • I can not see how the savings will be made!
  • Is this “doable”?
  • How does this affect the people/things I care about?
  • Will we still be true to our values?
  • I’m not supporting anything developed by them which I haven’t contributed to!

How do you combat these?

Talk to your stakeholders find out who is most likely to be a naysayer and get them involved early. Rumors and bad opinions spread fast so getting those that are most likely to complain to feed into the project early is good.

Find out what peoples worries are, perhaps using a social platform like Yammer and give good quality reasons to dispel them.

Once you have the worries set up discussion groups with other more engaged end users on your social platform, bringing the two groups together in open discussion can be useful to win over those who are no quite as engaged as others.

Open conversation is key to show those who are most concerned by the change the inherent benefits.  Remember you can’t please all of the people all of the time, but if you can please most of them you are more likely to succeed.