2 ms·
“whoever needs to use your thing has a certain stretch of time where they can implement their part.” This can be ameliorated many times by attempting to mock s
by cudgy 3y ago
“whoever needs to use your thing has a certain stretch of time where they can implement their part.”
This can be ameliorated many times by attempting to mock something that covers the most likely interaction between the dependencies. For example, you are waiting for an API to provide some data to you: create an agreed upon JSON format that you will expect to receive and use that to mockup the interface till it’s complete. This allows both sides to move forward more independently till both are complete and ready for integration.
- doctor_eval 3y agoI think as well that this is a problem that Kanban solves quite well. Instead of having a team sitting around waiting for another team, ideally you have people who can take a bit of work from a board and be productive even if their primary project is stalled. This is (part of) how I've run my last few projects and it's been very successful from a productivity perspective. The problems I've had with this is getting management to understand that productivity and developer quality-of-life is important. They want road maps, god damn it, because reasons. And they say they won't hold us to the road map, but then they do. And at the same time, the road map captures productivity because now you're doing what the road map says instead of being productive. But building software is often like building a tunnel. You don't know what you're going to be drilling through until you've drilled through it.