people work with the same code modules, there is a potential to start deleting other people's changes. In this case, the effort to recreate lost changes is considered waste and greatly impacts velocity. At this time in the project, implementing a competent CM tool may become a high priority.
By employing prioritization and JIT, we can ensure we do not build out too much infrastructure too soon, therefore limiting our infrastructure debt. Otherwise an "inventory of infrastructure" becomes shelf ware until such time that it is needed. In addition, there may be changes that occur to the direction of the project that makes the shelf ware infrastructure of less value or constrains future infrastructure direction. In both cases, this leads to waste, a muda in the lean world.
The next strategy focuses on a model that includes two different groups who need to work together to establish the infrastructure for the Agile method being used. The first group is the project team who is using Agile to deliver working software for the end-user (the ultimate customer who perceives the business value). The second group is the infrastructure team who builds out the infrastructure. Interestingly, the project team becomes the customer for the infrastructure team, just as the end-users are the customers for the project team. Just like the standard practice where the customer should be part of the project team for continuous feedback, the same holds true that a member of the project team should be on the infrastructure team. This is important to understand because the project team is the group that must assess the value of the changes so that the infrastructure team knows which infrastructure changes are perceived to be of most value and which to work on.