The Ballad of Tim Toady

Open-Minded Project Management

Choices

There’s an old saying among Perl programmers that has weaved its way into the developer’s lexicon:

There’s more than one way to do it

 

 

 

And, being Perl, it was initialized to TMTOWTDI, which is clearly pronounced “Tim Toady.”

These three Perl blocks do the same thing (example stolen from Wikipedia):

print if 1..3 or /match/

if(1..3 || /match/) {print}

use English;
if( $INPUT_LINE_NUMBER >= 1 and $INPUT_LINE_NUMBER <= 3 or $ARG =~ m/match/ )
{ print $ARG; }

Tim Toady Strikes Again!

I’d like to amend that phrase:

There’s more than one way to get there

 

 

 

Go ahead, mop the walls, because I know I just blew your mind.

Here’s a map of the area near where I live.  I picked a typical “Point A” (the green arrow in the lower left) and “Point B” (the red arrow in the middle right) and crudely drew four paths that I’ve actually taken to get from A to B:

Why have I taken so many different routes to get home?  Because none of them are ideal all the time.

• The most direct route (dark blue) consistently has the most traffic, and usually takes the longest, except during off-hours
• The light green route bypasses some of that traffic, but the bulk of it is along the straight line, so not much savings there
• The red line, though far more circuitous, is my preferred path, because it is a reasonable trade-off (less direct, but less traffic)
• The light blue line is an outlier, but because of construction, I took that route once and saved some time

Okay, but what does this have to do with managing projects?

It may be obvious already, but…

• There are many paths to get from Point A to Point B on a project
• There are trade-offs for each path
• No path is always correct
• You will run into roadblocks on any path, even a path you’ve traveled hundreds of times before

And then there’s the more kitschy and esoteric analogies:

• You might break down on the way to your destination, and need to call for help
• You might need to stop to refuel, because you’re not going to make it with your current resources
• You could take a path that’s not even on the visible roadmap, but you might travel it alone
• If you’re traveling with other people, they may have ideas on how to get to Point B that you’ve never considered
• If a path is short but full of traffic or roadblocks, you’ll waste resources getting there
• If a path is uphill, there will be more wear and tear

How can I apply this to my projects?

First, try not to beat the car analogy into the ground, like I have (and will continue to do).

I am always experimenting.  Every team is different.  Every tool is different.  Sometimes you need a lot of structure to guide a project to success.  Sometimes you don’t need any (rare, but true).  I have my preferred approaches (just like my preferred driving route), but I’m always open to new ways of solving a problem.  It’s great to have a strong opinion, but always be willing to consider that it’s not right.  It could be that your opinion is right for every circumstance but the one you’re dealing with right now.

Be willing to change.  Give an approach or a tool a try, but monitor its effectiveness, and the team’s attitude.  Yes, it’s a balancing act, but a major tenet of agile methodologies is adaptability.

When I first read about and implemented Scrum, I used Ken Schwaber book “Agile Project Management with Scrum.”  Ken made a big point of insisting that although Scrum was a set of guidelines, and not a formal process, that it would only succeed if you followed ALL of the guidelines.

And that’s what I did when I started.

Then I saw many large companies who had made the transition from Waterfall to Scrum fail because they didn’t follow all of the guidelines.  Instead, they picked and chose the ones that made sense, and discarded anything they didn’t see as valuable.

And that gave Scrum and agile a bad reputation among those companies.

So I continued to follow all of the guidelines, and projects were “successful.”  But my teams sometimes felt that the demands of the process were too great.  It didn’t feel very agile to them.  I realized that there’s still a lot of flexibility within the guidelines, and that one of the keys is getting out of the team’s way as much as possible.  A perfect example is the expectation of keeping estimates and actuals up to date at least once per day, and preferably whenever progress is made, so that the burndown chart accurately reflects progress.  It takes time and context-switching to keep the tool updated, and it’s ultimately beneficial for the ScrumMaster or project manager, not for the team.  Sure, the team gets some benefit by capturing and tracking tasks and hours, but let’s face it – it’s for the data reporting nerds who need to ensure the project is on track, and who want to show a beautiful stair-step chart to Complete Acceptance.

Burndown Chart #1:  Hooray!

Burndown Chart #2:  Oh Noes!

Changes

The reality is that although the team did not reach 100% completion of the scheduled tasks in that second burndown, they were not 250 hours behind, as the chart indicates.  The team just got real, real busy doing their jobs, so updating remaining work and actuals was an afterthought.

So I made the necessary updates to reflect reality (to keep the team focused until the iteration was finished), and did the demo for the client.  The client was happy with the new functionality, and that’s what mattered.

We talked about it in the retrospective (you are doing retrospectives, right?), and decided that actuals were not essential to track in the PM tool, because they were already being tracked in the time tracking tool.  By removing duplicate work tracking actuals, the development team stepped up and did a much better job tracking remaining work.

It was a very small change, but it worked.  The developers got into the habit of updating the PM tool when they checked in their code (which was at least 3 times per day), and the tool started to reflect reality.  It was less of a burden to the development team and the project manager (me), and the client had updated information all the time.

It’s a simple lesson, but a powerful one, and it applies to project management, driving a car, or having any conversation:  know your destination, pay attention, and be ready to change course, because there’s more than one way to do it, Tim.