I was originally going to title this post “slow the fuck down”, but there’s more to it than that.
First off, there’s a new movement out there called Slow Programming. I’ve seen some traffic about it in the blogs I read, and I’m sure there’s more to come. The premise is simple: long, deliberate planning and long, deliberate development. In terms of the development, though, “long [and] deliberate” is relative due to all the planning beforehand.
In other words, it’s the antithesis of Agile Programming, which calls for a short design/planning cycle and short development “sprints” in order to adapt to changing requirements.
Agile still gets my vote. But, this comes with a caveat: Agile requires team members dedicated to following the particular methodology being used, and mature enough not to panic. If everyone wants to panic, methodology goes out the window anyway, so you might as well go for something more lightweight.
Remember, Panic is not an agile methodology.
It’s easy to conflate Agile’s call for minimal design & planning with throwing those phases out the window completely and diving into coding head-first. Design & planning are still critical to getting a project off the ground. I’m living through a textbook example of what happens when nobody can be bothered to sit down & plan a project out: we’re overdue and over budget, yet I need to call the client today and figure out how the site is going to figure out how much a customer gets charged. This is the kind of thing that should have been figured out months ago, before the first line of code was written. Instead, we’re setting the rules 600 hours into the project because planning & design weren’t seen as important. You can’t be agile and change the rules mid-stream if you don’t have the rules in the first place. You have to have sprints planned out for the next few months before you can see how a change will effect them.
How should design be done on an agile project? With an agile kind of design! Sketches are a great agile design tool, because they encourage scribbling and reshaping and even throwing them out completely. If it took 30 seconds to sketch a page out, I feel a lot less guilty crumpling it up & pitching it than if a graphic designer spent 30 minutes on a mock-up. Further, the client is going to be a lot more comfortable suggesting the changes they want. Minimal work up front, easy to change…sounds pretty Agile to me.
Remember, Agile methodologies exist to minimize the cost (in terms of money and other resources) of making changes.
I was going to end this entry here, but as I thought about this subject I flashed back to an incident earlier in my career. The mainframe our software communicated with went down. Thousands of dollars of orders were in limbo, and it was my job to figure out which ones actually made it to the mainframe for fulfillment and which ones were queued up and might need to be refunded if the outage took a long time. After everything was back up & running, my boss at the time commented on how calm I remained through the whole thing, while everyone else was panicking around me. “When there’s a meteor about to wipe out the Earth, I’ll panic. This is just a server outage.”
Panic is our enemy. We want to feel and look like we’re in the moment, that we comprehend the gravitas of the situation, especially when upper management is watching and money is on the line. Panic is one way to show that urgency, but it leads to snap judgements and bad decisions. Rationality gets abandoned, for the most part, in the rush to “do something”. And, when it works, we get praise for our “quick thinking”. Bad behavior gets reinforced with praise. It’s addictive.
Also, panic is often accompanied by a rush of adrenaline, which makes us feel alert & ready to spring into action. But that adrenaline rush doesn’t last, leaving us burned out. Staying calm through a crisis keeps us ready to deal with changes as the situation develops. You might say that staying calm…keeps us agile!
If you’ve gotten this far, I hope you see where I’m coming from. Agile planning and deliberate actions are not exclusive. In fact, deliberate actions make it easier to be agile. Panic isn’t the answer, but neither is “slow programming”. Calm the fuck down, and you’ll find you’re a lot less stressed out and you’ll have more success at the things you do.
June 25th, 2007 at 7:25 pm
[...] and because I wasn’t in a panic about how late this project was, they took my “casual attitude” to mean that I [...]