The Agile Executive

Making Agile Work

Posts Tagged ‘Disruption

Only 10%

leave a comment »

Readers of the posts Customer Intimacy and Enterprise Software Innovator’s Dilemma might recall two observations made in this blog:

  • The dissatisfactory state of affairs in enterprise software as characterized by Crawford and Mathews in their description of Consumer Underworld relationship between vendor and customer:

Ignore my needs… Be inconsistent, unclear, or  misleading in your pricing… Offer me poor quality merchandise and services that I can’t use… Give me a reason to tell my friends and relatives to stay away…

Open Source Software is becoming ”good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By  so doing, Open Source Software will steadily gain ground from traditional enterprise software vendors

In a Viewpoint published in the July 2 issue of BusinessWeek,  former Harvard Business School professor Shoshana Zuboff cites the following statistics:

…  only 10% of Americans now saying they trust large corporations, according to the Apr. 8 edition of the Financial Trust Index. Some 77% of Americans say they refuse to buy products or services from a company they distrust, according to the 2009 Edelman Trust Barometer. [Highlights by IG].

The statistics given by Zuboff link the two observations cited above. One might argue that Crawford, Mathews and Zuboff deal primarily with consumer behavior, not with procurement of enterprise software. True that this argument might be, I sincerely doubt that the two worlds can be kept apart. At least some of  the folks who license and use enterprise software must be represented in the data given by Zuboff and are likely to act accordingly in their corporate roles. Moreover, her statistics seem to be quite consistent with the recent warning to high-tech issued by Christensen:

If you’re curious to know what lies in store for Seattle and Silicon Valley, spend a day walking around Detroit with the Ghost of Christmas Future.

Advertisements

Confluence

with 3 comments

The approach Eric Ries advocates for the Agile start-up has been covered in previous posts (click here and here). Basically, Ries sees the need to iterate on the customer problem alongside iterating on the solution to the problem. Furthermore, a process of discovery – finding the customer – accompanies iterations on the problem and on the solution.

In a note today entitled Three Designing Bears, Kent Beck brings up a great example for the approach Ries promotes:

[JUnit] Max is a bootstrapped product, so I need to find revenue as quickly as possible. I have no idea what people might actually pay for in a testing tool, so I need to try things as quickly as possible. Features only need to be finished enough to give me reliable feedback about their value. Will people pay for features like those? If so, I can afford to finish them later.

Various other threads are quite relevant to and consistent with the ideas of Ries and Beck. For example, commenting on Flickr in The Art of Agile Development, James Shore highlights their speedy {code –> test –> stage –> deploy} cycle:

When a user posts a bug to the forum, the team can often fix the problem and deploy the new code to the live site within minutes.

When coupled with “real time” user feedback, the confluence of speedy development with fast deployment reduces the risk of developing features that are never or seldom used. It applies to both start-ups and established enterprises. It opens the door for new software business designs that would have been considered infeasible just a few years ago. For example, one could enhance the Marauder Strategy (“seek out slow ships and take them out”) proposed by Jeff Sutherland by competing not “only” on velocity of development, but on accelerated deployment cycles and ultra-fast feedback loops.

Written by israelgat

May 6, 2009 at 10:26 pm

Punching Above Your Weight Class

leave a comment »

Authors Hagel, Brown and Davison use an interesting metaphor in a recent Harvard Business Review article on strategy in time of constant change:

Today’s new Digital infrastructure in fact gives relatively small actions and investments an impact disproportionate to their size. To use a boxing metaphor, companies can now punch above their weight class.

Compare the Digital infrastructure with traditional infrastructures such as water canals, railroads or highways. Unlike these classical means of communication and transportation, Software is unique in being integral part of the Digital infrastructure as well as being a major piece of what gets transported over the  infrastructure.  Best I know no other entity ever played such a dual role in as meaningful a manner.

The metaphorical punch Hagel, Brown and Davison use as an illustration for the leverage provided by the Digital infrastructure is particularly intriguing due to to the malleability of software. Delivery methods for products and services over the Digital infrastructure could evolve the way product feature and functions do. If the product continues to evolve after initial delivery, the opportunity presents itself to do Agile in the deep sense recently proposed in The Lean Startup: iterative customer development alongside Agile product development that includes iterating on the delivery method.

Written by israelgat

April 21, 2009 at 8:40 pm

Marauder Strategy for Agile Companies

with one comment

Colleague Annie Shum sent me the URL to a recent post by Clayton Christensen in The Huffington Post. In this post Christensen characterizes “disruption” in the following manner:

Disruption is the causal mechanism behind the “creative destruction” that [economist Joseph] Schumpeter saw so pervasively at work in capitalist economies. [Links added by IG]

Christensen’s post is largely about the automobile industry. It, however, ties nicely to an email exchange Jeff Sutherland and I had about Agile as a disruption inside the company vis-a-vis its intentional use as a disruptive methodology in the market. To quote Jeff:

We are starting to see organizations like yours that can use Scrum to disrupt a market. There is a tremendous amount of low hanging fruit out there. Dysfunctional companies that can’t deliver. I’ve been recommending a “Marauder” strategy to the venture group. Find a company who has a large amount of resources. Set them loose like pirates on the ocean and they seek out slow ships and take them out.

Carlota Perez, who has been often cited in this blog (click here, here and here), is a disciple of Schumpeter. I really like the way the “dots” are connected: Schumpeter –> Perez –> Christensen –> Schumpeter. Their theories of disruption and constructive destruction express themselves nicely in the business design proposed by Jeff.

The Use of Agile Methods by the Entrepreneur

with 2 comments

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.

Written by israelgat

March 3, 2009 at 10:55 pm

Why Agile Matters

with 9 comments

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:

  1. A major technological innovation introduces a new infrastructure
  2. The new infrastructure disrupts both industry and commerce (and very possibly society)
  3. Overtime, the new technology gets to be understood; it then gets harnessed
  4. 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
  5. 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:

slide1

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:

  1. Clearly perceived low – and descending – relative cost
  2. Unlimited supply for all practical purposes
  3. Potential all-pervasiveness
  4. 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.

The First Decision to Make

leave a comment »

The Choosing Between Two Disruptions post highlighted the fundamental predicament one faces with respect to large scale Agile deployment – Is an in-house Agile disruption initiated by you preferable to a market disruption through Agile which you will need to react to? I trust you will decide to give Agile a try even if you are concerned about a possible in-house disruption. This being the case, you will need to make numerous decisions about the way you will roll Agile. This posts deals with the very first decision to make with respect to so doing: Choosing the Agile learning paradigm which will be most effective in your company.

Learning and Thinking

Years ago, when I was a student at the Israel Institute of Technology (Technion), we had a quip about the learning paradigm: “In the second year you understand what you were taught in the first year; in the third year you get what you learned in the second year”. The quip captured the essence of the de facto learning paradigm that largely prevailed at the Technion back then. The Technion probably aspired for a very different learning paradigm, but circumstances in Israel during these years dictated a different pattern. As many of us were called to reserve army service for 30-60-90 days a year, we did not usually have enough time on our hands to think deeply about what we were studying. We absorbed a lot of information quickly in a somewhat mechanical way. Only over an extended period of time were we able to generate sufficient cycles to think deeply about what we were taught. This later thinking eventually led to understanding. We assimilated the curriculum with an average one year lag.

How will your Company Learn?

Business realities these days might force you to introduce Agile in a “Technion style” manner – you introduce Agile as a recipe. You do your best, of course, to explain the deeper thinking behind Agile, but you focus on the “How?” You bet the Agile roll-out on getting results through applying Agile practices. Once you have a couple of Agile success stories under your belt, people will naturally get curious about the underlying principles. They will rediscover them, assimilate them and propagate them.

The other way to go is to start with the deeper truths – software engineering laws, anomalies and trends that over the years led to the rise of Agile. You start with the “Why?”, bootstrapping your way towards the “How?”

The Reengineering Alternative

William E. Schneider’s book The Reengineering Alternative is a must read prior to making the decision how your company will learn Agile.

Schneider characterizes four core organizational cultures and provides the tools to self-determine your corporate culture and to assess the strengths and weaknesses that go with it. Each of the four core cultures – Control, Collaboration, Competence, Cultivation – has its own characteristic response to change. Choosing the learning paradigm best suited to your company is largely a matter of cultural fit.

For example, according to Schneider, the Control culture mandates change. Hence the “Technion style” approach discussed above could be quite appropriate if your company is of the Control ilk.

Time for Thinking

Reducing the pressure on a software team to the point at which thinking can be done in parallel with coding and testing is of immense value. Higher levels of quality and innovation are visible pretty quickly. Longer term, code adaptability and the ability to evolve the code pay off big dividends. These benefits are particularly important for teams who incorporate bleeding edge technologies in their product. You must have the time to think about such technologies and how to utilize them.

The pain of having an Agile project team gated on the availability of some feature from a Waterfall team can be significant. Painful though it may be, such a situation could actually be seen as a blessing in disguise. The team members have time to think. And, they have the time to refactor their code.

The Agile Leader

In addition to helping you make your first decision with respect to the Agile roll-out, Schneider’s book will give you a precious clue as to your role as an Agile leader:

A leader’s effectiveness can be measured by the degree the leader’s approach is integrated with the organization’s core culture.

A fascinating aspect of this sound advice is the culture within a culture situation. As Agile tends to create its own culture, the Agile leader often needs to align the Agile culture with a broader corporate culture. To succeed, the Agile leader needs to create such an alignment while protecting the Agile culture. Various means for so doing are described in the presentation Leading from Within.

Written by israelgat

January 19, 2009 at 4:14 pm