

Communication? Check - raganwald
http://braythwayt.com/2013/12/01/communication-check.html

======
raganwald
Another observation that got cut from the post: "Programmers love construction
checklists. We call them unit tests."

~~~
erso
I'm not sure I understand the point of the post.

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?

~~~
raganwald
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.

------
indirect
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.

1: [https://code.google.com/p/gerrit/](https://code.google.com/p/gerrit/)

~~~
raganwald
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.

------
bscofield
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.

