The Agile Executive

Making Agile Work

Archive for January 2009

Evolutionary System Development

leave a comment »

Mary Poppendieck pointed me at the recent Evolutionary System Development paper by Denning et al. The authors make two points which could be of particular interest to viewers of this blog, as follows:

 

  1. “All the evidence says that evolutionary processes work for systems large and small…”
  2. “… risk taking is the fastest route to fitness.”
Highly recommended!

Written by israelgat

January 14, 2009 at 7:11 pm

The View From the Executive Suite

with 4 comments

A few days ago I had the pleasure of spending a couple of hours with Bob Rockwell. Bob is the managing partner of AdviSoar, a Lewisville, TX consulting company specializing in coaching and developing executives, and teaching people the skills to develop executive relationships. “Helping Good People Do Great Things!” is AdviSoar’s mantra.

Business Risks Agile Addresses

Bob’s view of Agile, like any corporate executive, is business oriented. Important as the benefits to R&D are, Bob believes Agile is all about mitigating business risks. He specifically highlights the following as risks that Agile may be well suited to address:

  • Monetary risk: the level of investment it takes till one can have a meaningful “sniff test”.
  • Market risk: changes in the market in the window of time between concept and delivery. In particular, Bob is concerned about the risk of missing a market opportunity due to a too-constraining design document or a too-long development time. Additionally, Agile would seem to offer the potential of new discovery that could have market value.
  • Competitive risk: a rival in the market starts delivering faster or “better” by adopting Agile methods.
  • Execution risk: will the software be on-time? Will the business executive in charge get early warning signs in case the software project is in trouble?
  • Brand risk: tarnishing of image due to poor quality or miss-met expectations.
  • Innovation risks: shipping mediocre software (based) product due to insufficient experimentation and insufficient or ineffective “user” input through the process.

In other words, Agile for Bob is about running and growing the business, not about running R&D.

Laws of Software Engineering

Accrual

Our discussion of the risks Agile mitigates led to highlighting a few “cheat sheet” points an executive should keep in mind with respect to doing or utilizing software:

  • The investment in software development is typically less than half the overall life-cycle investment in software.
  • The longer you take to address technical debt, the higher you pay.
  • The accrual of business value in well run Agile projects is exponential (see chart above); in contrast, the investment is linear in traditional waterfall processes. In the graph above, taken fromJim Highsmith’s Agile 2006 presentation “How to be an Agile Leader”, 90% value is captured upon delivering 50% of features.

We ran out of time before we could discuss the classical laws of software evolution established by Lehman and Belady. I have no doubt we will get into them next time Bob and I meet. In particular, the question how applicable these classical rules are to Agile software projects is a topic I plan to discuss with Bob in length and depth. Also, a social contract for Agile is on the “agenda”…

Stay tuned….

Written by israelgat

January 14, 2009 at 2:34 pm

Choosing Between Two Disruptions

with 2 comments

A couple of weeks ago I was talking shop with a colleague of mine – the co-founder and CTO of a fascinating software company. He was bemoaning the paralysis that was affecting his company. Every executive was playing it safe, too safe. It was next to impossible to finalize their CY2009 plan as no executive would give hard commitments, let alone be aggressive about making commitments. My colleague was worried. Big time.
 
The fascinating thing about our conversation was that my anguished colleague was quite bullish about Agile methods. His was an informed bullishness – he is a very astute developer who grasps the potential of Agile in a deep manner. While worried about the financial crisis working its way from Wall Street to Main Street, my colleague was quite willing to invest in Agile methods in more than one way. It was intuitively clear to him Agile is not only a good risk to take, it is the right kind of risk to take these days.

The Risks of Introducing Agile

The risk you take rolling Agile on a large scale is the possible process disruption you introduce in your company. There are several risks; at the top of the list:

  • R&D productivity could go down before it goes up.
  • Marketing might be hesitant to promote features that are not 100% guaranteed to be in the forthcoming release.
  • Sales will need time to elevate the playing fields from selling function/feature to selling value.
  • Customer Support must revise support policy to accommodate frequent releases.

I would not take any of these risks lightly. Any one of them could get you and your company in serious trouble.

 
I would, however, suggest you look carefully into the nature of the Agile disruption. Like a set of nested Russian dolls, the disruption to your company’s established modus operandi masks the disruption Agile creates in the market. When it comes to Agile, you face the Innovator’s Dilemma in the Christensen sense. 

 

The Risks of Avoiding Agile

As software becomes more and more pervasive, it does not really matter whether you are in Information Technology, Financial Services, Transportation, Retail or any other vertical. The strategic question you need to consider is your company’s competitive position in the market vis-a-vis rivals who will successfully adopt Agile:
  • How would you cope with a competitor who is much faster to market than you?
  • How would your cost structure be viewed by industry analysts when your rivals rip the benefits of hyper-productive Scrum teams?
  • Would your brand be negatively affected if you fell behind on quality? 
  • How would your strategic customers assess your response time to requests for enhancement compared to nimbler players in the field?

While Agile may cause what seems like negative disruption internally, the need for so doing is often dictated by a corresponding disruption in your markets, where you can’t choose to avoid the disruption. You need to do a risk assessment of the internal disruption Agile might cause versus how you will be affected by market disruption if you do nothing, or something other than Agile.

Written by israelgat

January 13, 2009 at 10:26 pm

Leading from Within – Tonight in Austin

with 2 comments

Update: see presentation above, or download directly.

Tonight I’ll be giving a presentation at the Austin IEEE meeting entitled “Leading from Within.” It examines the “secret sauce” for enterprise level Agile deployment with special emphasis on the virtues of the Agile leader.

You can see full details, including a map to the location on the Austin IEEE site.

Written by israelgat

January 13, 2009 at 4:50 pm

Posted in The Agile Leader

Tagged with

Starting the Agile Dialog

with one comment

A question I always pose to executives who seek my advice on rolling Agile in their companies is “What would you like to accomplish?” I ask this “trick” question as the first step in a dialog aimed at developing a deeper understanding of rolling Agile at the enterprise level versus rolling it selectively in pockets. I usually consider the dialog successful when the executive has thought through the various possible foci for enterprise roll-out and is comfortable enough to start setting expectations with his teams, peers and superiors.

I find quantification extremely effective in cutting through the mystique of software engineering, enabling executives from all walks of life to put their hands around a topic which might not be in their domain of expertise. As I said in my recent Cutter essay, I usually point out three “axes” of quantification, as follows:

  • Time-to-market
  • Productivity
  • Quality

The three “axes”, of course, are not absolutely independent. For example, improvements in time-to-market could be very hard to accomplish if quality is not adequate. However, these kinds of dependencies are better explored at a later point in time. In the initial phases of the dialog, my objective is to simplify things to the point the executive and I can jointly think of the Agile roll-out as a one axis thrust. A dual axis thrust, e.g. simultaneously improve both time-to-market and productivity, is definitely feasible. However, I do not generally recommend doing so before an organization reaches an acceptable level of maturity using Agile methods.

Simplistic that the “one axis thrust” might seem, it actually leads to examination, and sometime reexamination, of fundamental tenets of operation. For example, an executive considering the time-to-market axis often needs to determine whether increasing market share through fast delivery of products should indeed takes precedence over improving cost structure through higher productivity. An executive considering the quality axis often starts looking into life cycle costs of software versus “just” R&D cost. It is a small step from here to debating whether a company should focus on growth through acquisition of new customers or on customer retention.

Questions like those listed above are characteristic of roll-out of Agile at the enterprise level. The scale adds questions of strategy to the customary Agile business value considerations. Large scale Agile deployment is likely to transform the company’s R&D organization as well as other functions in the company’s value chain. For such a transformation(s), intentionality is critical: the goals you’re accomplish need to be stated up-front and made clear to the organization, esp. those who’ll be part of this transformation. This seems obvious – people should know why they’re going through all this trouble to transform – but simply getting everyone on the same page is too often overlooked.

Hence my simple question: “What would you like to accomplish?”

Written by israelgat

January 12, 2009 at 10:17 pm

Posted in Starting Agile

Tagged with

Why Now?

with one comment

The decision to launch The Agile Executive in January 2009 stems from the confluence of economic imperatives, unfulfilled business needs and maturation of adjacent technologies that make this a perfect time for deploying Agile at the enterprise level.

The current macro-economic crisis has created a great deal of uncertainty with respect to operating environments. Corporations, large and small, are forced to revisit their core assumptions and modus operandi in response to changes that were not anticipated just a few months ago. The ability to quickly reconfigure the business is the best antidote to the challenges pervasive uncertainty poses. The flexibility and speed of Agile could and should play a critical role in reconfiguring the business to better respond to change. Dealing with “changing requirements” is what Agile was built from the start to enable.

In spite of all of the progress made by Agile methods over the past few years, most of the effort still goes towards the nuts and bolts of Agile. Hence, three needs have largely been left unfulfilled:
  1. The application of Agile at the corporate level as distinct from piecemeal implementation in selected pockets
  2. The utilization of Agile methods beyond software
  3. The development of business designs that take advantage of the capabilities of Agile methods

Effective fulfillment of these three needs is likely to transform and increase the value of not “only” R&D, but the company as a whole.

Last but not least, the compound effect of coupling Agile methods with technological progress in adjacent domains of software creates new opportunities for utilizing Agile. For example, virtual appliance techniques open the door for bridging the chasm between software development and IT operations. We are now able to “containerize”, distribute and provision the output of hyper-productive Agile teams as virtual appliances in a much faster manner than through traditional deployment methods. The power of so doing was demonstrated close to two years ago by Walter Bodwell who prototyped a containerized version of the BMC Performance Manager using rPath virtual appliance techniques. If we were to do so today, we would use rPath virtualization technology to put the BMC Performance Manager in the Cloud.

We will explore the various topics listed above at greater length and depth in subsequent posts. For now, think of The Agile Executive as a Michelin guide to your executive journey into Agile.

Written by israelgat

January 12, 2009 at 9:47 pm

Posted in Macro-economic Crisis

Tagged with

Coming Soon

leave a comment »

We’ll be starting up content on Agile advice, commentary, and views for the executive any minute now…

Written by Coté

January 6, 2009 at 9:01 pm

Posted in The Agile Life