3 ms·

The first one is clearly a situation tailor made for 24/7 because your requirements change in such short periods. This is similar to how companies that offer 24

The first one is clearly a situation tailor made for 24/7 because your requirements change in such short periods. This is similar to how companies that offer 24/7 technical support benefit from 24/7 dev availability. The second doesn’t seem to be an advantage for 24/7 availability. You would have achieved the same if you had hired the second team in a different country but in the same time zone as you. Arguably, with the more synchronous communication (I, on team A, have a question for someone on team B that’s blocking me can get the answer immediately instead of having to wait for my next shift) you may have been done even earlier.

indymike 4y ago
> Arguably, with the more synchronous communication (I, on team A, have a question for someone on team B that’s blocking me can get the answer immediately instead of having to wait for my next shift) you may have been done even earlier. What really worked was building something, showing the customer at 3pm, getting a change list and having all the changes done by 9am the next day. Also being able to do a design session and have all the prototype views done the next day really made customers happy. Another thing that was nice: we could have a bunch of stuff built at night and then test and fix it the next day (or vice versa). You do have to assign tickets a little differently. You want avoid making tickets so big that a developer can't finish one in a day - or you can get into where there's lots of blocking. Regardless, I think the 24 hour cycle worked pretty well for us, and if I start another dev shop, I'll do it that way again. A lot of the benefit was probably forcing everyone to do a couple of smart things: great CI, smaller tickets and complete work in one work day whenever possible. No dangling tickets. Avoid even having tickets where a developer can block another as much as you reasonably can. All of these things would have made a single timezone team better, too.

indymike 4y ago

> Arguably, with the more synchronous communication (I, on team A, have a question for someone on team B that’s blocking me can get the answer immediately instead of having to wait for my next shift) you may have been done even earlier. What really worked was building something, showing the customer at 3pm, getting a change list and having all the changes done by 9am the next day. Also being able to do a design session and have all the prototype views done the next day really made customers happy. Another thing that was nice: we could have a bunch of stuff built at night and then test and fix it the next day (or vice versa). You do have to assign tickets a little differently. You want avoid making tickets so big that a developer can't finish one in a day - or you can get into where there's lots of blocking. Regardless, I think the 24 hour cycle worked pretty well for us, and if I start another dev shop, I'll do it that way again. A lot of the benefit was probably forcing everyone to do a couple of smart things: great CI, smaller tickets and complete work in one work day whenever possible. No dangling tickets. Avoid even having tickets where a developer can block another as much as you reasonably can. All of these things would have made a single timezone team better, too.