Continuous integration, and for that matter, TDD, FDD, and other Agile practices and methods can be obscure to someone who hasn’t run across them before. Since some Agile approaches really relate to engineers more directly than to their managers and executives, I have been asked why business-people should care about some of them?
The question might be examined from the other side – how do things that are important to the business side relate to things happening on the technology side. Put yet another way, is the whole organization in-sync and harmonious, or is the left hand interfering with the right. Finding consistency of vision and values across disciplines within an organization can be very difficult, but there are good examples of business’ values being reflected in engineering practices.
Kaizen, for example, is an increasingly common business watch-word. It’s philosophies of waste-reduction, orderliness, and continuous improvement have radically affected Toyota’s much-vaunted production system, for example. This philosophy, and other principles have influenced Total Quality Management, Lean analysis, Six Sigma, and other value-oriented business management practices. Kaizen is often translated as meaning a continuous improvement in small increments, and in practice is almost a micro-quality-control. The idea that a single defect can bring a production line to a halt, so that the defect is caught early and fixed when it is cheap springs from this approach. (Kaizen is much more than this, and often also refers to a short high-value problem-solving session that uses related principles. Kaizen, in this context, refers to the process philosophy and the practice thereof, cf. Kaizen.)
Continuous integration is a software engineering practice that is quite similar. When combined with test-driven development, it forms a kind of Toyota-style production line scenario. Continuous integration basically means that all changes to the software are integrated with the rest of the software as soon as the developer submits the change to the central repository. At that point, or at very near intervals, the whole system is run through unit and integration tests to see that it is still healthy. If a defect arises, either through a mistaken submission, or the submission of something that breaks something else, the system alerts the developer, and possibly relevant management. The system “goes red”, as the jargon goes, and the developer rapidly fixes whatever is out-of-sync. This is quite analogous to Toyota’s “stop the production-line” approach to quality management.
Assigning power so close to the ground can be frightening to both executives and technical employees alike. This is understandable. People used to controlling everything often find it hard to delegate to the “shop floor”, and people who are used to possessing little power are often afraid to wield it once it is granted. Both the arenas of technology and business, however, have established, through volumes of evidence, that defects caught early can be orders of magnitude cheaper to fix. Toyota leapt ahead in its reputation of quality very soon after implementing such a system. Businesses that use Kaizen or other related approaches to quality management and process evaluation on the business side can see these principles at work in their software development organizations.
As with most good things – simple principles, broadly applied to specific disciplines, work to the overall benefit of the organization. They provide confidence and common vision and value across disparate specialties. Business stakeholders who make these high-level decisions can then have increased confidence that what they’re defining, marketing, and selling won’t fail them in execution in the customers’ hands.