Just Do It

Software Test and QA Testing

Update: After some amazing peer review from Michael Larsen, Ajay Balamurugadas, Tim Western, Jokin Aspiazu, and Jeron Rosink, both before and after publication, you can expect more to come next week. Consider this post the beginning!

I have never been a fan of "To-Do" lists, folders, or strategies to "get things done."

Instead, I focused on, you know, actually getting the thing done.

For years I felt mildly bad about this. Something was wrong with me; person after person would tell me how they were discovering a great personal productivity program, and how I was irresponsible for not doing the program myself.

Ten years later, I have a more balanced approach, but the to-do list is still not my first go to "tool." Here are a few reasons why.

Work Avoidance

One thing I know about to-do lists, is that when you make the to-do list, you aren't actually solving the problem. Moreover, writing the list gives you the sort of mental brain candy of success, much like getting the work completed would ... except that the work is not actually completed. Instead, the deliverable we've produced is a list.

I am not the first person to notice this; Merlin Mann, a productivity guru of sorts, has referenced the couch potato, who gets mad at a runner's magazine for not producing better "tips." Meanwhile, what the the couch potato really needs to do is to get out there and run.

How many times have you been in a meeting where someone takes an action item to follow up with Bob to see if he he has any concerns, compared to the number of times that someone offers to step out of the meeting, call Bob on the cell phone, and get an answer RIGHT NOW?

Which meetings went better? I'm guessing one with the cell phone, no?

Beyond Things

It's been nearly a year since I wrote "The Tyranny of Things" (and Part II) - none of this is too new, or too shocking, but I did want to add something else.

Many people don't like to act.

Consider, for example, the guy in the meeting who offers to follow up with Joe. That's easy to do.

For some reason, the actual follow-up is hard.

I am not sure why.

In a similar way, when you have status meetings, and someone says they are 90% done, 99%, 99.9% done, 99.99% done, week after week, that "one more thing" seems impossible to get done. It is always described as an easy thing, but there is always some excuse, some blockage why it can't get done.

As a project manager, when this happened to me, for some reason, following up in the middle of the week was a hard thing for me to do. Instead, I would hope that the issue would be resolved, it would not be, and in the meeting, we would be at 99.999% done - an extra nine this time - but the problem was still there.

I do not know why this is.

Interlude: Margaret Haddix

My daughter recently finished the "Among the ..." series by Margaret Haddix, and she is loaning me the books to read. They are juvinele fiction at it's best - quick, adventurous, and fun. In book four, I was struck by something: Nobody wants to do anything.

They all want someone to rescue them.

In the book, the hero isn't the one who is born to the right family or instilled with authority; those people tend to be peripheral to the story, they bumble around. No, the hero is the person who actually steps up to do something.

Which brings us back to the ToDo list.

Like any other technology, it's a tool, it can be used for good or evil.

In the examples above, I am talking about the use of the TODO list to avoid actually doing the work. (Sidebar: Isn't that exactly what a TODO means in code comments? "I could have actually fixed the bug, but I wrote a TODO instead?" / "Maybe somebody else will do it"?)

From Planning to Doing

In one meeting, a number of the team members were complaining how big a story was. "It should be a five!" said one person, another that it should be a three. Toward the end of the table, one developer kept insisting the story should be a one. Everyone ignored him, until he made a sweeping gesture. When the tech team came around, he said something in hushed tones, the team dispersed, and suddenly everyone agreed the feature was a one.

You guessed it: With his laptop open, the programmer implemented the feature while everyone else was arguing about it.

My friend Ron Jeffries has a similar rule -- never talk about design for more than fifteen minutes. Instead, once you get to that point, break out a keyboard and run an experiment.

We could say the same thing for testing, in terms of running tests or creating mini SQL and batch scripts, log file parsers, setup programs, and so on.

Takeaways

First and foremost, I want to suggest a predisposition toward action. Don't argue about facts; run experiments. Find out how long a process will take. Stay late one night and get that thing done. If someone else is blocked, find the obstacle and remove it. If you are blocked, work around it.

Second of all, you might want to consider bringing your laptop to meetings, and when people start arguing about facts, resolve the issue.

If we could eliminate these sort of false blockages from our projects, I suggest that we would see a significant improvement in productivity, across the board.

Most importantly, most people are scared to do this.

I still don't know why, but they are.

So go do it yourself.

In his article "Enough About Process: What We Need Are Heroes", James Bach defines the hero as one who takes initiative to solve a vague and ambiguous problem.

Go ahead.

Let the hero be you.

Next: Subject Matter Expertise Previous: /Lean/ Lightning Talks