I recently read The Checklist Manifesto by Atul Gawande. The centerpiece of it was the case study of a checklist to prevent post-surgical issues. It was just some simple questions to be asked (1) before anesthesia, (2) before the first incision, and (3) before the patient leaves the operating room. Really simple things like what procedure is to be performed and the name of the patient.
You would think that since surgeons are highly trained specialists and everyone is highly motivated to save patients, that this simple list wouldn’t help much. But it prevented a third of post-surgical complications. Everyone knew you should do these things, but they were being overlooked or abbreviated. Putting steps in writing also empowered the nurses who had previously felt intimidated to speak up when they saw something go wrong, since they had a standard to hold the surgeons to.
By now you are thinking “that is interesting and all, but what does it have to do with software development?” Well, it made me think of an agile team agreement. The agile team agreement is a written plan for the team to do the work it has ahead of it and what is expected of team members, i.e., a checklist. A user story is supposed to meet certain criteria before being considered, then to be done with it you need to meet other criteria. Agreements help keep you from skipping out on the steps needed to build in quality that you know you should be doing but sometimes skip for simplicity or expediency. They also makes it ok for the rest of the team to call out someone who wasn’t meeting the standards you all agreed upon at the outset. The places I’ve worked that used team agreements felt like they worked better than those that didn’t.
That’s a gut feeling, and unfortunately, we don’t have hard quantitative measures for software quality to match the medical example. Qualitatively, I felt like we accomplished more with less, and built better software. We definitely had a better time doing it which was just as important.