The Agile Executive

Making Agile Work

Posts Tagged ‘BusinessWeek

Consumerization of Enterprise Software

with 7 comments

Source: http://www.flickr.com/photos/ross/3055802287/

Figure 1: Consumerization of IT

The devastation in traditional Publishing needs precious little mentioning. Just think about a brand like BusinessWeek selling for a meager cash offer in the $2 million to $5 million range, McGraw Hill getting into interactive text books through Inkling or Flipboard delivering “… your personalized social magazine” to your iPad. This devastation might not have gotten the attention that the plight of the ‘big three’ automobile manufacturers got, but in its own way it is as shocking as a visit to the abandoned properties in Detroit is.

As most of my clients do enterprise software, many of my discussions with them is about the consumerization of IT. From a day-to-day perspective this consumerization is primarily about six aspects:

  • Use of less expensive/consumer-focused components as infrastructure
  • ‘Pay as you go’ pricing (through Cloud pricing mechanisms/policies)
  • Use of web application interfaces to monitor IT infrastructure
  • Use of mobile and consumer based devices for accessing IT alerts and interfacing with systems
  • Use of the fast growing number of mobile applications to enhance productivity
  • Application of enterprise social networks and social software in the data center

From a strategic perspective, IT consumerization IMHO is all about the transformation toward “everything as a service” [1]. The virtuous cycle driven by Cloud, Mobile and Social manifests itself at three levels:

  • It obviously affects the IT folks with whom I discuss the subject. Immense changes are already taking place in many IT departments.
  • It affects their company. For example, the company might need to change the business design in order to optimize its supply chain.
  • It affects the clients of their company. Their definition of value changes these days faster than the time it takes the CIO I speak with to say “value.”

© Copyright 2010 Israel Gat

Figure 2: The Virtuous Cycle of Cloud, Mobile and Social

Sometimes I get a push-back from my clients on this topic. The push-back is usually rooted in the immense complexity (and fragility) of the enterprise software systems that had been built over the past ten, twenty or thirty years. The folks who push back on me point out that consumerization of IT will not scale big time until enterprise software gets “consumerized” or at least modernized.

I agree with this good counter-point but only up to a point. I believe two factors are likely to accelerate the pace toward “consumerization” of enterprise software:

  1. Any department/business unit that can get a service in entirety from an outside source is likely to do so without worrying about enterprise software and/or data center considerations. This is already happening in Marketing. As other functions start doing so, more and more links in the value chain of enterprise software will be “consumerized.” In other words, these services will be carried out without the involvement of the IT department.
  2. Once the switch-over costs from legacy code to state-of-the-art code are less than the steady state costs (to maintain and update legacy code), the “consumerization” of enterprise software is going to happen with ferocious urgency.

If you are in enterprise software you need to start modernizing your applications today. The reason is the imperative need to mitigate risk prior to reaching the end-point, almost irrespective of how far down the road the end-point might be.  See Llewellyn Falco‘s excellent video clip Rewriting Vs Refactoring for a crisp articulation of the risk involved in rewriting and why starting to refactor now is the best way to mitigate the risk.

Footnotes:

[1] The phrase “Everything as a Service” has been coined by Russ Daniels.

Advertisements

Connecting the Dots: Operational Excellence, Strategic Freedom and the Pursuit of Passion

leave a comment »

My recent post The Headlong Pursuit of Growth, and Its Aftermath applied insights from Toyota Motor Corporation to Agile methods. Among various lessons to be learned, the post highlighted the relationship between mechanism and policy: 

Just like the Toyota Production System, your software method is a “vehicle” which is subject to policy decisions from above. It cannot, however, compensate for policy failures.

In other words, operational excellence in Agile methods is not a substitute for strategy/policy. It does not confer strategic freedom.

In another recent post – I Found My Voice; I did not Find My Tribe – the vicious cycle that leads to loss of passionate Agile talent was described as follows:

This “1.5” phenomenon is at the root of a vicious cycle that dilutes companies, particularly these days:

  1. A round of layoffs is implemented.
  2. Just about everyone takes notice and tries to exhibit the “proper behavior/values.”
  3. Folks in the “private tribe” don’t dare come out of the closet.
  4. The passionate person who found his/her voice in Agile is like a fish out of the water. Sooner or later he/she looks for a tribe elsewhere.
  5. The company becomes more diluted on folks who are willing to try new things and have the drive to make them happen.
  6. The products and the supporting processes continue to be mediocre.
  7. Goto step 1.

Reading the article Getting Toyota Out of Reverse, published in the December 18 issue of BusinessWeek, I found a fascinating linkage between the two posts:

“They say that young people are moving away from cars,” Toyoda said. “But surely it is us—the automakers—who have abandoned our passion for cars.”

One had better take notice when the president of Toyota speaks of the effects of loss of passion using phrases like “irrelevance or death” and “grasping for salvation”.

You need go no further than John Hagel‘s recent post Pursuing Passion for a resounding second opinion on the subject.

It Won’t Work Here

with 3 comments

Two major obstacles to vetting Agile topics effectively with executives were identified in the post entitled The Business Value of Agile Software Methods:

  1. Lack of hard quantitative data.
  2. The “It won’t work here” syndrome.

As indicated in the post, the data provided in the study How Agile Projects Measure Up, and What This Means to You and the book The business Value of Agile Software Methods address the first obstacle. This follow-on post is about the second of the two obstacles – the resistance to Agile transformation in the face of hard data on its benefits to other companies.

Resistance in the form of “it won’t work here” is typically anchored in one or more of the following five beliefs:

  1. Uniqueness: “Some very unique elements exist in our company. These elements render industry data inapplicable.”
  2. Secret sauce: “Something very special element existed in the companies reporting great success with Agile. Our company does not possess nor have access to the ‘secret sauce’ that enabled success elsewhere.”
  3. Cultural change: “For the Agile initiative to succeed, our corporate culture needs to change. The required cultural change takes a lot of time and involves a great deal of pain. All in all, the risk of rolling Agile is unacceptably high.”
  4. Affordability: “The company is strapped to the degree that investment in another software method is a luxury it can’t afford.”
  5. Software is not core to us: “We are not a software company, nor is software engineering our core competency. Software is merely one of the many elements we use in our business.”

Various other reasons for not going Agile in the context of a specific company are, of course, cited at some frequency. The five reasons listed above seem to be encountered most often by Agile champions.

Use the following counter-arguments to turn around these beliefs:

  1. Uniqueness: Very rare occurence. Companies use similar business designs, apply fairly standard operating procedures, utilize common technology, are subject to the same regulatory constraints that their competitors are, have offshore sites in places like India, etc. Discussion of your company vis-a-vis its direct competitor usually suffices to overcome the uniqueness claim. 
  2. Secret sauce: The ‘secret sauce’ is neither secret nor difficult to concoct. For example, the secret sauce used by BMC Software in its successful Agile initiative  had four simple ingredient: intentionality, know-how, flexibility and patience. Based on insights by colleague and friend Alan Atlas, I have recently added mutuality as the fifth ingredient. Your own secret sauce might be somewhat different, but I very much doubt that an extravagantly exotic sauce will be needed.
  3. Cultural change: Myth has it that Agile would only work in the Collaborative culture. Reality is it will work in any of the four core cultures identified by Schneider: Control, Competence, Cultivation or Collaboration. See Four Principles, Four Cultures, One Mirror for an approach to building Agile on the strength of whatever culture prevails in your company/organization.
  4. Affordability: The question to ask is whether you can afford not to improve your software. Tools are readily available to quantify your company’s technical debt. Monetize the technical debt and include it as a liability line item in a pro forma balance sheet. Doing so is likely to shift the discussion from affordability to how to create elbow room for handling the technical debt.
  5. Software is not core to us: Indeed, it might not be but it is likely to become so in just about any industry. Use an analogy like the record industry vis-a-vis the publishing industry. The record industry has been decimated by software over the past decade. Chances are a similar decimation is likely to occur in publishing unless the industry transforms itself. (Some of the decimation that already took place in publishing has become quite visible recently. For example, last week Bloomberg LP announced completion of the acquisition of BusinessWeek for a paltry $5M).

You will need to be realistically patient with respect to the time it takes for the considerations listed above to sink in. It could easily take six months just to forge a consensus on the subject in the executive team. It might then take another six month to operationalize the consensus. Chances are there is an elephant hidden somewhere in the “room” if you don’t carry the day with within a one year period of diligently vetting Agile with your executives.

The Changing Nature of Innovation: Part II — National Policy

with 4 comments

Michael Porter makes two interesting observations about innovation in the US in his BusinessWeek interview entitled Why America Needs an Economic Strategy:

… U.S. entrepreneurship has been fed by a science, technology, and innovation machine that remains by far the best in the world. While other countries increase their spending on research and development, the U.S. remains uniquely good at coaxing innovation out of its research and translating those innovations into commercial products. In 2007, American inventors registered about 80,000 patents in the U.S. patent system, where virtually all important technologies developed in any nation are patented. That’s more than the rest of the world combined

In contrast to the effectiveness of utilizing research and technology for entrepreneurial purposes, Porter notes a worrisome trend:

An inadequate rate of reinvestment in science and technology is hampering America’s feeder system for entrepreneurship. Research and development as a share of GDP has actually declined, while it has risen in many other countries. Federal policymakers recognize this problem but have failed to act.

Viewed in light of Part I of this mini-series on innovation, a natural question posts itself:

Do the new forms of experimentation, which enable the US entrepreneurial system to be so very effective in coaxing innovation out of research that has already been done, mask a fundamental decline for which there will be hell to pay?!

Written by israelgat

November 24, 2009 at 5:30 am