4 ms·

Sounds kind of familiar. We started a mvp/prototype that was handed to one guy without that much of a planning. That guy is really good coder but not a product

by trm42 8y ago

Sounds kind of familiar. We started a mvp/prototype that was handed to one guy without that much of a planning. That guy is really good coder but not a product owner/manager, documentor or planner. You see where this is going? This was about empowering team members with responsibility. Without a concrete plan it was really hard for the rest of us to help or say what's really important. And so began the feature creep for something that was suppose to be a quick prototype ended up being whole implementation which took half a year to get first somewhat working version. The problems for us was we didn't know status of anything as it was always promised to be ready in 1-2 weeks but feature creep made it bigger and bigger. We tried to help with planning sessions etc but that wasn't enough to get the prototype back to track. As everybody got a bit too rosy picture of its status, our salesguy started selling the idea forward. The timing seemed to be right etc but we didn't have even proper deml version as the one guy chugged on with his waterfall ad hoc dev style... After our sales guy confirmed there's lot of demand for this proto and we got the first somewhat working version out and when the next steps were not really sane, we made an intervention which we felt we should've done four months earlier. First we had a team discussion and decision what should we do together for the situation and then we created concrete plan for the next steps we felt we needed to get first sane version out. Then we made this public to everybody. The funny thing with this intervention was that the guy who made the feature creep proto felt relieved after this. The biggrst reason why we were so reluctant to intervene was that this guy would get badly demotivated but he had chugged on so long he did get really stressed and frustrated with the situation but didn't know how to get help in the hole he had dug in. So my advice is to talk out loud and make things visible. Timelines, features bot yet implemented etc. Maybe a gant timeline etc. These helped us to get the project to a sane point shere to continue.

kimdotcom 8y ago
So, have a plan?
BigJono 8y ago
> Without a concrete plan it was really hard for the rest of us to help or say what's really important. And so began the feature creep for something that was suppose to be a quick prototype ended up being whole implementation which took half a year to get first somewhat working version. This is interesting. Every example of scope creep I've run into has been a case of too many cooks in the kitchen, or an over-zealous "thinker" (as opposed to a "doer"). If I want to avoid scope creep I limit the scope of the project to as few people as possible and get them as close to the users/market as possible. It sounds more to me like everyone did get their two cents in, but not in the correct way, and this lone developer was formulating the requirements based on way too many informal channels rather than one structured one.

by trm42 8y ago

kimdotcom 8y ago

So, have a plan?

BigJono 8y ago

> Without a concrete plan it was really hard for the rest of us to help or say what's really important. And so began the feature creep for something that was suppose to be a quick prototype ended up being whole implementation which took half a year to get first somewhat working version. This is interesting. Every example of scope creep I've run into has been a case of too many cooks in the kitchen, or an over-zealous "thinker" (as opposed to a "doer"). If I want to avoid scope creep I limit the scope of the project to as few people as possible and get them as close to the users/market as possible. It sounds more to me like everyone did get their two cents in, but not in the correct way, and this lone developer was formulating the requirements based on way too many informal channels rather than one structured one.