Think back to the last few projects your team worked on. How did you spend your ‘sprint 0’ (or in waterfall your ‘requirements analysis’ phase)?
Did you spend it deciding on the technology stack your team would use? The Database, the front end framework, the message queueing stack, the server side framework, the language?
Or did you spend it building out the first feature to get feedback?
Chances are, you spent it making technology choices, but not really building anything.
Think back to the decision to chose the tech stack up front, or the database up front, or anything else that became a pillar of your application up front.
Did you know enough about the project and its intended purpose to be able to make those decisions, confident that it wouldn’t bite you later?
Put another way:
Why do we make the hard decisions up front, when we know the least? We will never know less about a project than we do in the first iteration. As project teams, we’re in precisely the worst possible place to make lasting decisions about the technology stack or framework or database.
You will never know less about what you’re working on than you do right now. Tomorrow you know more, and the next day you’ll know more than that, and so on. At some point, you’ll be able to make the hard decisions with confidence and the least risk possible.
Would you rather have a development strategy that helps you show progress while helping you defer the risky decisions, or a development strategy that requires you to have knowledge you can’t have at the beginning of a project?
Do you know what that development strategy is called that systematically helps you show progress early and often, and defer risky decisions until the risk is mitigated?
Test Driven Development.