Thursday, 16 April 2009

Fartlek development

The amusingly named Fartlek training is a form of athletic training in which high intensity work and low intensity work are alternated in the course of each training session. The two forms of work are complimentary in that they stress the you in different ways (anaerobic and aerobically) and allow you a chance to recover.

I think that this is a good model for software development in software start-ups.

Priority one: Build something that people want, fast

The main risk in a software start-up is making something that people don't want. So you want to find out whether your initial idea has merit, fast. So -- if at all possible -- you build a small prototype, and test it out in the marketplace, fast.

In order to satisfy the need for speed, you cut a few corners, and because it's small (and your team is good) you can get away with this approach (for now).

If no-one wants your prototype, you scrap it, and you haven't wasted time on lots of process that was supposed to pay off in the long-run (because there is no long-run).

On the other hand, if it the prototype is promising, you will learn from the market feedback how to make it better, and it will start to grow. This is where it is critical to switch gears and slow down (at least for a while). Because if you do not, you will find yourself in the realm of cowboy development, the bugs will start to bite, and the pace of development will drop as your team gradually spends more and more time debugging, less time developing, resulting in a drop of confidence -- "I don't want to quickly make this change because it might break something" -- and loss of tempo.

Priority two: Restore quality (and sanity)

The alternative is to switch modes. Fred Brooks said "build one to throw away", but at a minimum you should review what has been done to date and investigate and prioritize the very real risks of continuing with a prototype. These might well include:
  1. Customer or prospective customer loses data or has it corrupted
  2. Customer or prospective customer experiences bugs, crashes, or loss of service
  3. A crash or a bug during a demo
  4. The software does not scale, so performance degrades over time
  5. Development slows so that critical new features can not be delivered in a timely fashion
Improving the quality of the software process is what is needed for most of these, and many of the kinds of measures that help have largely been formalized in the Agile development processes:
  • Pair programming: Two heads are better than one, plus it offers real time code reviews, mentoring, camaraderie and friendly competition, less web-surfing
  • Test-driven development: Writing automated tests clarifies the design and as they build up offer an early warning system when a change breaks something unexpectedly (Design by Contract gives similar benefits)
  • Continuous integration: Frequently "checking-in" and automatically running the automated test-suite identifies incompatible changes made by different programmers or pairs sooner rather than later; saves you from merge hell
  • Refactoring: By reviewing code, eliminating duplication, reducing coupling, and improving the use of abstraction, your software base will become more concise, readable and maintainable
  • Short iterations / planning game: By maintaining a list of feature requests and bug-fixes that the developers estimate and the internal customer prioritizes (within a budget based on the amount of work accomplished in the previous iteration), a sustainable rhythm is established, and healthy prioritization is forced
  • Sustainable pace: Working more than an eight hour day / forty-hour week leads rapidly to damaging the code base, loss of morale, and bull sessions as people are present in body, but not in spirit -- avoid the "Death march" scenario
Additionally, a design review will be needed to knock the existing architecture and code into shape, and tests will needed to be added retrospectively if you didn't practice test-driven development in the initial prototype phase.

For a web-based service additional infrastructural elements and diagnostics should be reviewed and added.

All of this is manageable as long as the prototype is small, but the longer these steps are delayed, the greater the costs that must be paid. It's a lot like going into debt. You not only have to repay the loan, but also the accumulated interest. Some people call this design debt. (And the interest rates on design debt tend to be high.)

And then the cycle turns

While making incremental changes continued agile iterations is probably the way to go, slow and steady (but not slowing down). When the time comes to make a leap forward, knocking up a quick prototype is a great way to vary the routine, and makes business sense.

Almost everyone who learns to program first experiences the joys of "cowboy development" on small personal projects, but when they "turn pro" or start working on larger projects they soon learn that it doesn't scale beyond what you can easily hold in your head.

Some people think that up-front design and analysis will save the day, but this leads to waterfall with its 1/3 design, 1/3 development, 1/3 testing rule-of-thumb when done well. But then you discover that the requirements were wrong (they always are), and another long iteration is required.

Smart people rediscover short iterations, and lately these have been articulated as Agile Methods, and also include other ways to make the computer (e.g. automated tests) and human nature (e.g. pair programming) work effectively and more satisfactorily. The cost is a bit of deferred gratification by having to do some things up front (e.g. writing tests, refactoring) that pay off over time.

However, it would be wrong to say that an Agile approach is the best for everything, at every scale. In particular, in knocking up a quick prototype one may well be justified in reverting to some of the cowboy practices for a short period. Note that it is not compulsory to drop all the agile practices when doing so -- do what suits the situation.

The tricky bits are:
  1. Not leaving it too long
  2. Paying off the accumulated technical debt
  3. Getting back into the discipline of following the practices
  4. Combating the likely organizational pressure to continue at the previous pace!
So good luck with the fartlek development*, and let me know what you think.

*My esteemed colleague -- and former Olympian -- Ben Loft points out that interval training may offer a better analogy, but the name isn't as memorable.

Sunday, 12 April 2009

Provocation-based Selling (and Provocative Writing)

Who doesn't love a controversy?  Want to get noticed?  Provoke!  Capture attention!

The trick is to follow up with something that hits the spot lest you alienate your suddenly alert audience.

One way to provoke attention is to insult a big-name.  In a recent article in the Harvard Business Review -- In a Downturn, Provoke Your Customers -- the authors (including Geoffrey "Crossing the Chasm" Moore) slam the generic notions of consultative selling and especially solution selling (as opposed to the more specific Consultative Selling and Solution Selling®) either through ignorance or in a straightforward grab for attention.

The only problem -- as Keith Eades, CEO of SPI correctly points out --  is that they have done so to a large extent by over-simplifying Solution Selling,  and  then  comparing their "new" approach to a whittled down husk: 
Whereas solution-selling salespeople listen for “pain points” that the customer can clearly articulate, provocation works best when it outlines a problem that the customer is experiencing but has not yet put a name to. -- from the article
But Solutions Selling has a powerful way to think about where your customer is at, before getting into "pain points":  Levels of Need*
  1. Latent need: Unaware of a need that could be satisfied by purchase (perhaps they are unaware that there's a problem, or in denial, or resigned to coping with the status quo)
  2. In pain: Aware of the need ("in pain"), but unaware of how your offering can help
  3. Vision creation: The prospect has a vision or a "Solution", ideally including your offering. 
A key part of Solutions Selling is to move the customer upward through these Levels of Need.  The article mis-characterizes Solution Selling as simply asking the prospect about their pain (i.e. jumping in at level 2 - In pain), while correctly pointing out that during a downturn many more people will tend to be at level 1 because they are doing their best to make-do with much-reduced budgets and discretionary funds.

A key part of "provocation-based selling" seems to be to provoke a response by forcefully articulating a problem that the customer has, get them to acknowledge it, and then make a bee-line to the person who has the authority to do something about it (and who can release funds to purchase).

This is all good Solution Selling, just in slightly different terms.  In classic Solution Selling one would first try to stimulate the interest of a contact with a Reference Story, typically describing a person in a similar situation to their current one and how you were able to help that person.  Hopefully the contact will respond by either confirming that (s)he has similar issues, or -- equally good -- say something like, "No, we don't have those problems.  This is what's really bugging me ...".  Either way, you are engaging and on your way to level 2.  While exploring the prospect's pain, you should also be finding out who else is affected (i.e. who else you need to speak to get a fuller organizational picture of the pains, and also who can authorize a sale), etc.   [I have a fuller summary of Solution Selling here.]

The authors of the HBR article have a good point to make: That during a downturn a forceful -- or provocative -- approach may be a good way to jolt prospects into thinking about what can be done to improve their business, including alerting them to problems that they may be reluctant to address.  They suggest a mixture of fear -- "if you don't do something you're doomed" -- and hope -- "but we can help you get through this".  This seems like a good approach, provided you have accurate information, and can pull it off without alienating your prospect by coming across as arrogant: "I know your problems better than you"!

So "props" to the authors of In a Downturn, ... for being provocative, and thereby garnering some attention for the important issue of jolting people out of latency during a downturn.

My guess is that the authors feigned ignorance of Solution Selling etc. to whip up controversy, and that's probably a good thing!

* Austhink's add-on to SalesForce crm -- bSelling Opportunity Management -- augments SalesForce's contact information (which is a bit more Miller-Heiman-esque out-of-the-box) with a Level of Need field.  Naturally, we also do pain points!

Tuesday, 7 April 2009

To Customize is Cool

It's cool to customize! It practically has the word "customer" in it, so what's not to love?

Seriously: When prospective customers see the Qualify tool -- part of Austhink's bSelling add-on to Salesforce crm ...

they say two things:
  1. Wow!
  2. Can I customize it?
The "Wow!" reaction is because here is a tool that really helps the salesperson with a vital but difficult task -- sales qualification -- in a fun way. It provides useful feedback -- an overall percentage, and sensible concrete ways to boost the score. Ok: Most of the wow is because of the fun factor and groovy way it plays (like flipping through photos on a Mac).

The second reaction -- the wish for customization -- is natural. Although at Austhink we believe that the out-of-the-box system is quite generic, sales teams do of course vary in their terminology, types of customers, and overall slant sales.

So, I recommend a suck it before you salt it approach:
  1. Try out the generic version (that comes with the free version of bSelling) on a few opportunities to get the feel for the process. Just pick a neutral "card" if a factor doesn't seem to apply.
  2. Make notes about where the terminology needs revision, which "factors" don't apply, and which (if any) are missing.
  3. Upgrade to the premium version of bSelling and make use of our soon-to-be-released customize feature.
  4. If you need extra help, we can arrange consultation!
The customize feature allows your company to change the wording, options, factors, and weightings -- i.e. everything -- of the Qualify tool to tailor it to fit your unique situation. Just like the tool itself, it looks great, is fun-to-use and it has a game-like feel. Here's a sneak peak:

Each line represents a deck of cards in the tool, and each block represents a single card. The length of each line represents the weight of each factor. You just click on a box to edit some wording (shown), or click on an end box to stretch or squash a line (to make a factor more or less important compared to the others). Other operations are similarly simple.

By the way: If you think of the Qualify tool as a level in a game, the customization tool is like the level-designer that allows an obsessed user to design new game levels for their friends to play. In this case, the customization tool allows the sales-manager to tweak (or totally revamp) the qualification process to fit local conditions, and better monitor (and mentor) the sales team.

We are about to trial the customization tool with a select group of beta-testers -- email me at if you want to give it a whirl -- and the first version should be available in the next week or so.

Friday, 3 April 2009

From Moses to Moses ...

"From Moses to Moses there was none like Moses". The two Moses's of the quote are Moses the lawgiver -- he 0f the 10 commandments etc. -- and Moses Maimonedes the greatest Jewish sage of the middle ages.

Loyal readers of this blog will remember that last year my son Jake portrayed the earlier Moses in the kindergarten Pesach (Passover) play:
Jake as Moses

Witnesses said that his manner and physical resemblance to the biblical Moses was uncanny, and it seemed it would be a long time before anyone would else would pull off such a convincing portrayal ...

That was until Jake's little sister Ella put on the beard!

Ella as Moses

Apparently Ella was a little more tentative in her portrayal than Jake had been, but she is a year younger than he was when he took on the role.

Nevertheless, I am again very proud indeed. (And amused.)