Development teams typically encounter the situation where a systemic problem gets in the way of their immediate work. The question is then: should we work around the systemic problem or take extra time to fix it properly, for us and for everyone else?

I was involved in one such conversation today. A change in the development pipeline left one team with a repetitive task of compilation and copying. No tools were available to automate this, so they had the choice of writing a quick script to handle their current project, or writing a more general tool. The quick script was tempting but, as one of the Scrum masters pointed out, this was likely to be a problem for other teams sooner or later, and if everyone chose to make their own quick fixes things would be slower in the long term. (See also the story of stone soup.)

In our technical world this is a problem of value. Specifically it is about balancing product value with long term value. If a development team is focused on delivering product value, driven by a product manager or similar, then other kinds of value will not be realised.

This can also been seen through the lens of systems thinking. If teams are all siloed then the system as a whole (the department or organisation) will never be optimised, and will no doubt eventually grind to a near-halt.

One solution to this problem is to have a team dedicated to optimising this. A devops team with a fairly free hand is a good example, and they are likely to be focused on optimising the pipeline from coding to release. I’ve also worked with a “platform team” that had a wider remit, and as a result introduced a new kind of application infrastructure, focused on a specific class of application, that allowed their sister teams to deliver significantly faster.

Another solution is to ensure all teams know they have time to optimise the wider system. This might be built into their processes, for example with a “gold card” that allows free development. Or it could be tackled less through process and more through culture—that is, ensuring they have a genuine sense of ownership and the authority to optimise the system as a whole. This is trickier to introduce and manage, but more worthwhile overall.

I’ve previously discussed potential clashes between the role of Scrum master and line manager, and this is one situation where a distinct line manager can help: they can be a more persistent and reliable voice for “doing it right” against “doing it now”. But that’s not the only way. As I mentioned in the introductory example, in that case it was a Scrum master who was encouraging the team to take the extra time.