I also would be interested in a blog post about this. Seems to me (and some other commentators) on this thread, that very often there's an "infinite" amount of work to do, and I don't see how that squares with "we pay you for results".
A team I was on a few years ago did scrum (poorly). We had a list of tickets the product owner wanted done for the sprint. Except, more often than not, additional tickets would be added into the sprint (Either because us engineers found dependencies or because of additional bug requests).
Scrum doctrine says that you now have a broken sprint, and all bets are off. Did it matter to management? Nope.
This was a large Rails project (about 7 full time developers for a year+). It's possible it's different when you're working on many small projects.
I guess my worry about ROWE is situations where the result is, "Implementing all your tickets on your plate" and worries about what happens in environments where tickets get added to your plate such that the number of your tickets on Thursday == the number of your tickets on Tuesday. (Even though you implemented 6 tickets between now and then). I would certainly be interested in any comments/information/thought you have on a situation like that.
I work with Jonathan as a client - and my organization also does ROWE. I can say for a certainty that it works great for Rails projects. It comes down to intrinsic vs. extrinsic motivation.
Hours, made-up deadlines, etc. are all forms of extrinsic motivation which have been proven to destroy creativity, problem solving, and productivity.
ROWE needs to be a part of a bigger whole at how we look at and motivate employees. If you just drop ROWE into your current organization without taking a systems-level view, you're likely to fail. ROWE is like Agile - it's not a panacea - but if you zoom out and incorporate the philosophy at a systems level, I think you'll get great results.
Yes, Agile in not a panacea: you can't just drop it into an existing org and expect things to be rainbows and kittens. It needs to be accepted both at the grass-roots level AND management level.
Then when Agile fails a person or an organization it's Agile's (or Scrum's) fault... when it's really a people problem.
I guess I'm just waiting for the blog articles, 10 years from now, bemoaning ROWE because it didn't save an organization with a toxic environment. :-) (And feeling sorry for the poor developers involved).
As an addendum to what Matt said, like any substantial initiative, ROWE needs support from the whole organization to succeed.
But as you mention Ryan, it is super easy for those being measured to game metrics and optimize so that they look good. Mitigating this effect is very challenging and one that we continually face but our approach, and it has held up well so far, is to focus on people over process. I.e., our results include questions like "Are developers happy?" and "Are clients happy?"
Nebulous questions with unquantifiable metrics like these keep us honest and communicative with our clients and focused on the process of setting reasonable expectations that satisfy all. We stay focused on the people and change the process to ensure results, and expectations, are met.
Results may change from developer to developer, client to client, and week to week! We expect them to change as we make progress on the project.
Can you explain how your company uses ROWE? Was it there when you started, or did you witness the shift from hour-based work/pay to results-based work/pay?
I work in the same place as Jonathan, and have found working in a results only work environment to be an extreme step up. I started after the transition, and it was a very obliviously different environment than anywhere else we work.
The way we work is that we have very focused week or month or quarterly results we are responsible for, and we have a very transparent way of seeing who needs to do what and what is getting done. Beyond that, it's a big part of our culture not to be negative is someone chooses to work different hours or out of the office. It's their results to complete, and they know how they work most effectively.
