How to go ROWE (result only work environment)?
Even though we are a startup and heavily leaning on result-only work environment model, I noticed it's really hard to do this correctly, we still do have core hours and so many similar stuff and so far didn't manage to implement this successfully.
Is there any good guide on prerequisites for ROWE, or tips and tricks of implementation? Even better can you describe your own experience if you are part of a ROWE company.
I'm talking from the perspective of a software-product company and mostly referring to development team rather than business people.
1 Answer
Its an interesting concept, the best tip I can give is to define what the results are in detail and to break them down into bite sized chunks.
My company breaks a typical design into 4-8 sprints of 2 weeks each, each sprint has roughly 140 tasks which cover between 30 mins and 4 hours.
We started doing this because we wanted the junior developers to know what "done" meant because they would always say "i'm done" and invariably they would be no where near it when we checked.
Each of tasks represents a "thing that needs to be checked off". Each developer can still "do it their way" but it ensures they don't forget anything and is the "sign off" of the results that is important.
We include each known user interface, database table, search and unit test that is indicated by the design. Other come up obviously and they go into the next sprint or if really serious are addressed on the spot.
People by default have to do the minimum hours because the tasks while they have "buffer" built in are still fairly accurate.
-
Thanks for the great insight, what's the action if a certain person doesn't finish their own sprint? Do people go over the "expected" hours to finish their sprints and do they just don't do anything for the rest of the week if they already finished their sprints? – The Dictator 13 years ago
-
We have a tool (Jira) which tracks their progress throughout the sprint. As soon as they seem to be slipping they have myself and the project manager sitting next to them working through the issue. – Robin Vessey 13 years ago
-
I also spend most mornings doing the rounds of the office, discussing each project with each person and removing hurdles, putting them in contact with the person most likely to be able to help them. – Robin Vessey 13 years ago
-
I think you right, it comes down to do a good estimation and then let them do it. (for the record we are using the same method, 1 week, 1 sprint generally) however lost of people miss their sprints which makes it kind of useless. I assume this is a problem either about estimation or lack commitment etc. – The Dictator 13 years ago
-
I thought so too until I started breaking the tasks down to sub half day chucks, with them sitting there in the room commenting, and then monitor and question half day "where is it up to, what is getting in the way, how can I help remove the road block" ... often it was twitter and facebook but they pretty soon got the message. – Robin Vessey 13 years ago
-
This is Agile/Scrum right? Iterations and whatnot? Works well for large teams, I worked at a company of about 25 people and it worked flawlessly for getting stuff done. Eventually you can predict how many hours a team can do in a 2 week iteration very closely. – Digital Sea 13 years ago
-
We have 8 dev on 6 projects a month and it works just fine – Robin Vessey 13 years ago
