I recently read Atul Gawande's
Agile software development methods often have very few explicit processes. However, these processes are essential and require discipline to execute well. We're often tempted to skip steps, either because we think that the step doesn't apply in a particular situation or we forget to do it.
The former is reasonable when we really understand why the step isn't relevant, but we are often tempted to convince ourselves that a step is unnecessary before we've mastered the basic process. One common example is the Scrum Team that is tempted to skip one or more of the standard planning or review activities. And forgetting is just something that happens when we're busy and moving quickly.
It's when we skip steps that processes break down. Think about the time's you've had a hard time tracking down a problem. How often was this problem in code that you wrote a unit test for? While it's often tempting to say that a change is "too trivial" to break something, how likely would you make that same decision if you had to go through a process (either on paper or enforced by tools) that asks "did you write a unit test?" to which you had to explicitly say "no?"
As another example, consider the various meetings that are part of your agile process such as your daily scrum. Jean Tabaka's book Collaboration Explained: Facilitation Skills for Software Project Leaders
Discipline is essential to an effective agile software development process. But discipline, Gawande points out, is hard:
Discipline is hard—harder than trustworthiness and skill and perhaps even than selflessness. We are by nature flawed and inconstant creatures. We can’t even keep from snacking between meals. We are not built for discipline. We are built for novelty and excitement, not for careful attention to detail. Discipline is something we have to work at.
So, if checklists enforce discipline, do they do so at the expense of judgement and creativity? Gawande says no:
...the question of when to follow one’s judgment and when to follow protocol is central to doing the job well—or to doing anything else that is hard. You want people to make sure to get the stupid stuff right. Yet you also want to leave room for craft and judgment and the ability to respond to unexpected difficulties that arise along the way. The value of checklists for simple problems seems self-evident.
Using example from aviation, structural engineering, and medicine, Gawande demonstrates that well made checklists allow you to focus on the activities that require creativity, by providing a way to get the basics right.
The checklist gets the dumb stuff out of the way, the routines your brain shouldn’t have to occupy itself with
As much as I find checklists useful, if used the wrong way, they can do bad things to productivity and creativity. As Gawande says:
Bad checklists are vague and imprecise. They are too long; they are hard to use; they are impractical. ... They treat the people using the tools as dumb and try to spell out every single step. They turn people’s brains off rather than turn them on. ...Good checklists, on the other hand, are precise. ... They do not try to spell out everything... Good checklists are, above all, practical.
Perhaps a surgeon, using examples from aviation, medicine, and structural engineering can teach agile developers something valuable. The main lesson that appealed to me as someone who values (lightweight) process is process can enable you to be more effective and move quickly by liberating you from thinking about the well known issues, and allowing you to focus on the hard problems.
If your team is struggling with process and not getting enough done, think about whether there are some simple things you are forgetting, and write them down. And, most importantly, iterate on the checklists.
