Honestly, this is the way most early stage startups operate, other than this one: > 2. All Nighters over All Sprints (and some early stage startups operate that way too) These practices are all bad as a company scales - you need tests to prevent regressions as the code base grows, documentation to avoid repeating yourself, product managers making informed product decisions, etc. But when you have just a handful of em…
Yep — scope creep is the only other one I’d say early stage startups should avoid. But everything else is fine. Just talk to users too.
I have had a few great experiences where I’ve travelled to a customer with a few other dev/product ppl, and for a few days we just iterate on features that have unclear scope, synching up with them for feedback once or twice per day. But it really only works because we’re right there with the customer, getting constant feedback, and the work is timeboxed instead of scopeboxed.
For more normal cases, where you have to actually ship to get feedback, having a small, fixed scope for the work before you start is much better.