The Agile Executive

Making Agile Work

Search Results

Is There Something Inherently un-Agile About ERP Software?

with one comment

A reader of the post Make the Hairs on the Back of Your Neck Stand Up posed the following question:

I wonder if there’s something inherently un-Agile (and thus, unable to change fast enough to meet new business demands) about older enterprise software, or just ERP software?

The answer IMHO is size. To quote Capers Jones:

Since defect potentials tend to rise with the overall size of the application, and since defect removal efficiency levels tend to decline with the overall size of the application, the overall volume of latent defects delivered with the application rises with size. This explains why super-large applications in the range of 100,000 function points, such as Microsoft Windows and many enterprise resource planning (ERP) applications may require years to reach a point of relative stability. These large systems are delivered with thousands of latent bugs or defects. 

The phenomenon described by Jones is often exacerbated through the “ship more infrequently” syndrome. IMVU’s Timothy Fritz describes it as follows:

While this may decrease downtime (things break and you roll back), the cost on development time from work and rework will be large, and mistakes will continue to slip through. The natural tendency will be to ship even more infrequently, until you aren’t shipping at all. Then you’ve gone and forced yourself into a total rewrite. Which will also be doomed.  

You might choose to reduce your technical debt instead of trying total rewrite. Chances are you will struggle to find Elbow Room for Handling Technical Debt. My hunch is that once >50% of development resources are assigned to maintaining the software on an on-going basis, it is time to get into refactoring big time. If you don’t, sooner or later you are likely to find you can’t afford the software you developed.

Between Agile and ITIL

with 4 comments

You do not need to be an expert in Value Stream Mapping to appreciate the power of speeding up deployment to match the pace of Agile development. By aligning development with deployment, you streamline “production” with “consumption.” The rationale for so doing is aptly captured in the first bullet of the Declaration of Interdependence:

We increase return on investment by making continuous flow of value our focus.

As pointed out in previous posts in this blog, Flickr and IMVU seem to be doing an exceptionally fine job streamlining the flow of value: every thirty minutes and every nine minutes respectively. A recent presentation in Velocity 2009 by John Allpsaw and John Hammond adds color how development and operations at Flickr cooperate to accomplish “10+ deploys per day.”

What does such fast pace mean to the business? In a nutshell, much of the guess work as to what features are really needed is eliminated when you develop, deploy and collect customer feedback in ultra fast manner. Consequently, the company’s business design is likely to be transformed. Click here, here, and here for more detailed discussions how the business design gets transformed.

Michael Cote, Andrew Shafer and I have been pondering  about aligning development and operations for quite sometime. On the one hand, we are painfully aware of the traditional desire to minimize change in IT operations. On the other hand, we are of the opinion Agile principles are quite applicable to operations. We often wonder whether the obstacles between Agile and ITIL are real or imaginary. We actually believe the {development –> operations} theme is an important instantiation of Dean Leffingwell‘s recent thoughts about applying Agile/Lean principles to other knowledge work.

The three of us – Michael, Andrew and I – decided to do a few podcasts to explore what stands between Agile and ITIL. The first of these podcasts will be published this month (July 2009).

Stay tuned…

Written by israelgat

July 7, 2009 at 7:19 am

The Language, The Issues

with 2 comments

Colleague Clarke Ching asked me about the language I use in interacting with executives on Agile topics. To quote Clarke:

Obviously the language one uses with a developer is quite different from the language one uses with a program manager. Likewise, the language you [Israel] use in discussing Agile with executives must be quite different. What language do you use? In particular, what language do you use amidst the current economic crisis?

What language do you use amidst the current economic crisis?

I view the economic crisis as part of life. Having grown up in Israel, I still clearly remember:

  • The 1956, 1967 and 1973 wars;
  • Various economic crises;
  • Any number of measures taken by the government to cope with financial crises. For example, devaluing the currency on many occasions.

We all survived and the country moved forward in leaps and bounds. We simply learned to accept dramatic changes as inevitable, to continue doing what we believed in. We, of course, changed tactical plans in response to disruptions such as a change in the value of the currency, but continued to do the right things strategically. Such turbulence, and possibly worse, has been characteristic of much of the world for many years now. Just think of Eastern Europe, Latin America or Africa.

Fast forwarding to 2009: I try to put the economic crisis in perspective. I have discussed the techno-economic cycle along the lines articulated by author Carlota Perez in her book Technological Revolutions and Financial Capital: The Dynamics of Bubbles and olden Ages.  In my recent post Why Agile Matters,  I stated:

  • The fifth techno-economic cycle started in 1971 with the introduction of the Microprocessor;
  • This cycle has been characterized by software going hand-in-hand with miniaturized hardware. We are witnessing pervasive software on unprecedented scale;
  • Furthermore, software is becoming a bigger piece in the contents of just about any product. For example, there are about 1 million lines of code in a vanilla cell phone;
  • Agile software significantly reduces the cost of not “only” software, but the cost of any product containing software;
  • And, Agile software enables us to respond faster and more flexibly to changes – in the software, in the business process that is codified by the software, in the product in which the software is embedded.

In short, I speak about software as an important factor in the bigger scheme of things – the techno-economic cycle.

What language do you use in your conversation with executives?

I describe the benefits of Agile in the business context. For example, when I meet an executive of a major financial institution, I discuss with him/her issues of compliance and risk his company is facing.  For a global financial institution I typically discuss the critical needs during transfer of trade from London to Wall Street. A lot of things need to work seamlessly in order to ensure smooth transition. If things do not work well within the short transition window, the implications are dire:

  • Unacceptable risks. Billions of $$ could be lost if a global financial company cannot start trading on time in Wall Street;
  • Severe compliance issues. The executive with whom I speak and his/her company could get in serious regulatory trouble due to a failure to reconcile trades and keep the required audit trail.

The ties of these business imperatives to Agile are straightforward:

  • Higher quality code reduces the risk of a ‘glitch’ in the transition of trade from London to Wall Street;
  • Should a financial institution suspect a glitch might happen, Agile usually enables Application Development and Operations to fix the code faster than traditional methods;
  • And, using virtual appliance technology enables deploying the fix in minutes instead of months.

I usually cite the examples of Flickr and IMVU to demonstrate how fast one can deploy software nowadays. I make it crystal clear that I do not expect a global financial institution today to be able to deploy every thirty minutes or every nine minutes as Flickr and IMVU do. However, I stress that the software industry is clearly heading toward a much shorter cycle between concept or problem identification and deployment. I point out that he/she has an opportunity to be ahead of the power curve, to gain competitive advantage in the market through superior velocity in both development and deployment. Obviously, a faster introduction of a new hedging algorithm could make a big difference for a financial institution.

What do I typically hear from the executive in such a conversation?

The responses I usually get tend to reflect the alignment (or lack thereof) between the financial strategy and the operational strategy a company follows:

Customer Driven Testing

with 4 comments

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.

Written by israelgat

March 15, 2009 at 3:28 pm

Every Nine Minutes

with 2 comments

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.

Written by israelgat

March 14, 2009 at 11:12 pm