- Discovering Value
- Communicating Value to the Team
- Vision Tests
- Link Tests
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Communicating Value to the Team
When tests are used to express value, they force an architect to focus on customer value rather than on technology, elegance of solution, or other distractions. Those other decisions are the responsibility of the implementing team, not the architect, and they're a distraction from what really matters when you're envisioning a feature. Even if the person playing the part of an architect early in a feature's life ends up implementing that feature, its implementation details or decisions don't belong in architectural artifacts.
The tests must express value for the customer; if they don't, it's time to reevaluate what the architect is trying to accomplish and why. If a test expresses what a customer values, it's not a big leap to start calling that test a specification of the value we want to deliver. Once you've put the effort into creating a complete specification of the value that the team needs to produce, why would you even consider using anything else to communicate with them?
In a modern Agile team, tests are well understood as a way of judging success. For more than a decade, engineers have started projects by looking at the tests that a QA group will use to determine product quality. Tests are a "native tongue" of good software developers all over the world, which makes tests a very clear way to communicate goals.
The other great side-effect of communicating with tests is that it allows an architect and a team to collaborate and apply their creativity to the problem, rather than micromanaging the details of how they do their job. In this way, the medium of communication actually encourages better results.