Jul 112012
 

In my recent blog post Test-Driven Business, I started to examine the application of Test-Driven Development techniques to the business.  The general idea is that software to development is like hypothesis to the business. We test in development in order to make certain that the software works correctly. Likewise, we test a hypothesis in the business in order to validate it. Just as we fix a line of code, we fix an invalid hypothesis.

The model proposed for Test-Driven Business includes two core elements:

  1. View of the flow of activities in the firm as comprising three distinct phases: Ideation, Execution and Planning.
  2. Two strands that we try to merge within each phase.

With these elements in mind, the ‘test first’ approach followed by proponents of Test-Driven Development can be applied to the Ideation and Planning phases. Figure 1 illustrates the concept: we start test before development, solution before problem, delivery before strategy.

                                      Figure 1: A Model for Test-Driven Business

One important aspect of the model is the order in which things get propagated from one phase to another. If you assume sequential order from left to right in Figure 1, the flow for this business is very pragmatic: it subjects ideas (through some form of execution) to the rigor of the market before developing a strategy around these ideas. This kind of flow is illustrated in Figure 2.

                               Figure 2: A Possible Flow in Test-Driven Business

One could legitimately challenge the sequencing in Figure 2, proposing the flow {Ideation –> Planning –> Execution}, as illustrated in Figure 3, is the “right” kind of flow. Likewise, another person could suggest {Planning –> Ideation–> Execution} as the way to go. Other permutations, of course, are feasible.

                               Figure 3: Another Possible Flow in Test-Driven Business

As indicated in my original post on the subject, the “right” order can change from one firm to another, depending largely on the level of the idea under examination, the role of serendipity in the firm’s value web and its culture. In fact, the specific order in which the three phases are arranged captures deeply held convictions about the firm’s recipe for success. A Control culture might insist on {Planning –> Ideation}. Conversely, a Collaboration culture might consider {Ideation –> Planning} the preferred sequence[i].

In addition to the order in which Ideation, Planning and Execution determine inter-phase flow in the firm, the relative speeds of the three phases are of great importance (and the reason for my illustrating them in this post as gears). If the relative speeds of the three gears are not harmonized, the system gets out of balance. Such out-of-balance conditions might go all the way down to metaphorical gear braking. In particular, a gear that happens to be in the middle is particularly brittle, as it could be subject to potentially opposing forces from the two adjacent gears. For example, a firm that is modeled after Figure 3 might encounter major problems with Planning: the planning process might not be able to meaningfully cope with idea generation; or, the planning horizon will be longer than the execution period mandated by the market; or both.

Using the model described herein, I plan to address the following topics in forthcoming posts on Test-Driven Business:

  • Classification of companies by inter- and intra-phase flows
  • Blurring of the lines between the three phases
  • Continuous validation
  • How the Test-Driven Business concept is related to Agile 2.0
  • Cost-of-delay strategies for the Test-Driven Business
  • How to implement Test-Driven Business in ‘real life’
  • How to scale the Test-Driven Business to meet the needs of large enterprises
  • Can technical debt techniques apply to assessing ‘business debt’?
  • How the Test-Driven Business concept is related to management theories such as Radical Management and Escape Velocity
  • Any relevant topics proposed by readers of this blog

You can think of the topics listed above as my Test-Driven Business research agenda for the coming few months. Stay tuned….


[i] I use Control and Collaboration here in the sense defined by William Schneider in The Reengineering Alternative.

Discussion

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)