I recently became aware of Daniel Pink and some of his theories on motivation. His TED talk on The surprising science of motivation, where he introduces the Results Only Work Environment concept is quite thought-provoking, and well worth a watch.

At my workplace, I have responsibility for a number of small software development teams. Each of these teams tends to work with a different technology. We have a Java team, a Ruby/Rails team, a Python/Django team, and a smattering of C/C#/C++/Perl guys. Over the past 12-18 months, we've been slowly switching our development methodology away from the waterfall model towards a more agile approach.

One of the catalysts that helped get me started on promoting and adopting agile was the following quote from a Joel Spolsky article:

Some programming teams adopt a "waterfall" mentality: we will design the program all at once, write a spec, print it, and throw it over the wall at the programmers and go home. All I have to say is: "Ha ha ha ha ha ha ha ha!" This approach is why specs have such a bad reputation. A lot of people have said to me, "specs are useless, because nobody follows them, they're always out of date, and they never reflect the product." Excuse me. Maybe your specs are out of date and don't reflect the product. My specs are updated frequently. The updating continues as the product is developed and new decisions are made. The spec always reflects our best collective understanding of how the product is going to work.

When I decided that it was time for us to start moving towards agile development, I actually printed the above quote in large letters on an A4 sheet and plastered several copies around our office ;-)

In general, the results have been pretty good. In particular, I've found that web-based development (of which we do quite a bit of) lends itself particularly well to shorter development iterations with incremental functionality enhancements. Users appreciate that we can turn-around feature requests fairly quickly and provide regular updates, and the developers cope better with smaller "bite-sized" stories.

Getting back to ROWE, one of my teams (my Rails team) has ended up in a ROWE by accident, rather than design. This came about when we simply couldn't find good Rails developers locally, and ended up hiring some contractors in another country. These guys work their own hours, set their own schedules and mostly work from home. My only criteria is that they keep me informed (we use tools such as PT and Campfire extensively) and keep delivering. Which they do. I've found that they are eminently more motivated and productive than the office-based teams working the conventional 9-6 routine.

The challenge I face at the moment is convincing some of my fellow PHB's that a ROWE is something worth exploring further - as it's quite a paradigm shift ;-)