I often get questions about how to approach refactoring at the cultural level, i.e. how to promote it in the organisation. This post is an adaptation of some advises I gave to a customer of mine…
The best way is to have refactoring done as part of the story development, so during the sprint. It’s just there. It’s a way to keep technical debt low and it’s everybody’s job to do it. There is no reason to make a big fuzz around it as each refactoring cycle lasts a few seconds to minutes.
Of course reality is different and more often than not the team does not have the care for good quality software they should have.
I would distinguish between two cases:
1) The team does not understand that the software has a lot of technical debt – and this includes also the case of not wanting to understand… 🙂
In this case some metrics may help: by measuring the complexity in the code it’s possible to show how complicated the code is and how difficult to change it becomes over time. Another option is to discuss with the team very concretely what to do to speed up the development.
It is a ScrumMaster’s job to raise awareness in the team about these topics. Some strategies:
- Work on a story trying something new to keep the technical debt low. For example have a code review with somebody, do some pair programming, use some metric tool. Here the ScrumMaster is a role model, breaking the pattern “it’s easy for you to say to do that and not to do it yourself”
- Subtly but constantly raising awareness. Promote good quality code as much as you can (but… avoid to be thrown out of the team because you’re getting on their nerves! 🙂 )
- Use some time during the sprint to discuss these topics. The retrospective is the natural place. Important is to have the team committing on some clear improvement goals and confront them with the goals at the end of the next sprint. No clear commitment usually means it won’t be done!
- For these strategies there might be people in the team who are more sensitive to these topics than others: get them on your side and start doing something with them
2) The team understands the issues, but is unwilling to take actions
In this case the problems could lay in individual blocks or they could be systemic around the team, and it will be your job to understand them.
Examples of individual and team issues:
- Fear of not being able to do the job properly
- Fear of being put under even more pressure
- A latent conflict inside the team that prevents implementing more collaborative practices
- Misalignment with the organisational goals
- Generic de-motivation and de-engagement – though usually the cause for this is systemic.
Examples of systemic issues:
- Project pressure (it’s probably problem #1)
- Blaming organisation
- Organisational goals not properly communicated
- Organisation is forcing local optimisations on the team (metrics, pressure, …)
- Non-supportive organisation (why should I do X if they don’t care about it…)
Once you have diagnosed what this could be, try changing something you believe it might help and check whether the results are what you expect.If not, try with some other ones – it’s anyway a complex adaptive system you’re dealing with!
The important thing is… patience. Though it might seem just a matter of engineering practices, refactoring is also a very deep cultural change and as such will take a while to develop.