Abandon Your Process and Think

I've been in the software game for a long time, something like 25 years professionally. Through that time I've used a number of processes and techniques for planning, designing, and delivering software. I've even invented a few of my own. Every technique I've used has had its good parts and its bad parts, but when it comes to actually delivering Agile/Lean approaches seem to work best. That said, there are still issues with these techniques. 

Consider that you are relying on your process to think for you. 

I don't want to disparage anyone or any process in this conversation, but in order to explain I'll need to talk about some specific practices that I've seen. One of my favorite whipping boys is the Definition of Ready. Time and time I again I see teams institute a Definition of Ready and then watched as the lights go out. The developers seem to stop thinking about the context of their work and become hyper focused on the card at hand once they have completed the Definition of Ready. Its as if the process has turned off a part of their brain. 

Defect triage is another process that seems to turn peoples brains off. An issue that is trivial to fix, say a log file size configuration becomes a full defect on a card wall that is timed, measured, and reviewed when the actual work to correct the problem might take two or three minutes to resolve. The process has taken over completely in this case. 

I remember the old days (2004) when we just got things done. Most of the cards we had in our team room had a few words on them and we just had a quick discussion about what needed to get done, then we did it. There was no Definition of Ready and the Definition of Done was one line line, 'Does the Product Owner approve?'. When we found issues or problems we just fixed them. If someone outside the team found an issue we created a card, took our lumps for having a defect, and then we just fixed it. Things moved pretty fast back then. 

I think we were so effective because we were always thinking. The process was seen as a constraint and therefore kept very intentionally light. Good intent and attentiveness was all we needed to develop good software. What I see today is too much process, to much adherence to process, and a blindness of process obsessed coding zombies.

The irony is that many of the people I see behaving this way are asking for more autonomy. Their response to having that autonomy is more process that they then blindly follow. I'm not sure if the processes they create are a expression of their commitment to the autonomy; as if process is what was asked for, or If process is a comforting respite from thinking. I cynically presume the later. 

Ultimately I believe that having clarity about the objectives of our work is what matters most. The processes that we use should remain ephemeral and be adapted rapidly to the conditions of the work that we endeavor to complete. If a process is not working, don't try to force it, throw it away and think about the problem without the constraints. If it turns out that a process is the right answer to a problem, then apply the process to that problem and move on, but don't assume that the process is universally applicable, and by all means, don't force the process onto everyone and everything.