Just Go Touch the Boat

February 23, 2019

A few years ago, I set out to build a boat in my garage. It was a pretty substantial project. Frankly, it was a lot more than I think I was really prepared for. Nevertheless, I did it. It took me about three years to get done, but I finally realized that particular dream and went sailing on a boat I had built myself. Pretty cool, right?

Well, one of my biggest frustrations was this weird phenomenon that happened right before I got started on the work. I can remember it happening in a very specific place: in the garage doorway. Full of good intentions, and ready to get down to cutting some wood, I would pause at the entry to the garage. There was this moment of uncertainty. Often it wasn’t just a moment though, this could turn into a 10-minute-long, what-in-the-hell-was-I-thinking pause. Often it could completely derail me. I’d spin right on my heels and head back to the couch where a beer and Netflix (and blissful determinism) awaited me. It got so bad that I had a rule: just go touch the boat. I figured doing that much would get me close enough to the problem to create the momentum to figure out the next step.

That pause…what was that?

It was a real killer. Here’s what I think it was: it was realizing that I really didn’t know what I was going to do next. At a high level, I knew I wanted to work on the boat. But the specifics – what part of the boat was I going to work on, what did I need to do specifically? That often wasn’t fully thought out. I had an instruction manual, but that really only described the high-level activities that I had to do. The devil was in the details. I suspect that the delays came down to a few different categories of problem:

  • Setup– Are the requisite materials, tools and plans ready for the next step in the process. Are these preparations in a state where I can easily get started or is there some work I need to do before I can even touch the boat. Often this would be cleanup activities. Often, I had left my workspace a mess after the last session, so I couldn’t get started or find tools until I cleaned up the place. Or perhaps my wife had the audacity to park the car in the garage, thereby blocking my access to my precious…sorry…my boat. 
  • Comprehension– Do I really understand how to solve the problem at hand? I’ve learned that much of woodworking is a series of problems. At a macro level, the work is straightforward, but when you get right down to it, you discover that the tools you have don’t work right. Or you are missing a tool. Or you have no clue how to get the geometry of two pieces right in advance.
  • Drive– There were times when I had things set up, and I knew what to do, but…I didn’t want to. Sometimes the prospect of turning on the table saw, braving the spinning blade of death, and filling the garage with a fine layer of sawdust (over absolutely EVERYTHING) was just too much. Huh…there, I said it. There were these moments when I just couldn’t face the effort after a long day at the office or sometimes even on a Saturday.

I mention all of this because I find myself in a similar position now. I’m not building a boat. Instead, I’m building a business. Just like a boat, there are plenty of instruction manuals. The problem is, just like with the boat, the details are often different from what they describe in the books. And I find myself eager to get started. And yet I pause…

So, I’m re-using a mantra that served me well when building the boat: just go touch the boat. I’m not sure what to call this pause. This moment of uncertainty before committing. But I’m willing to bet big money I’m not alone. 


Announcing The Swarming Development Method

October 6, 2014

music-music-player-musical-instrument-566-824x550

By now, you’ve probably figured out that I’m laying out all the guidance for using Swarming as a legitimate, full-fledged, Agile method. It looks like this:

Swarming

There you have it. A complete method for swarming. Wrap it up and ship it.

“But wait!” you say, “You’re not a real methodologist, your just some guy with a blog!” You are absolutely right. What gives me the right to propose a new agile methodology? What kind of egomaniac thinks he can just pop up with a completely new method of team development? Well, actually, it’s not that new. I pulled a lot of the material from a variety of existing sources. I copied the format for the Values and the principles from the Agile Manifesto. Nothing here is all that original. After all, if I’m right, bugs have been doing this stuff without the benefit of my genius for millions of years. Why would I do this?

First, I’d like to state this as emphatically as I can: ANYBODY CAN DO THIS!¬†We can all be copying methods and tweaking them – and we should. No real experience is required. After all, that’s how the guys who came up with Scrum, and Kanban, and XP did it. They copied ideas from Takeuchi and Nonaka, Ohno, Demming, Goldratt, and a whole bunch of others. We need to keep doing that – copying and stealing and mixing and removing bits until we find methods that work even better. Take this opportunity to make a methodology that is an expression of your beliefs. Heck, maybe it expresses the vision of your entire team…or company.

Secondly, there just aren’t enough methodologies out there. Having scrum taking over 80% of the agile project management ecosystem is really, really…boring. Ken Schwaber, one of the creators of Scrum, has always maintained that something better will come along one day. I’m sure that’s true, but it won’t happen unless we are creating a vibrant ecosystem of competing methods. Just having Scrum and Kanban isn’t enough.

So feel free to take this¬†methodology – it’s yours. Run with it (careful, it’s pointy), copy it, break it, fix it, and for God’s sake, make something wonderful.