I had a good discussion with a chap called Marios whom I met at one of the many great pro-Agile evening events in Leeds. He was there with an interest in improving things at his job as a mechanical engineer and wasn’t really aware of the state of affairs in the software world, so I expect he was a bit overwhelmed with jargon by the end.

Marios was frustrated with the waste and inefficiency that he could see in his company, and being young and idealistic was trying to work out ways to fix everything.

fix all the things

My advice, being young and cynical, was that this sort of thing tends not to succeed. A bit more helpfully, we explored some of the problems he was talking about and they seemed like the sorts of things that you could put into pictures: things like a Kanban board or a burnup chart that’d highlight where the obvious (to him) bottlenecks were. Moreover, it seemed like it might be possible to visualise them in near real-time without too much more effort.

We thought a bit more about what the consequences of this would be, and came to the conclusion that this might be enough. Once he was showing some pictures that highlighted the problems they were facing, it’d be a lot easier to get his colleagues on board with fixing these problems. In fact, it was entirely possible that visualising the problems would have been enough for them to be resolved naturally.

We came up with the phrase

Visualise, don’t optimise

to describe the idea that rather than fixing problems yourself it’s often good enough to believe that the problems are there simply because people can’t see them, and once they can see them they’re conscientious enough to fix them themselves.