Send As SMS

Thursday, November 02, 2006

Test-driven programming, extrapolated

Many agile methodologies offer test-driven programming (write the unit tests first, then write the code), the premise being that [adequate] tests largely define what the code should achieve and that several things go better if what an artefact is supposed to achieve is [somewhat] defined before that artefact is created (I'm simplifying, obviously).

Well, what if we took this thinking a little further:
  • What we are to test should at some level be a consequence of how the user(s) will use the software. Perhaps we should write the user manual before we write the tests.
  • What the user manual documents will need to be what the user will experience in using the software; even though we're writing the user manual rather early, we'll still need some screen mockups, workflows, key use cases, etc. created first.
OK, so far this is not so counter-intuitive for a developer accustomed to working agile, except that I've moved the user-manual forward somewhat. What if we went one step further?
  • The user manual describes the user experience that the organisation will be aiming to sell / promote to customers / users. Perhaps before we describe the user experience that we are aiming to sell / promote, we should produce the marketing communication materials (press releases, brochures, ...) that we'll actually be using for that selling and promoting.
Crazy you think? Amazon doesn't.
Once we have gone through the process of creating the press release, faq, mockups, and user manuals, it is amazing how much clearer it is what you are planning to build. We'll have a suite of documents that we can use to explain the new product to other teams within Amazon. We know at that point that the whole team has a shared vision on what product we are going the build.
Even this is not far from typical practice; the key features of a new release are typically agreed across all involved teams very early in the process. However, producing something as concrete as a press release and the supporting marcom material not only provides a crystal clear vision but also (a) allows scope creep to be stamped out fast and (b) forces important [customer-visible] items that come up during development to be stated where all can see it on an "it'll be stamped out otherwise" basis.

I like it.