4 ms·

I'm really curious as to how ROWE works in practice for software developers, because the I'm extremely dubious. In software development, there is usually an "i

I'm really curious as to how ROWE works in practice for software developers, because the I'm extremely dubious. In software development, there is usually an "infinite amount of work" to be done, so the important thing is to prioritize well as a lot of that work will never get done. But what does it mean to say "you've met all your objectives"? If you say "great, I finished all my objectives in 20 hours this week, see you at the beach", this company will eventually get killed by competitors who are just as productive yet work 40+ hours a week. But fundamentally, the idea of "you've met your objectives, now you can go home" just feels like a fantasy in the world of software development.

p1esk 3y ago
What do you do during sprint planning meetings if you don’t know your objectives?
- hn_throwaway_99 3y ago
  But it's not like you complete your objectives and then you say "great, we're all done, let's go home." Every company I've ever worked for had a backlog a mile long, and we knew we'd probably only ever get to 20% of it or so. The whole purpose of sprint planning is to just prioritize the most important stuff to work on for the next sprint, but if the teams capacity increases you'd pull more stuff in.
  - p1esk 3y ago
    No, the purpose of sprint planning is to specify (more ot less) exactly what you plan to do this sprint. Usually the best case scenario. You make your best effort to finish the things you outlined, sometimes you manage to do it, sometimes you don’t, but why would you ever try to do more than you planned to do? If you’ve done the tasks, you’re done, period, go relax, grab a beer, wait till the next sprint. You’ve literally done your job. Why in the world would you want to “pull more stuff in”? That’s how I’ve done it, and have seen it done in the last 7 companies I worked at. Your reasoning is so foreign to me. The only way it makes sense if you are speaking as a manager.
    - hn_throwaway_99 3y ago
      > If you’ve done the tasks, you’re done, period, go relax, grab a beer, wait till the next sprint. Well, to each their own, but that has never been the case in any of the companies I've worked at. In fairness, over the fast 5 years or so more and more the companies I've worked at have used Kanban over sprint planning, because usually the "estimation" part of agile (i.e. the cards, the voting) has proven to be the most useless piece of agile.
      - p1esk 3y ago
        Regardless of what you use, you should have a clear idea of what you plan to accomplish in the next n days. And you need to communicate this information to your manager. If you have done that, and the manager agrees it’s a reasonable objective then I don’t see how what you describe can ever happen. If an unplanned task comes up with a high priority then you simply tell your manager: “OK, sure, which of the planned tasks do you want to delay?” It doesn’t matter what you use for planning, you agree to do something in advance, and you provide a reasonable estimate of how long it will take. Your manager should trust your estimates, even if they are sometimes wrong.
        mixmastamyk 3y ago
        I’ve worked at both types of places. The main difference was if one was a contractor or on salary. I also believe everyone needs a mental break at the end of an accomplished iteration. The satisfaction of feeling done. You might only answer email or edit docs on that day but that’s definitely worthwhile. Not to mention, when you have a family, weekends aren’t especially relaxing, so if you “sprint” every week for years, it leads to almost certain burnout. In other words, we don’t run marathons at full speed for a reason. Oh and by the way, even at the contracting place where we were given fresh tickets when done early, no one ever expected them done immediately. So in effect we’d sit on them, take a mental break, and everyone was happy with appearances—the theater of work.
1123581321 3y ago
ROWE would essentially encode a normal software job into a mix of goals and expectations. E.g. if you're expected to average some fraction of the team's point velocity over the year, that's written down. If you're expected to jump from a finished ticket to the next, or alternate reviewing and starting new work, that's written down. (A ROWE job description can totally be written to keep you stuck at work if it has availability or response time expectations.) If you work at a smart company, your manager doesn't spell out much of your job, and ROWE can encapsulate that if you and your manager have a shared understanding of what an effective month/quarter/year looks like. If you're that kind of senior engineer, the exercise should prompt some good discussion about reducing the number of hours you spend on more measurable, less effective tasks. The goal is to create something that both you and your manager buy into, so they feel good if that's 'all' you do and you feel it's doable to review the list and feel good about it before the end of a typical workweek. As you might be able to tell, it's not easy to come up with a list that achieves this. Most managers will be too timid, or won't understand themselves well enough, to put the real full expectations of a job on paper. However, a 'certified ROWE' workplace undergoes coaching so they have a better chance of success, similarly to how some organizations do for OKRs if they want to use them as intended and not as fantasy aspirations. In practice, if you have a boss that hates ROWE, you're going to have a tough time convincing them that you've met your objectives enough to step away from work for a bit, no differently than how any other flexible work arrangement stops being flexible the moment your boss stops trusting you. (I'm close to a ROWE-certified organization that has been successful with it for about 15 years.)

p1esk 3y ago

What do you do during sprint planning meetings if you don’t know your objectives?

hn_throwaway_99 3y ago
But it's not like you complete your objectives and then you say "great, we're all done, let's go home." Every company I've ever worked for had a backlog a mile long, and we knew we'd probably only ever get to 20% of it or so. The whole purpose of sprint planning is to just prioritize the most important stuff to work on for the next sprint, but if the teams capacity increases you'd pull more stuff in.
- p1esk 3y ago
  No, the purpose of sprint planning is to specify (more ot less) exactly what you plan to do this sprint. Usually the best case scenario. You make your best effort to finish the things you outlined, sometimes you manage to do it, sometimes you don’t, but why would you ever try to do more than you planned to do? If you’ve done the tasks, you’re done, period, go relax, grab a beer, wait till the next sprint. You’ve literally done your job. Why in the world would you want to “pull more stuff in”? That’s how I’ve done it, and have seen it done in the last 7 companies I worked at. Your reasoning is so foreign to me. The only way it makes sense if you are speaking as a manager.
  - hn_throwaway_99 3y ago
    > If you’ve done the tasks, you’re done, period, go relax, grab a beer, wait till the next sprint. Well, to each their own, but that has never been the case in any of the companies I've worked at. In fairness, over the fast 5 years or so more and more the companies I've worked at have used Kanban over sprint planning, because usually the "estimation" part of agile (i.e. the cards, the voting) has proven to be the most useless piece of agile.
    - p1esk 3y ago
      Regardless of what you use, you should have a clear idea of what you plan to accomplish in the next n days. And you need to communicate this information to your manager. If you have done that, and the manager agrees it’s a reasonable objective then I don’t see how what you describe can ever happen. If an unplanned task comes up with a high priority then you simply tell your manager: “OK, sure, which of the planned tasks do you want to delay?” It doesn’t matter what you use for planning, you agree to do something in advance, and you provide a reasonable estimate of how long it will take. Your manager should trust your estimates, even if they are sometimes wrong.
      - mixmastamyk 3y ago
        I’ve worked at both types of places. The main difference was if one was a contractor or on salary. I also believe everyone needs a mental break at the end of an accomplished iteration. The satisfaction of feeling done. You might only answer email or edit docs on that day but that’s definitely worthwhile. Not to mention, when you have a family, weekends aren’t especially relaxing, so if you “sprint” every week for years, it leads to almost certain burnout. In other words, we don’t run marathons at full speed for a reason. Oh and by the way, even at the contracting place where we were given fresh tickets when done early, no one ever expected them done immediately. So in effect we’d sit on them, take a mental break, and everyone was happy with appearances—the theater of work.

1123581321 3y ago

ROWE would essentially encode a normal software job into a mix of goals and expectations. E.g. if you're expected to average some fraction of the team's point velocity over the year, that's written down. If you're expected to jump from a finished ticket to the next, or alternate reviewing and starting new work, that's written down. (A ROWE job description can totally be written to keep you stuck at work if it has availability or response time expectations.) If you work at a smart company, your manager doesn't spell out much of your job, and ROWE can encapsulate that if you and your manager have a shared understanding of what an effective month/quarter/year looks like. If you're that kind of senior engineer, the exercise should prompt some good discussion about reducing the number of hours you spend on more measurable, less effective tasks. The goal is to create something that both you and your manager buy into, so they feel good if that's 'all' you do and you feel it's doable to review the list and feel good about it before the end of a typical workweek. As you might be able to tell, it's not easy to come up with a list that achieves this. Most managers will be too timid, or won't understand themselves well enough, to put the real full expectations of a job on paper. However, a 'certified ROWE' workplace undergoes coaching so they have a better chance of success, similarly to how some organizations do for OKRs if they want to use them as intended and not as fantasy aspirations. In practice, if you have a boss that hates ROWE, you're going to have a tough time convincing them that you've met your objectives enough to step away from work for a bit, no differently than how any other flexible work arrangement stops being flexible the moment your boss stops trusting you. (I'm close to a ROWE-certified organization that has been successful with it for about 15 years.)