cLabs: SellingAgile

I've recently been sucked into Clarke Ching's TOC and Selling Agile mailing lists, and on the TOC they were throwing around some sort of conflict cloud diagram, and trying to apply it to software development. I came up with the following, and while it didn't elicit much response (as basically I was late in the game and going a new direction from the get-go), I really like it. To me, it captures a core conflict in many a software business.

             Experiment to discover what we can do
       Build something new 
Earn money
       Promise work to customer
             Know what we can do

If I come back to this later, I'll try a more proper diagram, but basically you read it this way:

In order to earn money, we must promise work to the customer.
In order to earn money, we must build something new.
In order to promise work, we must know what we can do.
In order to build something new, we must experiment to discover what we
can do.

... and the two ‘wings’ in the diagram are the conflict. (TOC then has a bunch of techniques to flesh this out into other diagrams to help further analyze the situation.)

At the time I posted this to the list, here was my off-the-cuff analysis:

The obvious solution is we need to re-train our sales teams to be
selling investments in an experimental R&D effort, not a specific known
entity, not at least until we have a specific known entity.

I reckon doing that is a lot harder than just saying it, esp. with the small amount of experience I have on that side of Corporateville. But ... I am curious to know if that couldn't alleviate some stressful situations that contribute to a development team making rushed (and therefore poor) design decisions.

tags: ComputersAndTechnology AgileDevelopment