Test-Driven Business

 Posted by on Jul 9, 2012  Add comments
Jul 092012

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[1].

                        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[2].


[1] 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.

[2] 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).


  16 Responses to “Test-Driven Business”

  1. Interesting post, Israel – in the startup world the Lean Startup approach seems to be tackling product and customer development from a TDD perspective, but it’s very challenging for established firms to adapt this to existing strategy and planning processes.

    • avatar

      Thanks for kind words, Seb!

      What I see more and more in my practices is that large enterprises seek to start Lean Startup type initiatives. Some folks create a “startup” by physically locating a select team elsewhere. Others opt to establish different modus operandi and modus vivendi for such teams without physically separating them from the “mother ship.” Whichever way you go, the critical parameter is how you merge back the “startup.” This, IMHO, is the point in which you either make it or break it.

      I plan to publish a series of follow-on posts on various aspects of Test_Driven Business, including the good point you bring up. Stay tuned…


      • avatar

        This is a great post. I agree with your observation that large enterprises seek to start Lean Startup type initiatives. I am managing an initiative like that right now. I started with incubation of an idea that is leading to product with an objective of business incubation (with revenue stream).

        We are very agile and iterative. We are exposing solution to trusted partners ( even before MVP) to test the ideas and are using information to refine the strategy and delivery. I believe that after few iterations of this flow, I have a higher chance of incubating a business than with non-iterative plan. I didn’t think about TDB ( test driven business), but after reading your articles, I am realizing that we are operating in that mode. I do promote Collaboration culture which is automatically leading to {Ideation –> Planning} sequence.

        looking forward to more on this subject.

        • avatar

          Thanks for the kind words, Iqbal.

          From everything I glean, The Lean Startup is the next step in the evolution of Agile, sort of bringing the tenets of Agile to their logical conclusion. I think this is particularly appropriate to our era: for most practical purposes change in no more discontinuous. Rather, it has become constant. If you accept this premise, on-going learning is the source of competitive advantage. Hence, The Lean Startup. Not “only” as a startup, but as a modus for large corporations.


  2. avatar

    Good one, Israel. TDD takes a bit of a mind-shift to get used to, but once you do, it’s quite powerful.

    A couple of key related things I like to remind people of as they shift to test-driven development (and business):

    1. Focus on delivering to real people who are buying and using your product.

    2. Keep your iterations short.

    3. Remember to bias towards Minimum Viable Product and away from Big Design Up Front.

    • avatar

      Thanks for the kind words, Pete!

      The overarching idea is that software to development is like hypothesis to the business. We test in development in order to make certain that a software module works correctly. Likewise, we test a hypothesis in the business in order to validate it. If you accept this premise, the rest naturally follows.

      The foci you highlight for development (through TDD) are right on. The question on my mind is what are the corresponding practices for Test-Driven Business?


  3. Nicely stated; I have seen, for medium to large teams, the cost of testing, finding and resolving defects downstream (even prior to product release) is quite expensive. A process built around the notion of “how will I test this design?” no doubt will save countless hours of non-value added time.

    • avatar

      Thanks, Ron!

      The classical theory of the economics of software engineering holds that a bug in the field is 100X as expensive to find and fix as a bug in the development lab. I am quite willing to accept that Agile software methods, which merge development and test, have improved the classical results to some degree. Hence, for the purposes of this post we can make the assumption that finding and fixing a bug in the field is “only” 10X as expensive as doing so prior to releasing the code.

      If we accept the premise that software to development is like hypothesis to the business, it could be conjectured that the cost of finding and fixing a “bug” in a business hypothesis is 10X higher downstream than it would have been to fix it at the point in which we validate our business design.

      Scary that a “10X” factor might be under the best of circumstances, I think it is compounded by change being constant these days. Hence, a business hypothesis that was validated last month might not hold this month, or next month or next year. My next post on the subject of Test-Driven Business will address this critical aspect of “continuous validation.”


  4. […] Test-Driven Business Written by: Israel Gat […]

  5. avatar

    You’re bang on. It’s like we’ve come full-circle to the inverse of the concepts in New Industrial State.
    As cycles get tighter, we’re moving to continuous integration, and continual release. If I understand correctly, individual tactics would be developed as business user stories with acceptance criteria. Then in a continuous release environment, as the features push, you’d be able to verify if the hypothesis “passes” the business test almost instantly (at least in many environments).

    I think in this case, we’d end up with a very granular backlog of basically three levels of priority:
    1- This week
    2- Next week
    3- Everything else

    Now do we have to wean the organization from long-term planning? And is that the biggest challenge?

    • avatar

      I would actually go one step further, David. We are de facto decoupling the cadence of development from that of deployment. If you accept this premise, the implications are far reaching. For most practical purposes organizations were forced to align their overall process and activities to the cadence of development. Marketing, sales, professional services, customer support, etc. were traditionally planned in accord with the release date. This is no more the case.

      My counsel to Cutter clients is to be very flexible in their long-range planning, but quite persistent on the vision. As the long-range plan becomes more and more flexible, a crisp vision becomes critical to making intelligent decisions in the course of the Agile process. Initiative and creativity at the team level lead to emergence of a whole which is bigger than the sum of the parts only if they are guided by a crystal clear vision.


  6. avatar

    Hi Israel:

    Very good article. Though the concept of lean start-ups work well for small to mid sized companies, I have not seen it work successfully for larger enterprises. I am not against the lean startup for enterprises approach but the challenges are unique which a startup/mid-sized companies do not have to go through. IMHO, these are some of the challenges

    1. Process takes precedence over people. This is a cultural issue and culture flows from top-down and only changes slowly.

    2. often have a procurement department through which all procurements occur. Process again, but there has to be some ingenious way to simplify this. Add Master Contracts/Agreements to this and it definitely reduces the organization’s agility.

    3. Lack a proper lean/agile portfolio prioritization process, and the ability to adapt their portfolio based on customer discovery/product market fitment.

    What other challenges do you think enterprises need to address to operate as lean start-ups?

    • avatar

      Large corporation do not necessarily operate as lean startups. However, various corporations that I work with initiate a Lean Startup type teams within the bigger corporate startup. Sometimes such team is formed in a special off premises mini-site; sometimes such a team stays on premises but does not need to follow regular corporate processes. Either case, the team is measured on learning, and thence turning learning to earnings.

      The “trick” is bringing back the team to the “mother ship” in the right time. In many ways it is like M&A – you want to pay special attention to re-assimilating the team in the mainstream process and culture.


    • avatar


      I agree with your assessment, however I believe it is starting to change, even in the larger org’s. In organizations where Product can get to a fairly monolithic portfolio backlog, and where teams can get to tightened release cycles (with continuous release being the goal), then those results tend to gain the attention/acceptance of the organizational leadership.

      From there, if the team has enough critical mass, it can begin to “infect” the rest of the organization. I think that’s the “trick” that Israel is referring to. Clearly it requires leadership, but aside from permission at the top, in my experience the real leadership comes from product, program, and engineering leads.

      • avatar

        Could not agree more, David. The Lean Startup approach is penetrating corporate America. It might not have crossed the chasm yet, but it will.

        My own view of assimilation (of any real new thing, not “just” The Lean Startup), is that it is a combination of top-down and bottom-up. Whether the mix will be 20/80, 50/50 or 80/20 is something I can’t usually predict. But, I am skeptical about the prospect of success if an “ingredient” of the mix, be it the top-down or the bottom-up, is lower than 20%.


      • avatar

        Also relevant is the TechCrunch article “How Big Companies are Becoming Entrepreneuriall” http://tcrn.ch/PeCoyt.


 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>