Results Workspace Only

Question

I would like to configure ROWE for my development team: Result Only Work Environment.

Basically, people work as they want, whenever they want, until the work is done. This environment was a huge success for Best Buy: increasing productivity and reducing sales.

Does anyone have any tips for doing this work for the development team?

Edit:

More: I will lead a team of 3 other fairly experienced developers. I plan to standardize core processes such as version control, bug tracking, code review, planning, testing, etc. “How they want to work” refers more to how they manage their time: for example, scheduling appointments, pair programming.

Answer 1

If you have other departments in your organization, consider managing their expectations. It will be difficult to convince them that their project will take longer (throw on all the technical jargon that you can think of) than you thought when you noticed that your team was never there (in their eyes).

You still have to have realistic expectations when planning. Do you really allow flexible time when they have 10 hours of work that must be completed in 10 hours? How are you going to deal with troubleshooting issues that escalate into the development team?

One developer may be consistently better than others / less time, but a team may feel that this person has a lighter workload. Get ready to crush some ego.

I think pair programming is missing?

Answer 2

The answer to this question will vary depending on the size and culture of the organization. Some also argue that the process can make a difference, and you don’t want your people to take any approach to achieve a result through something that they don’t feel is just as important.

Can you provide additional information about the size of the organization and what works today, like today?

Answer 3

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

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

Answer 4

WHEN they want will be easier than they want. I would not give so much freedom to the developers. IMHO, this will lead to a complete mess of code.

Today, very few very good developers, and those who are good enough, must become development leaders and make global decisions. Others should just follow the instructions, or all hell could break.

Answer 5

You need to determine what results they must achieve, clearly and completely unambiguously, so that they understand what they can control (in essence, how they work, the order in which they develop things, etc.) and what they cannot ( usually what is expected of them - both in terms of the actual product, and with supporting materials, such as progress reports, and when all this is intended for delivery). You also need to tell them what resources they have - can they order highly specialized machines or order new software, for example, or is this all decided?

I would also ensure that one of their early results was a schedule of completed steps against which you could measure progress and agree with them what would happen if they started to miss the milestones.

But I have little doubt that you are going to determine version control, bug tracking, and so on. Surely this is what you should let them decide? In the end, they are part of the process. Personally, I would say that they should have version control, centralized logging of defects, etc., But the mechanisms, tools and processes should correspond to them.

It looks like you are saying that you want to create results only in a production environment, but do not trust them. If you say what you are going to do is create a ROWE, then you need to make sure that otherwise you really only perform half the process, and these situations rarely deliver the benefits people hope for.

In the end, either you trust them or not, but if you cannot trust them to decide how to make version control, which is frankly secondary to developers, you probably shouldn't trust them with a schedule that is usually much less simple a question.

Answer 6

Focusing on results means you have to trust your developers to make the best decisions. Some people love this freedom. They applaud when they have the freedom to use a wrench as a hammer, if that means faster results, instead of switching tools to stick the image on the wall.

But sometimes it can hurt. The processes are designed for maximum productivity, efficiency and effectiveness, with all kinds of safety measures. Using the wrong subversive tool, the developer could easily slip through and delete the entire history of all the work performed by the team, thereby eliminating the "undo" magic function.

In another case, most fresh graduations (which, as I know) do not have the knowledge or the ability to make decisions on their own. They may not produce as quickly as they can with someone bark orders from him / her. One of the most distinguishable characteristics of the new city is that when he is at an impasse or does not know what is happening, he does not ask for help.

Your developers must be in the right mood to achieve their goals. Freedom is good, but control and make sure it is the right way.