Setup described in this story was reached after four years of development in heavy process based project.
How was this achieved:
- Bringup tests were automated in a sustainable manner, i.e. the effort to keep them actual is affordable. It is not like team would not try to automate tests before – but several factors like technology or experience have killed this try.
- Teams have given up in negotiations with “CM responsible” and created a tool chain with significantly better performance.
- Number of builds (or integrations) was increased from two per week to more than 100 ((6*4+2)*5 + 2) [(6 teams 4 times a day + 2 common) 5 times a week + 2 regular builds = 132]
- Number of builds that can be daily executed gave the possibility to optimize the CM structure and adapt according to system dynamics.
The simplified schematic of actual structure is on next picture:
One morning we have discussed with the team how has the build structure evolved. Consensus that we came to: whole story is nice demonstration of general self-organizing system behavior, if the system detects an obstacle. In this case, we have developed complete CM solution outside our CM department and CM build as was known in previous versions is just last formal step right now. This points to the weak management as well – we were not able to improve most inflexible and obviously slowing down ring of our development chain.
And finally once again causal loop diagram:
