Build a Team that Ships
startupboy.com
Build a Team that Ships
1–10 of 37 posts
Re: Build a Team that Ships
#2 No tasks longer than one week. You have to ship
something into live production every week – worst
case, two weeks.
Re: Build a Team that Ships
#3No tasks longer than one week. You have to ship something into live production every week – worst case, two weeks. Does this actually work? What I mean is, no matter how much you break down a task, aren't certain sub-tasks going to take more time than this?
I feel like the author sort of answers this question with the following statement:
It’s not perfect. We ship too many features, many half-baked.
The product is complex, with many blind alleys.
This is a great approach. It's also not always appropriate for everyone.
Re: Build a Team that Ships
#4No tasks longer than one week. You have to ship something into live production every week – worst case, two weeks. Does this actually work? What I mean is, no matter how much you break down a task, aren't certain sub-tasks going to take more time than this?
It does if your problems are simple...
Re: Build a Team that Ships
#5No tasks longer than one week. You have to ship something into live production every week – worst case, two weeks. Does this actually work? What I mean is, no matter how much you break down a task, aren't certain sub-tasks going to take more time than this?
I feel like the author sort of answers this question with the following statement: It’s not perfect. We ship too many features, many half-baked. The product is complex, with many blind alleys. It sounds like his team is more focused on just getting something out and improving it iteratively than it is on producing a polished product that is architected beautifully. This is a great approach. It's also not always appro…
I wonder if refactoring work is allowed to meet this requirement, even though it's not customer-visible?
Re: Build a Team that Ships
#6I feel like at a certain point you are moving too fast. The author makes it seem like he is chasing after speed at his own peril.
Isn't it better to take an extra week to polish a feature than to just "ship it" and then patch it later? At a certain point as your organization grows and your product becomes more mature shouldn't your focus shift from quantity of features released to actually shipping quality releases?
I know there is a balance here. Don't be so worried about polish that you don't ship anything but don't be so blinded by speed that you ship everything within a week. You just can't make blanket rules like this.
Re: Build a Team that Ships
#7Earlier quoted context omitted.
I feel like the author sort of answers this question with the following statement: It’s not perfect. We ship too many features, many half-baked. The product is complex, with many blind alleys. It sounds like his team is more focused on just getting something out and improving it iteratively than it is on producing a polished product that is architected beautifully. This is a great approach. It's also not always appro…
I wonder if refactoring work is allowed to meet this requirement, even though it's not customer-visible?
Promise you will deliver the refactored code in a week, set out some metrics, ship it.
The other devs will be happy someone improved the code. Like the guy said, it's better they ship what they want than not ship what you want
Brilliant IMO
Re: Build a Team that Ships
#8No tasks longer than one week. You have to ship something into live production every week – worst case, two weeks. Does this actually work? What I mean is, no matter how much you break down a task, aren't certain sub-tasks going to take more time than this?
In my experience, tasks that take longer than one week sometimes take two weeks. But if they don't make it within two, they basically never ship. It's like you can go out and have one drink, or two, or many. But never three...
Re: Build a Team that Ships
#9Earlier quoted context omitted.
I feel like the author sort of answers this question with the following statement: It’s not perfect. We ship too many features, many half-baked. The product is complex, with many blind alleys. It sounds like his team is more focused on just getting something out and improving it iteratively than it is on producing a polished product that is architected beautifully. This is a great approach. It's also not always appro…
I wonder if refactoring work is allowed to meet this requirement, even though it's not customer-visible?
We do regular one-day long refactoring sessions where everyone refactors. But yeah, our codebase is not a thing of beauty. We're more focused on figuring out what users actually want, and we'll rebuild it when it's falling over.
Re: Build a Team that Ships
#10"All BD via APIs". I know what APIs are, but what's BD?