Archive for March 2009
Customer Driven Testing
David Anderson, James Shore and I engaged in a Twitter dialog about the post Every Nine Minutes. Our exchange highlights the importance of balancing development, deployment and operations, as follows:
what concerns me about continuous deployment is it is developer centric. Deployment has a cost for the customer [DA]
Continuous deployment involves automating what must be done anyway. Unless you mean end customer, don’s see the costs you mean [JS]
yes end customer. not everyone wants the UI changing every 9 mins 😉 what about training? marketing? etc..? [DA]
I think that’s an issue that’s raised by, but independent of, continuous deployment, and quite manageable. [JS]
I want 2 c people talk about this holistically. If deploying more often is better then how do u reduce cost/impact on customer? [DA]
It seems to work quite well for their clientele. Their iterative customer development work might be the ‘secret sauce’ [IG]
is this an aspect of their tech enthusiast, early adopter market? [DA]
I think it is deeper – they adjust their testing to the needs of their market segment. Will blog on it later today. [IG]
The software IMVU produces is similar in some respects to what Clay Shirky calls Situated Software: “… designed for use by a specific social group, rather than for a generic set of users”. . . IMVU’s testing seems to be in good accord with the needs and priorities of their young users. Certain deficits in their software do not seem to be terribly important to their clientele. As pointed out by Elizabeth Hendrickson it might not be perfect but the software does the job for the target clientele and creates value.
The way IMVU develops the customer in an iterative manner (in parallel with iterating on the product) seems to be the key. Deep understanding of customer and problem determines testing strategy. Given their Lean Startup orientation, “good enough” testing seems to be quite appropriate for their business design:
- Product release cycle in hours, not years
- Tightly coupled with customer development
- Minimum feature set, maximum customer coverage
- Rapid hypothesis testing around market, pricing, customers,…
- Extremely low cost, low burn, tight focus
IMVU is an example of the approach advocated in Agile Considerations for CXOs: don’t harness Agile into a rigid business design; instead, develop a business design around the capabilities of Agile.
Every Nine Minutes
The post Every Thirty Minutes highlighted Flickr’s deployment frequency – literally every thirty minutes.
IMVU is reported to do so every nine minutes. The report has created a fair amount of controversy. Whether you are or are not in favor of such continuous deployment, one point is worthy of mention. IMVU is the very same company featured in The Lean Startup presentation. The way they do customer development has been discussed in our recent post Why Agile Matters.
Between what they do in iterative Customer Development and their work on Continuous Deployment IMVU is well worth paying attention to.
“More Than One Way to Roll-Out Agile”
Ryan posted part I of the debate between Erik Huddleston (Inovis), Jack Yang (Homeaway) and me on the subject of Agile roll-out strategies. The heart of the debate is team-by-team versus all-in. To paraphrase Robert Graves, the debate is true and the telling is frank. Highly recommended!
A Quip That Says It All
Readers of the post Can You Afford the Software You are Developing? might recall my grave concern about accruing technical debt. It is like debt on your credit card – you struggle to pay the interest; you rarely manage to pay back the principal.
Reading Esther Derby‘s article The Three Pillars of Executive Support for Agile Adoption, I noticed her independent “verdict” on the subject:
Technical debt is the harvest of cutting corners to meet unrealistic deadlines
I am inclined to think “technical debt” is actually a euphemism for “inadequate investment”
“Agility” in Action
Colleague Annie Shum sent me the cartoon above. Perhaps not quite the way we use “Agility” in this blog, but thought provoking nonetheless…
Is the Off-shoring Trend Turning Around?
Met a fellow Agilist in the gym this morning. He works for a major financial institute that recently carried out a round of cost cutting in IT. They chose to lay off off-shore, protecting on-shore software engineering resources.
I recently learned of a few other software/IT companies who followed a similar layoffs strategy. Is the off-shoring trend in software/IT starting to turn around?
Five Imperatives for End-to-End Agility
David Worthington, Steve Brodie, Brett Adam and I just finished part I of the End-to-End Agility webinar. The focus of the webinar is on ultra-fast development, test and deployment through:
- Agile methods
- Virtual labs (i.e. development/test environments “in the cloud”)
- Virtual appliances
Slides and recordings from the webinar should be available in 48 hours. Until then, I will just mention the five imperatives identified in this webinar for accomplishing End-to-End Agility:
- Self service
- Scalability
- Collaboration
- Control
- Automation
Part II of this webinar series will be delivered in early April. It will emphasize the effects of hyper-productive Agile teams on operations.
Reflections on The Use of Agile Methods by the Entrepreneur
Walter Bodwell has posted his reflections on The Use of Agile Methods by the Entrepreneur. To quote Walter’s summary:
It looked at agile from a different point of view than typically done.
See here for the full review of the presentation by Walter.
The Use of Agile Methods by the Entrepreneur
Sebastian Hassinger and I just finished delivering this presentation in Agile Austin. It is a ‘think-piece’. Comments on the presentation will be highly appreciated.
Why Agile Matters
Agile matters because it is a critical factor in the techno-economic process. In fact, it fits nicely in both the classical theory of techno-economic cycles, and the latest revisions to the theory. Whichever school of thought you might follow with respect to what the nature of the current macro-economic crisis is and what the implications for your company might be, Agile will serve you well.
Technological revolutions
In Technological Revolutions and Financial Capital, author Carlota Perez views technological revolutions as part of techno-economic cycles. According to Perez, techno-economic cycles are composed of a sequence of events that proceeds in the following way:
- A major technological innovation introduces a new infrastructure
- The new infrastructure disrupts both industry and commerce (and very possibly society)
- Overtime, the new technology gets to be understood; it then gets harnessed
- As the new technology gets harnessed, confidence in it grows and it gets used broadly. Consequently, in good time, the new infrastructure itself becomes a stabilizing force
- A new technological innovation disrupts the prevailing order and gives rise to start a new techno-economic cycle
Perez identifies five successive technological revolutions between the 1770s and the 2000s:
To summarize, Perez perceives that technological revolutions are subject to laws of cyclicality. The cardinal law in the cyclicality is that intertia eventually becomes the legacy of successfule innovation.
Has the techno-economic paradigm been disrupted?
In a recent Harvard Business Review article, authors Hagel, Brown and Davison suggest that we are witnessing a profound shift:
The historical pattern – disruption followed by stabilization – has itself been disrupted.
Hagel, Brown and Davison perceive an exponential pace in information and telecommunication. The exponential pace creates a new reality and a new order:
Because the underlying technologies are developing continuously and rapidly, there is no prospect for stabilization. Businesses and social institutions constantly find themselves racing to catch up with and learn the steadily improving foundational technologies… The core technology infrastructures that once formed the bedrock have turned into plasma.
Choosing between the two theories
The debate about which techno-economic paradigm – the Carlota Perez paradigm or the Hagel, Brown and Davison paradigm – is better suited for the current circumstances is beyond the scope of this blog. Be it as it might, Agile fits well with either paradigm, though in a different manner.
Agile as a low cost input
If you believe the classical techno-economic paradigm a la Perez continues to prevail, you need to think of software produced by hyperproductive Agile team as a low-cost input in the techno-economic system. If Agile is massively adopted, it will satisfy the four conditions stipulated by Perez for an input to be a key factor in the technological revolution:
- Clearly perceived low – and descending – relative cost
- Unlimited supply for all practical purposes
- Potential all-pervasiveness
- Capacity to reduce the cost of capital, labour and products as well as to change them
The potential implications of Agile software getting to satisfy these four conditions are far reaching. According to Perez, the current technological cycle started in 1971 with the introduction of the microprocessor by Intel. Hence, one might think of Agile software as a “mid-life kicker” to the current techno-economic cycle.
At the micro-economic level, the implications of Agile as a low-cost input for traditional enterprise software vendors are dire. As pointed out in the post Enterprise Software Innovator’s Dilemma, some low-cost input effects are already manifesting themselves through Open Source Software.
Agile as agile
If you subscribe to the “bedrock into plasma” paradigm advocated by Hagel, Brown and Davison, you need to view Agile from the point of view of, well, agility. Irrespective of whether your business strategy calls for adapting to the market or shaping it, speeding up the business, not “just” R&D, is absolutely of the essence. You need to apply the Agile principles to the way you develop your business and your customers.
The point in nicely illustrated in The Lean Startup presentation by Steve Blank and Eric Ries. The authors are emphatic in their recipe for success:
Winners are those that can move faster than their competition.
To move faster than the competition, Blank and Ries recommend applying Agile principles to customer development. In so doing, they extend Agile beyond the traditional starting point when the (customer) problem is supposed to be known but the (software) solution is unknown. They elevate the paying fields to the level in which customer development is done in parallel to product development. This kind of uninterrupted flow in the feedback loop between developer and end-user makes Agile extraordinarily powerful.
For further research
I encouraged you to consider the ramifications of the ideas presented above and to comment on them in this blog and elsewhere. Of the numerous avenues that we can explore in pursuing the boundaries of Agile, the following topics are particularly intriguing:
- Alan Fusfeld introduced the Technological Progress Function as a tool to quantify technological progress as function of time and scale. The opportunity exists to combine software metrices, the technological progress function, and the techno-economic paradigm in a unified model.
- As pointed out above, inertia eventually becomes the legacy of successful innovation. Conversely, one needs to overcome inertia in order to introduce successful innovation. Jim Highsmith‘s recommendation to innovate through experimentation a la Agile is very powerful at the project level. It is not fully clear how a similar approach could be facilitated at the policy level.
