perimental mindset” and fast and open communication with each others. Ensuring joint understanding of requirements In IID frequent integration and testing ensured that the subcontrac- tor had understood the requirements correctly. This is a typ- ical uncertainty in distributed development, especially when companies have not worked together before and have dif- ferent cultures. Frequent integration and testing gives fast feedback and any misinterpretations become visible early. Thus, possible misunderstandings have less damaging con- sequences. Moreover, learning from mistakes is fast and happens early, preventing problems from accumulating and creating situations that are harder to resolve. Avoiding “big bang” integration IID,as used in our case companies, prevented different sites and partners from do- ing too long periods of independent development, which could have led to modules that would be hard or impossible to integrate, i.e., they avoided possible problems that would come from “a big bang integration”.
4. Discussion and Conclusions Frequent communication is a central prerequisite for suc- cessful implementation of IID in a distributed environment. This way of development requires much more communica- tion between parties during the whole collaboration com- pared to development where work products can be clearly separated into independently developed modules. Espe- cially uncertainties in the form of changing requirements demand communication and problem solving. In uncer- tain environments short iteration cycles are needed to re- veal problems as early as possible. The shorter the cycle the more communication is needed to coordinate the work and to quickly solve the problems during development. When the cycles are longer the communication need is more con- centrated to the integration phase. This communication overhead is clearly an issue that requires careful planning when implementing IID in a distributed environment. Defining an iteration length that is suitable for distributed development is an interesting topic. In our study both projects A and B, used one week integration cycles suc- cessfully also with subcontractors. Fowler  reported that iteration cycles should not be shorter than two weeks in off- shore projects due to communication overhead. One expla- nation to this difference could be that in our study all par- ties that participated in weekly iterations were from Europe and therefore the time-zone difference was quite minimal. Moreover, the subcontractor in project A had on-site per- sonnel at the customer company, which facilitated commu- nication. Fowler, however, worked with projects distributed between India and Europe or North America, where time differences are noteworthy. 4.1. Limitations Our initial results presented in this paper are based only on a few case projects, which limits our possibility to draw far reaching conclusions. Moreover, when doing our first interview round we did not concentrate on studying IID, but asked about many other practices too. This means that we