Continuous Improvement in Context
Beth took a situation that was out of control and tried to control it, applying the theory that slower is safer. In some cases that’s true. Slower often gives you more chances to correct yourself and react, but slow might not be safer in all cases. When driving a vehicle, it often appears safer to drive slow. Yet sometimes driving conditions such as mud or sand create a “viscous cycle” where it becomes vitally important to maintain a minimum threshold speed, otherwise you get stuck in a rut and can’t get out of it.
Heavyweight configuration management environments that make developers wait non-negligible periods of time for things like check-out-authorization, presenting and approving all files to be modified prior to coding, protracted build-and-test cycles, waiting for a new baseline to be promoted for use, etc. are considered detrimental to the health of an agile development environment.
To solve the real problem consider what your goals are. If you want an Active Development Line, you want a codeline that is in good shape most of the time, but rapidly evolving. A codeline that never changes will always be safe, but you are not adding much business value.
The SCM Pattern Language shows you one way to resolve these issues. Figure 3 shows the relevant patterns. You create an Active Development Line by having developers work in a Private Workspace. Before anyone checks code in to the codeline, developers must do a Private System Build and run a Smoke Test. The Smoke Test should quick to run, even if it is not comprehensive.
At this point you are probably asking yourself how it is possible that a less than comprehensive test can give you any sort of stability. This only works because developers will be running more comprehensive Unit Tests while they are doing coding, and you also have an Integration Build process that runs a full suite of Unit Tests and a Regression Test. You are making the decision that delayed integration will cause more problems than a slight chance of a build problem. And the integration build and test process ensures that when a problem slips through, you will catch it quickly.
In many cases, the full suite of Unit Tests may be quick enough to run so that developers can, in fact, run comprehensive tests before check-in, but if the comprehensive testing starts to take long enough that developers defer integration, you should consider a simpler pre-check-in test suite.
Figure 3: Supporting an Active Development Line
Agile, Lean, and Other Cliché’s
The SCM Patterns support a development environment that adapts to change. Most all development environments are ones where change and uncertainty is the rule. There are two adjectives that describe approaches to development that are focused on change: Agile and Lean. Let’s spend a few minutes reviewing the concepts.