Listen to this post
An intermediary practice is a practice that works indirectly on what you are trying to achieve. Before discussing examples and the risks of intermediary patterns, let’s look at some of the things needed to achieve flow (realizing value without delay):
- Removing delays in workflow (hand-offs and waiting for others), feedback, learning, and between getting and using information
- Manual testing
- Technical debt
By working directly on these, here is what you would have.
- Small items to work on
- Work cells (people working together to reduce hand-offs)
- A team having end-to-end responsibility for functionality
- Managing proper levels of Work-in-Process
- Acceptance specification before design
Here are a few intermediary practices, that assist these issues.
- Cross-functional teams
There is no question these intermediary practices are good. But they should be recognized as such. This enables them to be better because people understand what they are trying to achieve. Also, if they are not easy or advisable to achieve the direct practices can be done and improved in steps.