Result Only Work Environment

Question

I would like to set up a ROWE for my dev team: Result Only Work Environment.

Basically, people work how they want, when they want, as long as the work gets done. This environment has been a huge success for Best Buy: increasing productivity and reducing turnover.

Does anyone have any advice for making this work for a dev team?

Edit:

More details: I will be leading a team of 3 other fairly experienced developers. I plan on standardizing the basic processes, such as version control, bug tracking, code review, planning, testing, etc. "How they want to work" more refers to how they manage their time: i.e. scheduling meetings, pair programming.

Answer 1

The answer to this question is going to vary depending on the size and culture of the organization. Some would also argue that the process can matter, and you don't want your people taking any approach to achieve a result at the expense of something which they do not feel as as important.

Can you provide more info on the size of the organization and what working there is like today?

Answer 2

WHEN they want will be easiear than HOW they want. I wouldn't give that much freedom to devs. IMHO, this would lead to a total mess of code.

There's very few very good developers out there today and those that are good enough should be made development leads and make the global decisions. Others should just follow the instructions or all hell can break loose.

Answer 3

Make sure you hire the right people, you might find they work more than they WANT to admit X-).

Programming is more than a job, its a passion, and if you find the right person to fit your environment, performance measures go out the door, as the do it for the love of it.

Answer 4

If you have other departments in your org., consider managing their expectations as well. It will be difficult to convince them that their project is going to take longer (throw in all the technical jargon you can think of) than you thought when they notice your team is never around (in their eyes).

You'll still have to have realistic expectations in your planning. Are you really allowing for flex time when they have 10 hrs of work to do that is due in 10 hours? How are you going to handle trouble-shooting issues that get escalated to the dev team?

One developer could be consistently better than the rest/take less time, but the team may feel this person has a lighter workload. Get ready to crush some egos.

I guess pair-programming is out?

Answer 5

Results oriented means that you must trust your developers to make the best decisions. Some people love this freedom. They cheer when they have the freedom to use a wrench as a hammer if it meant quicker results, rather than switching tools just to nail a picture on the wall.

But sometimes it could be damaging. Processes are designed for maximum productivity, efficiency, and effectiveness, with all kinds of safety measures. With the wrong subversion tool, a developer could easily slip and delete all history of all work done by the team, thus eliminating the magical "undo" feature.

In another case, most fresh grads (that I know) don't have the knowledge or capacity to make decisions on their own. They may not produce as fast as they would be able to with someone barking orders at him/her. One of the most distinguishable characteristics of a fresh grad is when he is stumped or doesn't know what's going on, he doesn't ask for help.

Your developers must have the right set of mind in order to achieve goals. Freedom is good, but monitor and make sure it's the correct way to go.

Answer 6

You need to define what the results they're meant to achieve are clearly and completely unambiguously so they understand what they can control (essentially how they work, the order they develop things in and so on) and what they can't (usually what they're expected to deliver - both in terms of actual product and supporting materials such as progress reports - and when it's all meant to be delivered). You also need to let them know what resources they have - can they order high spec machines or order new software for instance or is that all decided?

I'd also ensure that one of their early deliverables was a schedule of completed milestones against which you could measure progress and agree with them what happens if they start missing milestones.

But I am slightly dubious about the idea that you're going to define version control, bug tracking and so on. Surely these are things you should let them decide? After all they're part of the process. Personally I'd state that they must have version control, centralised defect logging and so on but the mechanisms, tools and processes should be up to them.

It feels a little like you say you want to create a results only work environment but you don't quite trust them. If you're saying what you're going to do is create a ROWE then you need to make sure it's just that otherwise you're really only doing half the process and those situations rarely deliver the benefits people are hoping for.

After all, either you trust them or you don't but if you can't trust them to work out how to do version control which is frankly second nature to developers, you probably shouldn't be trusting them with the schedule which is normally a far less straightforward matter.