This is the kickoff of our new series 5 Minutes. We will feature here spotlights on people with current topics. The first one is Frank Westphal, Agile Software Technologist from Hamburg, who works as freelancer and consultant. His approach is about Web 2.0, Lean Management, Extreme Programming and test-driven Software Development. He did consulting on qype.com, makes an German podcast called Tonabnehmer and his latest project Rivva is a “Meme Tracker”, that searches weblogs in context of Web 2.0 for top-stories and zeitgeist topics.

Hello Frank. Why do you follow the “Agile Software / Extreme Programming” approach? And why do you think this strategies work on software development?

I’ve been a proponent of Agile Development and especially Extreme Programming (XP) because I think that their approach to developing software is true to the nature of software. For the first time in computing history, we see software as what it truely is: soft, malleable, flexible and extremely easy to change. Software has this funny characteristic that its very existence changes its own requirements. How often have you demo’d some stuff to some people and got dozens of new ideas along the way? It’s due to the fact that software is so intangible that directions keep changing during the course of a typical software project. Some people think that setting everything in stone (the plan, the requirements, everything) is the right answer, but we think that’s just stupid. Change is inevitable. In fact, that’s why we do software, not hardware, in the first place.

The only way to succeed in a world of constant change, though, is to stay Lean. In other words: Only do the things that add value, at the time they add value, and with the intensity they add value. We’ve borrowed heavily from the Just-in-Time school of thought at Toyota. They’ve become increasingly good at this stuff through their Kaizen practice of endless self-improvement. There’s much to be learned from the eastern folks.

Can you in short explain the method of “Getting Things Done” and why this is a useful method?

Getting Things Done (GTD) is David Allens self and time management method and has developed almost cult status following among computer geeks for a very good reason. One of its central ideas is the Mind Sweep: Get everything you need or want to do out of your mind and into a trusted system like for example a PDA or a stack of index cards. Our primary goal is Zen-like emptiness because our minds are generally better at having ideas, not holding ideas.

Another central idea is the concept of the Next Physical Action: Just ask yourself: What’s the next tiny step to make progress towards your project goals? Many people naturally write these lists of “things to do” in times of crisis or before their holidays. Why limit what works so well only to those moments? To clear out our heads and get closure on all open loops in our lives, we do context-specific lists in GTD all the time. Works like a charm.

How do you think that “Getting Things Done” can be suitable for software development? Or is it mainly targeted at project management?

In my experience, you can profit from GTD on several levels. On a personal one, Getting Things Done helps you define your work: The typical task of all knowledge work, like software development, is rather amorphous. In fact, it’s our job to define our job. However, some people easily go out on tangentials and then suffer from a bad work / life balance. GTD keeps them focussed and generally in a flow state of mind.

On a project level, Getting Things Done’s “next actions”, “waiting for” and “someday/maybe” lists, accompanied by its weekly review are some powerful tools. At the end of your next project meeting, just ask the simple question: What’s the next physical action?

Do you think that the “Getting Things Done” method can be further enhanced?

Hard to tell. The general suggestion is to take the GTD book as your starting line only. Every GTD’er evolves his or her own way of “getting things done” over time anyway. GTD may sound deceptively simple, almost common sense, and on many levels it is. As a whole, however, it takes a lot of discipline. I guess, that’s a sweet spot where additional tools might come handy.

You also have recently written a book, can you say in short what it deals about it and why you have written it?

It’s a german book about Test-Driven Development the core XP practices. I originally set out to write an XP comic book, but then I found that the chapters I had written had slowly culminated into a book of their own. Eventually, I had to skip the whole comic idea because it would have cost me too much time.

Please say something about yourself, what makes you tick and work and why you are happy with it.

That would be my fixed-gear bike that makes me tick. All my friends think I’m insane that I would ride a track bike with no brakes on the streets. Unlike other bikes, such a bike doesn’t coast. So, as long as your wheels are in motion, your legs are in motion. It’s a total addiction to ride a fixie and develop the much-needed skills to survive on such a bike in city traffic. I guess, I really should become a bike messenger.

Thanks for this inspiring talk.

Text and Interview: Martin Wisniowski, March 2007

Frank Westphal

Website: Frankwestphal.de

Podcast: Tonabnehmer

Latest Project: Rivva.de