5 ms·

"- I think it's easy to 'hide' from the team if a developer is having a problem (either with their code, or their motivation). It's easy to coast through an unp

by gexla 15y ago

"- I think it's easy to 'hide' from the team if a developer is having a problem (either with their code, or their motivation). It's easy to coast through an unproductive day and there is often a delay in the other team members realising that a project is falling behind schedule." I understand the code part of this problem. I think it's good to have a set estimate on how long the item should take so that as soon as you hit that tripwire you stop, send a notification out to the rest of the team, explain the situation and ask for feedback. Perhaps a good way to help with this would be to setup a "feature timer" which automatically hits an "oh shit" button and sends out the notifications automatically.

JonAtkinson 15y ago
It's a problem which we're mainly trying to solve with visibility. We have a HipChat bot (which shares commit messages, Jenkins feedback etc), and we're considering having it just post "What are you working on" into the group chatroom once an hour. Like most problems, I think it can be solved with a bit of self-reflection and better communication.
nulluk 15y ago
I have to disclose I am a remote worker for JonAtkinson. I believe set estimates are not the best way to approach this problem because how do you estimate it? If you are in new territory then what seems trivial to one person may require some research and extra understanding by another. Also when you set a deadline it becomes more of a target for the individual action and instills a time wasting mentality. It's especially difficult when a new employer enters the company as they feel under pressure that this is the expected deadline. One of the most helpful things Jon has done to elevate this situation when it arises is allow honest conversations without any fear which come from I guess a personal understanding/experience. I also don't believe this problem is specific to remote working, it's simply a managerial problem within the industry as I am willing to openly admit this (having a problem and not speaking up) also happened at my previous job but the openness didn't exist hence a lot of dodging and ducking was performed until the task at hand was accomplished.
- gexla 15y ago
  The estimate wouldn't be a deadline or for billing purposes. It would be more of a tripwire for "this task needs attention" to make sure a developer doesn't get bogged down in a task that he / she is unwilling to admit defeat on. Sometimes all that is needed is a fresh perspective from someone else to look at the task and offer a different approach. Think about those situations where you bang your head on a wall for far too long on a problem and then take a break or sleep on the problem and then fix it immediately when you get back to the task. Another developer could also offer this fresh perspective. The task may simply be bigger than originally estimated and the discussion may be no more than "okay, adjust the estimate and keep doing your thing." Also, in some cases there actually would need to be a deadline and there would need to be pressure. It depends on your situation. X startup working on their own application may have wiggle room for their timeline, but I do mostly client work where our deadlines are pretty much set. Often I need to give estimates which the rest of the team will use as part of tracking and projecting the overall timeline as well as setting the expectations for the client. I agree with you though. It sounds like you guys have a great setup.

by gexla 15y ago

JonAtkinson 15y ago

It's a problem which we're mainly trying to solve with visibility. We have a HipChat bot (which shares commit messages, Jenkins feedback etc), and we're considering having it just post "What are you working on" into the group chatroom once an hour. Like most problems, I think it can be solved with a bit of self-reflection and better communication.

nulluk 15y ago

I have to disclose I am a remote worker for JonAtkinson. I believe set estimates are not the best way to approach this problem because how do you estimate it? If you are in new territory then what seems trivial to one person may require some research and extra understanding by another. Also when you set a deadline it becomes more of a target for the individual action and instills a time wasting mentality. It's especially difficult when a new employer enters the company as they feel under pressure that this is the expected deadline. One of the most helpful things Jon has done to elevate this situation when it arises is allow honest conversations without any fear which come from I guess a personal understanding/experience. I also don't believe this problem is specific to remote working, it's simply a managerial problem within the industry as I am willing to openly admit this (having a problem and not speaking up) also happened at my previous job but the openness didn't exist hence a lot of dodging and ducking was performed until the task at hand was accomplished.

gexla 15y ago
The estimate wouldn't be a deadline or for billing purposes. It would be more of a tripwire for "this task needs attention" to make sure a developer doesn't get bogged down in a task that he / she is unwilling to admit defeat on. Sometimes all that is needed is a fresh perspective from someone else to look at the task and offer a different approach. Think about those situations where you bang your head on a wall for far too long on a problem and then take a break or sleep on the problem and then fix it immediately when you get back to the task. Another developer could also offer this fresh perspective. The task may simply be bigger than originally estimated and the discussion may be no more than "okay, adjust the estimate and keep doing your thing." Also, in some cases there actually would need to be a deadline and there would need to be pressure. It depends on your situation. X startup working on their own application may have wiggle room for their timeline, but I do mostly client work where our deadlines are pretty much set. Often I need to give estimates which the rest of the team will use as part of tracking and projecting the overall timeline as well as setting the expectations for the client. I agree with you though. It sounds like you guys have a great setup.