"Failure is not fatal, but failure to change might be." — John Wooden
I was serving as liaison between an outsourced development team and a client who wanted to retool their SaaS platform. The project was structured into twelve sprints of two to three weeks each. By the end of sprint three, we had produced meaningful work — but received almost no client input. I could feel the development team's frustration rising.
I asked the owner to sit down with me and walk through the application. Within fifteen minutes, he was visibly frustrated. The new UI didn't reflect what he had envisioned. Several features were missing. He wanted to know why work had started without what he called an "all-encompassing design specification."
I left that meeting feeling better about our timeline, not worse — because the owner's reaction confirmed exactly what I expected. There is no such thing as a complete design spec. Clients never provide sufficient detail upfront, and they never adequately test what they're given until it's in front of them. What I was practicing — and what the timeline needed to accommodate — was value-driven development: responding to change rather than following a static plan.
Roadmap Considerations
◆ Is testing completed within the same development sprint as the corresponding code? If not, defects accumulate faster than they're resolved. ◆ Is documentation minimal, purposeful, and secondary to working code? Documentation that no one reads consumes time that could build features. ◆ Does the plan allow the software to evolve in response to changes in business conditions and user feedback? If the roadmap is immutable, it's already wrong.