3 ms·

The problem with "everyone leaves at 5" is that everyone's forced to come in at 8 or 9. Some people work differently. I'd take a 50-60 hour work week with flexi

by strlen 16y ago

The problem with "everyone leaves at 5" is that everyone's forced to come in at 8 or 9. Some people work differently. I'd take a 50-60 hour work week with flexible hours (and ability to learn new technologies, improve existing infrastructure and initiate "venture" projects) over a 45 hour work week with fixed hours and a strict adherence to a development methodology. Perhaps that's why I am drawn almost solely to technology organizations and could never see myself working anywhere else (e.g., consulting or internal systems development).

city41 16y ago
True, I hear you. I can't speak for everybody. But I still think there is truth that efficient, sustainable hours can be more productive than long, stressful hours.
- strlen 16y ago
  > But I still think there is truth that efficient, sustainable hours can be more productive than long, stressful hours. I agree here (when I find myself working 60+ hours a week outside of rare crunch time, I am usually doing something wrong e.g., giving bad estimates or losing focus), but forcing people to work "efficient hours" (you must be in the office at 9, vs. being allowed to come in at 11 and stay until 8) is micro management (loss of autonomy). Not being allowed to do (even non-user facing e.g., infrastructure) projects without permission from project management, planning meetings and daily status reports is another example of micro management. Perhaps this isn't a part of agile manifesto (just like concentration camps aren't a part of the communist manifesto), but that aspect is certainly a feature of almost all implementations of uppercase-A agile (scrum, XP, etc...). I'm all for frequent releases, continuous integration (and possibly continuous deployment), iterative development (at least for product features) et al, but you don't need a full blown "Agile" process (planning meetings, daily stand-ups, index cards, bringing in training consultants, hiring "scrum masters", etc...) for that. Work life balance is important. It's also very important to work smartly and use labour saving techniques (adequate hardware, tools/automation). Performance requires maintenance and I make sure to allocate down time (time with friends and relatives, concerts, non-technical reading, trips/vacations, exercise, etc...) to myself on a regular basis. However, the most important aspects of a job (to me) are autonomy, great colleagues and challenging work (exposure to new concepts and technologies, which frequently have a learning curve). Given a choice between working a 1-2 hours more and giving up any one of these aspects, I'd gladly accept a few hours more of work.
  - city41 16y ago
    I don't include working 8-5 in my definition of "efficient". Although I do think working the same hours as the rest of your team has benefits too good to ignore. I mean having a life where you can still exercise, eat well, enjoy some hobbies, spend time with friends, etc. Means that when I sit down to work, I'm so much more focused and willing that I ultimately get more work done. I agree following a process to the letter without really thinking about what it's doing for you is bad. If you feel agile is not allowing you to pursue other needed things then that's bad. Take what works for you from a process and leave the rest behind.

by strlen 16y ago

city41 16y ago

True, I hear you. I can't speak for everybody. But I still think there is truth that efficient, sustainable hours can be more productive than long, stressful hours.

strlen 16y ago
> But I still think there is truth that efficient, sustainable hours can be more productive than long, stressful hours. I agree here (when I find myself working 60+ hours a week outside of rare crunch time, I am usually doing something wrong e.g., giving bad estimates or losing focus), but forcing people to work "efficient hours" (you must be in the office at 9, vs. being allowed to come in at 11 and stay until 8) is micro management (loss of autonomy). Not being allowed to do (even non-user facing e.g., infrastructure) projects without permission from project management, planning meetings and daily status reports is another example of micro management. Perhaps this isn't a part of agile manifesto (just like concentration camps aren't a part of the communist manifesto), but that aspect is certainly a feature of almost all implementations of uppercase-A agile (scrum, XP, etc...). I'm all for frequent releases, continuous integration (and possibly continuous deployment), iterative development (at least for product features) et al, but you don't need a full blown "Agile" process (planning meetings, daily stand-ups, index cards, bringing in training consultants, hiring "scrum masters", etc...) for that. Work life balance is important. It's also very important to work smartly and use labour saving techniques (adequate hardware, tools/automation). Performance requires maintenance and I make sure to allocate down time (time with friends and relatives, concerts, non-technical reading, trips/vacations, exercise, etc...) to myself on a regular basis. However, the most important aspects of a job (to me) are autonomy, great colleagues and challenging work (exposure to new concepts and technologies, which frequently have a learning curve). Given a choice between working a 1-2 hours more and giving up any one of these aspects, I'd gladly accept a few hours more of work.
- city41 16y ago
  I don't include working 8-5 in my definition of "efficient". Although I do think working the same hours as the rest of your team has benefits too good to ignore. I mean having a life where you can still exercise, eat well, enjoy some hobbies, spend time with friends, etc. Means that when I sit down to work, I'm so much more focused and willing that I ultimately get more work done. I agree following a process to the letter without really thinking about what it's doing for you is bad. If you feel agile is not allowing you to pursue other needed things then that's bad. Take what works for you from a process and leave the rest behind.