Ask HN: Should you ship an MVP if your team isn't agile

[JulianMiller520]

I've been working with a vendor who is clearly on to something product-wise but the version they shipped is buggy and simple things like modal window controls aren't working. They impressed in the beginning but now the bosses are talking about ditching them because they aren't able to fix the features they shipped in a timely manner. It really made me wonder if they've done damage by shipping too early. Thoughts?

[lucisferre]

What I'm guessing you are looking at is a prototype, whether they know it or not, and it is rarely a good idea to simply try to fix the bugs in a prototype. They are great for validating early assumptions but typically should be thrown away once that cycle is completed and rewritten.

Trying to improve and fix prototype code is typically very challenging. It often has no architecture or structure, so changes and new features are slow to implement.

If this vendor doesn't understand this, or it seems likely that having them rewrite it would just result in another prototype quality result then your bosses are right to walk away.

[JulianMiller520]

Great take! Any ideas for evaluating if they are stuck at the prototype phase? Perhaps tell-tale signs you've seen in the past?

[lucisferre]

It's hard to say without knowing the situation and the team involved better.

Almost any really new software or even feature generally needs some amount of prototyping initially and usually this will happen whether the team planned it that way or not. However, if this step of the development process wasn't communicated to you from the beginning then I would suspect that they are either ignorant of this, or at least their organization is (I assume this is a contract or agency situation?). Either situation will be a potential problem for your company since it means they will continue to accrue technical debt rather than iterating on the prototype.

Done properly the prototype is either all or mostly thrown out and re-built from the ground up to improve and solidify the architectural and software design aspects. This paves the way for future feature development to continue unfettered by technical debt and early defects. Trying to simple cover the defects with "duct tape" or "cowboy" code is likely to cause the rest of the work to slog on and future iterations an feature development will become very slow.

However, without knowing more about your situation I'm not sure how useful or correct my advice is here.