Companies are getting bigger, projects do so, and a need of scaling grows. The purpose of this post is focusing on aspects of building agile scaling scheme in an organization. There are taken into account communication and integration aspects. These aspects are often not properly executed or neglected at all. They are in fact inevitable factors in achieving scaling goal.
Unit tests vs. Integration tests
Let’s start the consideration with integration concerns in development aspects of writing tests. Here, the assumption of a unit test is a code as simple as possible in order to verify one exact functionality. In real world example those tests have mocks to components which are not subject of the verification. In integration tests there are a few mocks or not mocks at all and there are verified certain number of functionalities working together. Assuming this scenario, which kind of test is more appropriate? Unit tests are hardly ever heavy. They are lean, small and fit. At least, they are expected to appear this way. Mocking may sometimes take time and trouble. Even though all unit tests work properly in separation, it does not imply that a bigger part built on top of smaller parts work together properly too. Small unit tests with mocks are fine, perhaps. However they may prevent from revealing problems with mocked objects. If quality is a goal, testing cannot be deferred to production. Appropriate test harness is needed during development. We conclude that there is much higher confidence in software correctness and quality if it is verified on the production-like environment. The environment is a result of modules integration.
Teams integration concerns
Development concerns are scaled to distributed development model. When agile teams are scaled then a distributed development emerges. Parallel development of unit modules is desired to speed up implementation. One dimension of keeping teams together are dependencies. In case they don’t exist, teams are building different systems, though. As long as each team works on its duties, no problem occurs. It applies in a same way to considered testing matters. Teams have to have their mutual integration plan. Following the unit and integration testing reasoning, there is a need of teams integration harness during daily development. On release level, total – not a harness integration has to happen.
Communication comes first
Conway’s law formulate the following:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations [1].
Assuming the law is true, we can consider the following implications:
good communication -> good design
bad communication -> bad design
Going further, because design is a copy of communication it works conversely i.e.
good design -> good communication
bad design -> bad communication
Product reveals how communication works in a certain company. Addressing this to the subject of this discussion, we guess that quality of software system integration reveals quality of communication in the company producing software.
Only well organized teams scaling development model gives an opportunity to build a great product. Proper communication is the foundation. Communication leads to integration and integration enables scaling. Scaling is commonly desired and not always properly understood factor in organization expansion. However scaling is like an iceberg. There are other virtues building this goal, we call them communication and integration. If a developer distinguishes unit and integration tests, he/she very likely will feel a need of teams work integration on the organization level. It works in both ways. Having good understanding of teams cooperation will support understanding unit and integration tests. Communication structure cannot be established only once. In agile environment this requires continuous inspection and adaptation. Here starts the journey to success.
Summary
Communication and integration are just only simple words. There is a lot of work behind them in order to make them meaningful in succeeding with scaling. Practice and observations convince they are necessary to achieve goal whereas it’s challenging turning them into action.