Many teams wish they had more time for four activities:
1. Rewriting code
2. Refactoring code
3. Training and improving skills
4. Experimentation with tech and techniques
The problem is, these events don’t look like adding features, which is what bosses and clients want.
Everyone is doing it.
All software teams do these things, but many “sneak them in” while building features. They hide these activities from others, out of shame, fear of getting in trouble, or because it could send the signal that the team wasn’t as perfect as the boss thinks.
Sneaking things in takes a variety of forms. Do these sound familiar?
1. Allowing developers to try out a new technology on a non-critical project?
2. Adding additional time to a feature estimate to rewrite/refactor some code?
3. Padding feature estimates so you can perform some bug fixes?
4. Paying off technical debt while doing system enhancements?
What impression does all this sneaking around give others?
Could hiding these activities give outsiders the impression that software is something to do perfectly the first time, like a well-rehearsed piano recital?
Could it give your boss the idea your team doesn’t have technical debt or quality problems?
Could you be sending the signal that your team doesn’t need time for training or experimentation?
Could you be reinforcing to the developers that some part of their work is shameful?Could you be teaching developers to sneak things past you?
If you are sneaking in these activities, I think you are giving others the wrong impression of software development. These are first-order software development activities, not examples of wasted time and money. The goal is not to rid the team of these, but to manage and prioritize them alongside the features. That only happens if you talk openly and honestly about what your team does.
Now it’s your turn.
How many other problems could you imagine this would cause?
How can you begin to discuss these items more openly with others?