I like the idea of submittal checklists, indeed this is a part of our business that maps very literally to what our users need to do: complete a list of tasks before submitting an electronic bill.
However, equating submittal checklists to something including stand ups seems weird to me. Would you really have a checklist saying "Did stand up meeting today." and if so, why?
The point of a checklist is to put knowledge of what needs to be done for a task in the world instead of keeping it in the head (I've borrowed this idea from The Design of Everyday Things). Checklists are for complicated things, like the aircraft checklist you mention, that require every step to be checked otherwise people may die.
I'm a fan of small checklists for software development that determine when a user story is completed. In Tracker there's tasks you can add to a story that can be used as acceptance criteria, for example.
But what good is a communication checklist? Is it really a desire to have a checklist that includes items such as "had standup meeting?" And if so, why?
You are describing a construction checklist. Things to be done, like run unit tests before deploying, implement feature 12345, or weld a brace plate over the bolted supports.
Construction checklists are objective and empirical.
Whereas a submittal checklist contains communication tasks. For example, "Obtain signoff on requirements changes." In a narrow sense, there's a measurable outcome: Did the customer sign? But the real purpose of such an activity is to avoid a major misunderstanding. It's about communication and synchronizing knowledge, not measuring the progress of the project towards "done-ness."
To that extent, a stand-up serves the same purpose. Not that you have a checklist saying "hold standup on Monday, December 2nd," but rather that they are different paths to the same objective.
If your checklist exists to codify things you know at the time you compose the checklist, it's a construction checklist. Unit tests are another way to accomplish the same thing.
But if the purpose of your checklist is to make sure that Alice talks to Bob about the idea that Carol wants to pitch to Dave, that's a submittal checklist.
If that still isn't making sense to you, read the book before dismissing the idea just because I'm not explaining it persuasively.
I feel like I'm kind of getting it but in quite an abstract sense. Do you have any thoughts around how this might look put into practise in software development?
I used to work at a shop that used Gerrit[1] to manage our master branch. Pushes directly to master were rejected, and all commits had to be signed off by a developer other than the author, confirming that a) the tests passed and b) the functionality had changed as advertised.
Motivation to review started low but got quite high once developers wanted their own code merged. Motivation to merge other things without checking started high, but got low extremely quickly once the merger had to fix the tests if they merged a failure.
I sometimes wonder if it's somehow possible to get either one of those (extremely positive) trends in a "modern" github-based workflow.
I work in an environment like this now, and it's fine, because we have a review culture. I don't think that technology can every impose a cultural shift by itself.
Gawande is one of my favorite non-fiction authors; I've learned a ton from his books and articles. I second (and would third and fourth if I could) the recommendation for The Checklist Manifesto here.
