Change used to be viewed, experienced and managed as a discontinuous phenomenon. A period of change was typically followed by a period of stability. Moreover, the general expectation was that the period of stability would last a much longer time than the time it took to assimilate change.
Change nowadays is becoming continuous. Various Cutter Consortium clients deploy code dozens of times a day. Companies like Wisemarkit enable you to “open a shop in 60 seconds and fill it with products you believe in.” When new features are deployed every hour and e-shops can be formed on the fly, periods of stability in which you can catch your breath have for most practical purposes vanished. Whether you are a student in your dorm dreaming up a start-up, or the CEO of an established $1B company, you experience the new modality of change. Moreover, you typically experience it under conditions in which symmetry of ignorance prevail, making prompt response to change tricky unless you had already designed your systems to cope with this systemic form of ignorance.
My counsel over the past couple of years to Cutter clients who wrestle with change being so fast that it becomes disruptive, has been to cope with change through merging “strands” at multiple phases. The approach is illustrated in Figure 1. In Agile you merge development and test so that test can start before development is complete and test informs development through tight feedback loops. The net effect is faster/earlier delivery of better software. You can do the same to merge strategy and delivery during planning. For this phase, the effect of merging the strands is faster/earlier delivery of better services. Last but not the least, you can adopt the same approach for ideation, merging the problem strand with the solution strand, thereby delivering faster/earlier learning.
Figure 1: Coping with Change through Merging Strands
One of the methods by which the merging of the two strands can be done during execution is through Test-Driven Development (TDD). You not “only” merge the development strand with the test strand. You actually take a seemingly counter-intuitive approach starting with definition of tests to be performed before you even start development. Working in this manner, most times the quality of the software you deliver is much improved.
You can “TDD” beyond the software development phase by adopting the ‘test first’ approach for the other two phases illustrated in Figure 1, thereby making your whole business test-driven. For ideation, you drive the definition of the problem to be solved through first articulating the criteria the solution needs to satisfy. For planning, you start by formulating the delivery criteria that your strategy will need to meet. In each phase, you bring reality faster to the iterative process through starting from the “end.” Whether you are focused on ideation, execution or planning, the fundamental effect is earlier learning of the various kinds of realities you business must take into account. In today’s ever-changing environment, such test-driven business learning is your only sustainable competitive advantage.
When change is constant, it affects all facets of your company. Quite often these effects are not visible, and their impact is tricky to assess. The only way to cope with such change is by ruthlessly testing your business hypotheses. Test-Driven Business as described in this blog post enables you to do so. It subjects your business design and its execution to the kind of rigor that Test-Driven Development applies to software development. You could metaphorically think of Test-Driven Business as equipping your business with a test harness.
 The phases illustrated in Figure 1 should not necessarily be interpreted as sequential. One could argue that Planning should precede Ideation or that Planning should precede Execution. IMHO, the three phases could actually be sequenced in various ways, depending on the level of the idea under consideration, the role serendipity plays in your value web and your corporate culture. As I will point out in a forthcoming post on the subject, constancy of change actually blurs phasing. Also relevant to the question of sequencing is Mintzberg’s discussion of the ten schools of strategy formation in Rise and Fall of Strategic Planning.
 One of the intriguing aspects of test harnesses in software development is automated testing. I don’t know at this point in time to what extent the testing of business hypotheses could be automated (as distinct from manually collecting and analyzing the data to test the hypotheses).