Most of the conversation about the agile technical practices tends to stay in the weeds. We talk about whether we should test before or after, whether we should be writing unit or acceptance tests, whether we should be mocking or not, whether PR’s are helpful or harmful. We have discussions back and forth about all of these topics and while they are good details, they sometimes obscure what’s really important.
None of these things are the goals. They’re all steps towards the goals and if we lose sight of what the goals themselves are, then none of these things matter.
From my perspective, the business case for all the technical practices boils down to two things:
- Faster and more actionable feedback so we can make better decisions.
- A higher quality product so our customers get more value.
Why might we want to use Test Driven Development (TDD)? Its focus on design results in a higher quality product. It also encourages smaller, more granular, automated tests which will provide faster and better feedback.
Why might we want to aggressively refactor the code? It results in higher quality.
Why might we want to have multiple people working together in pairs on an ensemble? Higher quality. Faster and better feedback.
Why might we want to continually integrate the code? How about releasing frequently? Faster and better feedback.
So if you’re asking yourself whether you need the agile technical practices, ask instead whether you need faster, more actionable, feedback and high quality. If you don’t care about those things then no, you don’t need any of this.
If you do care about being able to make better and more timely decisions and do want to deliver high quality solutions to your customers, then it’s time to focus on improving our technical practices. Once we’ve made that decision, we can start looking into the details again.