More haste, less speed
Once upon a time, I joined a project that was in a real mess. The project was supposed to deliver 3 similar but slightly different systems, and were way behind schedule. The team didn’t really understand version control, and there was a lot of copy and paste between 3 separate repositories, with things getting lost along the way. In addition, the “enterprise” technology being used meant that the deployment mechanism was manual upload of files using a WebDAV GUI, so nobody really knew what code existed on which servers.
A while after I stepped into the midst of this mess, the project lead sent a message, which really stuck with me: “Guys — we need to rush !!! We have only 3 more days on this sprint to close all these tickets! I am going to escalate this”.
It really got my hackles up, and not just because I think that the over-use of exclamation marks is the sign of an untidy mind. I wasn’t really sure who he planned to escalate it to, or what he thought he might gain from that. Perhaps he imagined that we might find some extra team members from somewhere, and that they would disprove Brooks’s law. Perhaps he was just trying to show the team who was boss. It didn’t seem very productive. Besides, dealing with all the politics and overheads of an ‘escalation’ would have put the project even further behind schedule.
For a long time, I’ve been convinced that it takes much longer to fix the mistakes that were caused by rushing than it does to do slow down and do the job properly. The trouble is that sometimes it takes longer to explain that to a project manager, especially if they’re inexperienced, or if they’re getting grief from clients about delivery dates.
It’s the kind of thing that got me thinking about anti-patterns in team leadership. This sort of mentality leads to endless crisis meetings, so that developers spend longer talking about why the project has problems and defending their own competence than they do working on the problems that the project is there to solve. Besides, most developers are better at solving problems than they are at talking.
The first thing I wanted to do after joining that project was sort out a proper branching strategy and code review process, to be followed shortly after by nightly builds that would make sure that the the code on the test environment matched what was in version control.
There was significant resistance to these ideas. “We don’t have time for that sort of thing”, said the other developers. “We’ve got to get these tickets out”. Their attitude reminded me of the images accompanying the excellent points made by Håkan Forss about the value of investing in improving your process. An inexperienced team were trying to churn stuff out as quickly as possible. Of course, the number of tickets that failed testing was enormous. Eventually I managed to persuade the team of the benefits of code review, but I figured that trying to get them to test automation would have been a step too far.
I’ve previously written about my own opinion on the value of code review, and as my colleague Tom Phethean put it, “effective code review is directly linked to quality of the code which reaches production, so don’t give in to time or management pressures and skip reviews”.
Most managers won’t want to hear this, but very often when there is a problem, the thing that developers should do is slow down. Rather than jumping straight into writing code and finding solutions for problems, spend some time thinking about the problems themselves. Why do those problems exist? What are the underlying causes? Are they just symptoms of some deeper problem? Are they worth solving? Developers love trying to solve problems, but sometimes they need someone to stop them trying to fix everything.
As well as code review, another important point where developers should slow down is in testing their work on their own machines before getting it into test environments. There seems to be a view among some developers that testers’ time is less valuable than their own. Perhaps from a short-sighted, purely financial perspective, there may be some truth in that. But it’s an enormously disrespectful way to treat your colleagues, and a very inefficient way of working, that is likely to increase the overall elapsed time of the project. If developers don’t test their work properly before passing it on to QA, the project will suffer, not least because of the inefficiency of context switching when the developer needs to go back and fix a bug, having moved on to another feature. As Jez Humble explains, there are real gains to be made by making feedback loops faster.
Those faster feedback loops are only possible if you slow down and take the time to set things up properly. If you’re always rushing to get features out the door, you’ll never be able to make the efficiency savings and quality gains from getting your process right.
This really chimes with my experience of working in events. The deadlines are tight, and the hours are anti-social. In some areas, you might need to say that something is “close enough for rock and roll”, but quality is enormously important where it really matters — sometimes it can even be a matter of life and death. This might be how you rig a truss, or it can be as simple as never running on the job — that’s how people slip and hurt themselves. There’s always time to do things properly, no matter how much of a rush you think you’re in. Cutting corners is likely to hurt you in the long run.
As Kimber Lockhart puts it, “Crafting a sense of purpose is different than creating urgency.” If your team feels pressurised to churn out work quickly, it isn’t likely to be high quality.
Originally published at Red Route on February 21, 2017.