Get in the car!

Having kids can provide great examples of pathological team behavior. It's not that your team behaves like children. On the contrary, the reasonable explanations and subtle arguments deployed by adults can serve to obfuscate fundamental issues. But having kids helps to emphasize that all human beings exhibit the same basic traits. Kids just tend to exhibit these behaviors in such an obvious way that they can shed light on team and work dynamics. In particular, one recurring scene in our household has made me think more critically about what it means to be "done."

I am usually the one to drive the kids to school. I have two kids that go to two different campuses of the same school. One is in first grade the other is in second. If I can get both kids to the North campus by 7:50 AM, the South campus kid can hop on a shuttle and make it the rest of the way herself. Then I can go straight to work. If I'm late, we miss the bus and I have to drive a few miles to south campus and drop off the South campus kid myself. Missing the bus gets me to work almost a half hour later than I otherwise would have. You might say I'm motivated to get to get the kids ready on time.

I've learned that it's not enough to ask the kids if they are ready or to list off the things they need to get done before they can get in the car. The only thing that really matters is if they are in the car or not. Often the biggest delays happen between the time they believe they are ready to go and when they actually buckle up their seat belts. They have to go to the bathroom, get a stuffed animal, brush their teeth, or any number of last minute items. What's worse is that because they think they are done they tend to play around, argue, and generally make noise as I'm trying to make sure I have everything I need. I can't concentrate and deep in my heart I know that the kids aren't really ready if they aren't in the car.

That means in the morning you'll often hear me tell the kids to get in the car with a fair degree of urgency. Getting them in the car focuses their minds on all the little things they need and also gives me thirty seconds of quiet to help me make sure I haven't forgotten anything.

You know where this is going. It's not enough to say you are done. You have to report that you are done, something must be delivered, and there has to be some objective measure or someone acting as a gatekeeper. The bar doesn't have to be high, but it has to be higher than the developer's say so. How often have you heard "It's done, there are just a couple of bugs." or "It's done, but I have to check-in and run some final tests."

That just isn't good enough. In order to run a project successfully you need to identify simple, objective criteria for when every task is done. It's also not good enough to have milestone criteria. If you don't know how much of your work is done on at least a week by week basis if not a day by day basis, human nature will kick in and things will pile up.

And I do mean simple. It doesn't have to be end to end scenario tests, although it is always nice if a task can light up actual functionality. For example, here is one possible approach:

• Developers must write accompanying unit test for every task.
• Tester code reviews unit test to verify that it does what it should do.
• Developer runs unit test in presence of tester and sees that it passes. If you are using Smiley Project Management, the tester can place a star sticker by the task.