The Agile Executive

Making Agile Work

Archive for the ‘Macro-economic Crisis’ Category

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.

A Note on the Macro-Economic Crisis

with one comment

Re-reading Technological Revolutions and Financial Capital: The Dynamics of Bubbles and Golden Ages by Carlota Perez, I was struck by the following paragraph:

So, once again, the amount of money available to financial capital has grown larger than the set it recognizes as good opportunities. Since it has come to consider normal the huge gains from the successful new industries, it expects to get them from each and every investment and will not be satisfied with less. So rather than go back to funding unsophisticated production, it develops sophisticated instruments to make money out of money. [Italicized  and highlighted by IG]

Perez published the book in 2002. Her words of wisdom seem to be appropriate today even more than they might had been then.

(Click here and here for related discussions of Agile in the context of the current macro-economic crisis.)

Written by israelgat

April 13, 2009 at 12:20 pm

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:

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.

From “How” to “What”

leave a comment »

I have been speaking with various panelists in preparation for the forthcoming Rally’s Agile Success Tours. One emerging thread in these pre-panel discussions is the need to elevate the playing fields. Nobody doubts, of course, the importance of the nuts and bolts of Agile. But, just about every panelists I spoke with believes we should pay as much attention to end-to-end corporate business considerations. In other words, we are starting to shift from “How” to “What”, from the small scale roll-out to enterprise level Agile.

Stay tuned…

Written by israelgat

February 21, 2009 at 10:36 am

Batten Down the Hatches

leave a comment »

“As you might expect, we are in a batten down the hatches mode.” These words, taken from an email an executive just sent, prefaced his decision not to go ahead with planned Agile projects due to the need to cut costs. His operating assumption is simple: His company must cut costs now and will somehow manage without  investing in Agile software and consulting.

Real $$ are hidden in your software

In Estimating Software Costs, author Capers Jones quantifies five year cost of software application ownership (for the vendor). He examines three  similar applications, each of nominal size of 1000 function points, as a function of the sophistication of the corresponding projects. The respective life cycle costs are as follows:

  • Lagging projects: $2,316,000
  • Average projects: $1,860,000
  • Leading projects: $1,312,000

Jones goes on to issue the following stern warning:

All known compound objects decay and become more complex with the passage of time unless effort is exerted to keep them repaired and updated. Software is no exception… Indeed, the economic value of lagging applications is questionable after about three to five years. The degradation of initial structure and the increasing difficulty of making updates without “bad fixes” tends towards negative returns on investment (ROI) within a few years.

Dwindling maintenance revenue streams complicate the situation

Revenues from maintenance services are subject to severe pressures these days as many customers are renegotiating service contracts. Igor Stenmark foresaw and foretold the phenomenon in November 2008.  To quote Igor:

…sacred cows like software maintenance can become hamburger meat if users feel enough of a budget pressure.

Net net, as they say, the exec mentioned above is likely to face rising maintenance costs due to software decay over time. At the same time, revenues from maintenance contracts are bound to fall short of projections due to customers renegotiating their contracts.

The shiny new toy is not a cure

Recognizing the software maintenance conundrum they are caught in, many executives are pushing hard to develop new software to increase sales in order to compensate for the decline in revenues from software maintenance services.

What is missing is a serious commitment to improve the underlying software process. Software developed today might indeed be sold as a shiny new toy tomorrow. But, unless the software process is improved, a little down the road the new software will have similar maintenance problems. The corrosive effect of software decay on the shiny new software will become more and more severe as a function of time. The current business environment, hopefully, will change in a few years. However, the underlying software development and maintenance laws will not. No getting around it.

No better time than now

The numbers from Capers Jones cited above are illustrative of the cost savings you could expect to attain by modest investments in improving software process and practices. You might perhaps have more attractive cost saving alternatives available to you. However, if you don’t, there is no better time to invest in software process and practices than now.

Written by israelgat

February 16, 2009 at 4:09 pm

A Social Contract for Agile

with 10 comments

How do you make Agile work in spite of layoffs? The following war story is pertinent.

During the 1967 war between Israel on the one side and Egypt, Jordan, and Syria on the other, my paratroop battalion carried out a helicopter raid on the Egyptian artillery in Um Katef. The raid was quite successful in neutralizing Egyptian artillery fire which was playing havoc with the Israeli infantry. We incurred, however, quite a few casualties as a result of firing bazookas at Egyptian ammunition trucks. The resultant explosions created an inferno that proved lethal to Egyptians and Israelis alike. We retreated when the Egyptians sent in reinforcements to reign us in. We carried back our wounded in dunes in which you sink to your knees even if you are not carrying anything. Also, we carried back our dead. The dead continued to be part of us in spite of not being with us anymore.

The relevance of a paratroop raid some 40 years ago in the Sinai desert to Agile practices in software circles today might appear to be tenuous.  This post takes the view that the two – paratroop units and Agile teams –  are actually quite similar from a leadership perspective. It is next to impossible to get soldiers over the top if they suspect they might be left behind on the battlefield if they were wounded or killed. Likewise, empowerment, collaboration and the willingness to experiment go down the drain when an Agile team expects “casualties” in the form of forthcoming layoffs.

Flying at the Teeth of Layoffs

The design for the 2005 roll-out of Agile at BMC Software did not put in place any planning in advance on how to deal with the impact of possible layoffs on Agile assimilation. Everyone knew, of course, that layoffs might and do happen in the software industry. However, Agile was kept in a different mental “drawer” from the one in which possible layoffs were kept. Planning-wise the two were not really connected.

When we had to carry out layoffs in 2005, we encountered severe cognitive dissonance:

  • On the one hand, the excitement in the business unit about Agile was tremendous. We were witnessing the psychological aspects of Deming‘s System of Profound Knowledge in an unprecedented manner. Skill, pride, confidence and collaboration were building up faster than you could say “Agile”.
  • On the other hand, the layoffs put a damper on all four elements – skills, pride, confidence and collaboration. Folks who worried whether they might be next in line to be laid off were not able to place the Scrum team’s accomplishments ahead of the credit they sought for themselves. The determination to learn more and deeper about Scrum slackened as employees bided their time in anticipation of the next round of layoffs. Obviously, pride and confidence went down the drain.

Reciprocity

Preserving the Agile momentum in the face of layoffs required striking a new balance between what employees were getting out of Agile versus what the company was expecting to accomplish through Agile. I actually viewed it as a kind of balance of payments problem. It was quite clear what the company was already getting out of Agile, and even clearer that the long-term payoffs from successful implementation of Agile could be very significant indeed. We did not, however, have a good answer then for worried employees who asked: “What is in it for me?” A record breaking Scrum implementation 12 months down the road is not too meaningful for an employee who suspects he might not be with the company in 6 months.

It so happened that in 2005 we started seeing job specifications that either asked for or mandated Agile skills. This gave us the clue to a meaningful reciprocity in the face of potential layoffs. By investing aggressively in Agile training we would not “only” improve productivity, we would also enhance marketability of our employees. We would be providing a better safety net for them.

A Social Contract for Agile

My sense in 2005 was that the social contract between employers and employees in the software industry was broken. Without a working social contract, the friction and antagonism can bring a system down. For example, in 1942 – the turning-point year of WWII – 833,000 days of coal mining were lost due to strikes in the British coal industry.

The preliminary thoughts I had on the subject in 2005 turned into a mini social contract. The mini social contract is an agreement between an executive and his employees on the rules of the game that are mutually satisfactory. The mini social contract I used evolved over the years. Here it is in its latest form:

Team, my overarching organizational objective is to preserve our team and its institutional knowledge for our corporation and its customers for years to come. We will achieve this goal by enhancing our software engineering prowess to the level that the resultant benefits will outweigh the repercussions of the current financial crisis. The state of the Agile art should enable us to attain hyper-productivity which will serve as the best antidote to layoffs. In the event that we fail to accomplish hyper-productivity and our assignments fade away, you will find the Agile skills you developed much in demand in the market. Whether you will or will not be with the company in the future, I acknowledge your need to develop professionally as Agile practitioners and commit to invest in your education/training.

Impact of the Social Contract

Applying the social contract produced four effects:

  1. It legitimized discussions on a taboo topic.
  2. It reduced fear while increasing hope.
  3. It was a hard proof point to the folks in the trenches that I as an executive was one of them. This is a most critical aspect in the executive-employee relationship in software companies.
  4. It led to fruitful exchanges with Agile practitioners in other companies who were wrestling with the very same issue. These exchanges helped us improve the social contract.

Criticism of the Social Contract

I got some flak from colleagues on the commitment to invest in Agile training. The concern was that such a commitment, even if it is given as a gentleman’s word, is too open-ended. Proficiency in Agile, it was argued, is quite relative. Hence, when could one state that the contract was “fulfilled” with respect to commitment to invest in Agile training and coaching?

The Fine Line Between Management and Leadership

The criticism of the social contract cited above should not be rejected out of hand. Obviously, one does not want to create expectations that might not be fulfilled.

Quite simply, committing to Agile training and coaching actually illustrates the fine line between management and leadership. As the quip goes – “Leaders do the right things; managers do things right”.  Committing as an executive to Agile training and coaching across the board might appear to be not doing things “right”.  Making this kind of commitment, however, is in the very nature of leadership. And, frankly, it is also doing things “right” for executives who have the best interest of the company at heart.

Where do You Lead From?

We were taught to lead from the front in the paratroop corp. Over the years, I have learned one other important aspect of leadership: leading from within. To me, the social contract is leading from within.

Written by israelgat

February 3, 2009 at 5:32 pm

The Mindset

with 5 comments

In her recent post Stop Drinking the Kool-aid – Eat the Cereal!, colleague and friend Jean Tabaka gives an interesting metaphor for iteracting with executives about Agile:

Talking about Agile to executives can be like feeding turkey to your family on Thanksgiving; it puts everyone into a sleepy stupor.

Jean goes on to recommend Lean as a way to get the message across. To quote her:

Through Lean, I am able to tap into discussions about waste versus value. I can engage the executive team into looking at their entire organization. And, these “seeing the whole” discussions help them then understand why they should care about an engineering groups adoption of Agile.

Working the Lean angle the way Jean recommends could most certainly open the discussion and enrich it. Success, however, depends on a certain kind of mindset of the executive you are talking to.  This mindset is nicely described in H. Thomas Johnson‘s article Manage a Living System, Not a Ledger:

…a business organization cannot improve its long-run financial results by working to improve its financial results. But the only way to ensure satisfactory and stable long-term financial results is to work on improving the system from which those results emerge.

If you accept the premise expressed by Johnson, you need to consider two kinds of possible dialogs to get your Agile message across:

  • Agile focused dialog about the what, why, how and when of Agile. You do this kind of dialog when your counterpart is already at the point of looking for sustainable value generation, not for a magic bullet.
  • Recipe for success dialog. This kind of dialog establishes the foundation required for the first dialog when the executive is not quite ready yet for Agile. Give the executive the opportunity to think deeply on his algorithm for success. It may take a few conversations until the algorithm is spelled out. Once it is, you can start working with the executive on what Agile is and how it might fit into his algorithm for success.

An extremely important point to keep in mind is that mindsets evolve. The set of business circumstances under which an executive is operating can lead to a certain mindset. The mindset can be quite different at another point in time due to change in strategy, priorities and constraints. A good fit for Agile may not exist today, but it might exist tomorrow.

Written by israelgat

January 26, 2009 at 9:51 pm

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