Who am I?

I’m an Agilist, a former software engineer, a gamer, an improviser, a podcaster emeritus, and a wine lover. Learn more.

Currently Consuming
  • The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
    The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
    by Eric Ries
  • The Talent Code: Greatness Isn't Born. It's Grown. Here's How.
    The Talent Code: Greatness Isn't Born. It's Grown. Here's How.
    by Daniel Coyle
  • Alexander Hamilton
    Alexander Hamilton
    by Ron Chernow

Paul Tevis

Entries in books (38)

Friday
Mar192010

A Pair Of Recent Reads

For some reason I decided that I can't remove a book from the Currently Consuming section until I talk about it. Here's two that need off the list.

Mastering Virtual Teams: I'm working on three projects right now where we don't have everyone in the same place (two at the day job plus the Origins Awards), so I was hoping for some good answers from this book. What I got was two general principles with some specific advice. The principles are these:

  • Different tasks have different needs when it comes to collaboration and communication technology. Choose technology appropriate to your tasks.
  • Be aware of how different cultural backgrounds (be they national, organizational, or functional) will affect aspects of you team dynamics.

This is good stuff, but I did find myself hoping the book spend more time showing how these ideas apply to particular situations than it did. It also suffered from some organization problems. The big one was that in the section on tech, it showed for each technology what its strengths and weakness are. That's fine, but if I'm choosing a technology based on the task I have hand (as the book recommends I do), I need the lookup table to go the other way. If I know we need to brainstorm, I want the book to tell me what my best choice for that task is; I don't want to have to look at each choice in turn and see how it compares in the brainstorming category.

Overall: Worth reading if you're completely new to the topic (e.g. you haven't seen Geert Hofstede's framwork for assessing culture before), but probably not the Single Most Indespendible Book On The Topic.

 

The Thin Man: I picked this up from Borders last weekend because it (and The Big Sleep) jumped off an endcap at me. (I mean this metaphorically, not that I'm notably clumsy.) I'd never actually read any Dashiell Hammett, nor had I seen any of The Thin Man films. (This latter fact left me at considerable disadvantage during the drive from Chicago to GenCon last year, when Greg Stolze and Ken Hite were discussing at some length a hypothetical remake of the series.) I enjoyed it, though I found the nigh-constant use of dialogue vaguely disorienting.

Overall: It was nice quick read, so I'm tempted to go back and fill in with Hammett's other novels.

Wednesday
Mar172010

Amen To That

Lisa Crispin and Janet Gregory in Agile Testing:

"Successful projects are the result of good people allowed to do good work."

 

Sunday
Mar142010

For Rob: The Checklist Manifesto

My friend Rob suggested that I read The Checklist Manifesto. I did so. He then asked me questions about it, which I answer here:

What field were you looking to apply TCM to? Any examples of problems you hoped it would apply to?

I went into it with no real idea what it was about. All I had was your strong recommendation, based some of our conversations about (I believe) Made To Stick.

Do you think there's a meaningful difference between cockpit checklists and construction checklists?  Do you think this needed more exploration?

I'm undecided. Certainly what he found useful about them was different. In the case of construction checklists, he emphasized the communication component (the submittal schedule) rather than the "this is what you do" component (which is probably some variant on a Gantt chart). In the case of cockpit checklists, he emphasized the latter, which makes sense given the number of people involved.

One complaint I've heard is that it gives too little guidance on how to actually make a list.  Once that was called out I realized I was filling in gaps with my GTD knowledge, so I am not sure about this one way or another.  Your thoughts?

It certainly lives up to its "manifesto" claim in that regard: It presents a clear call for action, without really giving specific guidelines about how to it. That's not entirely true, as there's a few choice paragraphs in the "The Checklist Factory" chapter about what makes good and bad checklists. But there are too few concrete examples. Did you notice how the whole book is about the development of the WHO Safe Surgical Checklist, but the checklist itself is never included in the book? (If you're interested, it's here.) I certainly would have like to see examples of each of the types of checklists that he talks about it. He also talks about the need to test and refine new checklists; I would like to have seen before and after versions.

Do you think this idea has any real chance of penetrating the geek mindset?

I do think there are real challenges to adoption, as he identifies in "The Hero In The Age Of Checklists." As to whether those are overcome, your guess is as good as mine on that.

Now that you're done, how do you see yourself applying this?

Any book like this is like the cave in The Empire Strikes Back for me: What's in there is what I take with me. What I took with me was a lot of stuff about Scrum, since that's what I'm living in right now. There's a lot of resonance there: pushing authority out the people on the ground, insisting on regular communication to resolve problems, and following a checklist-like process to take care of the dumb stuff so that you can be smart. Plus, the inspect-and-adapt cycle of Scrum lends itself to the development of checklists. We'd already started to create checklists for the different types of stories we implement; I'm working on one now for estimation.

Beyond that, I see some potential for application in RPG design. As you pointed out, the end-of-session and end-of-year processes in Mouse Guard are basically checklists of this. They get you to stop and think about the right things, which ultimately is what the manifesto want you to do.

Does that answer your questions?

Page 1 ... 4 5 6 7 8