Archive for December 2009
Is There Something Inherently un-Agile About ERP Software?
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.
Make the Hairs on the Back of Your Neck Stand Up
Cote sent me the recent CIO Magazine article entitled ERP’s Paralysis Problem and the Repercussions for Business Everywhere. The article discusses the findings from a December 2009 study conducted by IDC and sponsored by ERP vendor Agresso, as follows:
A couple of verbatim responses from respondents should make the hairs on the back of your neck stand up: “Capital expenditure priorities are shifted into IT from other high-payback projects” just to perform necessary ERP changes, noted one respondent. Said another: “Change to ERP paralyzes the entire organization in moving forward in other areas that can bring more value.”
To make doubly certain the message gets across, the article finishes with the following “nocturnal” paragraph:
As the sun finally sets on the first decade in the new millennium, it’s high time we say good night to ERP. A new day will be starting soon, and the blemished legacy and failings of ERP’s nearly four-decade-long reign will be a distant memory.
Maybe. While ERP systems no doubt have their own particular twists, the sorry state of affairs described above is true of various industries that have developed complex software systems over prolonged periods of time. Just in the past few months I have witnessed such situations in banking and health care. In previous life I had been exposed to more of the same in other industries. The software decayed and decayed but technical debt had never been reduced. Consequently, the cost of change, any change, today is horrendous. As Jim Highsmith‘s chart below indicates, “once on the right of the curve, all choices are hard.”
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.
Enough, indeed, to make the hairs on the back of your neck stand up…
Predicting the Year Ahead
Cutter Consortium has published predictions for 2010 by about a dozen of its experts. My own prediction, which examines the crash of 1929, the burst of the “dot-com bubble” in 2000 and the financial collapse in 2008, is actually quite bullish:
I expect 2010 to be the first year of a prolonged golden age. Serious as the various problems we all are wrestling with after the 2008-2009 macro-economic crisis are, they should be viewed as systemic to the way a new generation of revolutionary infrastructure gets assimilated in economy and society.
In addition to the techno-economic view expressed in the Cutter prediction, here are my Agile themes for 2010:
- Agile moves “downstream” into Release Management.
- Agile breaks out of Development into IT (and beyond) in the form of Agile Infrastructure and Agile Business Service Management.
- SOA and Agile start to be linked in enterprise architecture and software/hardware/SaaS organizations.
- Kanban starts an early adoption cycle similar to Scrum in 2006.
Acknowledgements: I am thankful to my colleagues Walter Bodwell, Sebastian Hassinger, Erik Huddleston, Michael Cote and Annie Shum who influenced my thinking during 2009 and contributed either directly and indirectly to the themes listed above.
Prosperity without Growth
Readers of this blog might recall the ‘secret sauce’ proposed in The Mindset for talking about Agile with executives:
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.
In a perceptive CQI article on the recently reported problems at Toyota, Johnson offers the following analysis:
Toyota avoided this fate until the last decade because it did not regard results as outcomes that a business achieves by requiring managers to drive people to meet financial targets. It saw that results emerge from a process in which people carefully nurture a web of relationships. These relationships, strikingly enough, emulate the behaviour in natural living systems.
The reversal of Toyota’s fortunes in the past decade suggests that many of its top managers lost the habit of thought that had previously shaped the company’s policies and actions. They lost the habit of thought that caused the company, perhaps unconsciously, to act like a living system. Toyota adopted the finance-oriented mechanistic thinking that had spawned the inferior management practices and the poor performance shown by most of its competitors after the 1970s. And because it abandoned living-system thinking for mechanistic thinking, Toyota began to embrace a virtual world of finance, not a concrete world of humans in cooperative relationships.
Johnson concludes his analysis with a broad warning:
Efforts of companies to reduce that waste by “going green” are not likely to be any more effective than efforts to improve performance by “going lean”. In neither case do these efforts change the thinking that produces excess growth. The efforts might reduce the rate of growth for a time, but they will never reverse it as long as companies adhere to the conventional wisdom from the virtual world of finance that says prosperity is not possible without growth. [Highlights by IG]
The hazards of the virtual world of finance have been conclusively demonstrated during the macro-economic crisis of 2008-2009. One must wonder what it would take to learn the applicable lessons at the micro level of individual companies.
Connecting the Dots: Operational Excellence, Strategic Freedom and the Pursuit of Passion
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:
- A round of layoffs is implemented.
- Just about everyone takes notice and tries to exhibit the “proper behavior/values.”
- Folks in the “private tribe” don’t dare come out of the closet.
- 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.
- The company becomes more diluted on folks who are willing to try new things and have the drive to make them happen.
- The products and the supporting processes continue to be mediocre.
- 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.
Wrestling with Scaling Software Agility
Software Development Times has just published Guest View: Wrestling with Scaling Software Agility by Ryan Martens and me. This Guest View is a little unique in that Ryan and I actually try to wrestle each other to the ground… Here is why we try to do so:
Agile champions spend a lot of time trying to communicate the agile premise to the executives in their organization. The difference in context between the champion and the executive often makes it a difficult conversation. A Scrum Master versed in behavior-driven design is not always able to relate to the frustrations of a sales executive who gets free advice on how to sell from everyone and his grandmother.
Conversely, a CFO does not necessarily understand why unit test coverage on the company’s legacy code is still inadequate after a full year of investment in agile methods that embrace refactoring as a core practice.
To bridge the chasm through this article, we resort to role-playing. Ryan Martens plays the Agile Champion; Israel Gat plays the Skeptical Executive. Metaphorically speaking, each one tries to wrestle the other to the ground.
Before you get into this Guest View, I would like to reinforce an important disclaimer:
A note of caution before Ryan and Israel make irreparable damage to their long-standing relationship: The two actually understand each other extremely well and rarely are they of different opinions on the fundamentals of agile in real life…
Enjoy the article!
The Headlong Pursuit of Growth, and Its Aftermath
The December 12-18, 2009 issues of The Economist features a couple of fascinating articles on Toyota Motor Corporation. According to The Economist, Toyota’s President reached the following dire conclusion on the situation Toyota is facing:
Mr Toyoda’s alarm call last month appears partly to have been prompted by reading “How the Mighty Fall”, a book by Jim Collins, an American management writer, which identifies five stages of corporate decline. Mr Toyoda reckons that Toyota may already be at the fourth stage. Companies at this point, says Mr Collins, frequently still have their destinies in their own hands, but often flit from one supposed “silver bullet” strategy to another, thus accelerating towards the fate they are trying to avoid.
In the litany of things that went wrong, an interesting point is made about the Toyota Production System:
… the recalls continued and Toyota started slipping in consumer-quality surveys. A year later Consumer Reports, an influential magazine, dropped three Toyota models from its recommended list. The magazine added that it would “no longer recommend any new or redesigned Toyota-built models without reliability data on a specific design”. People within the company believe these quality problems were caused by the strain put on the fabled Toyota Production System by the headlong pursuit of growth.
Whatever Agile method you practice – Scrum, Lean, Kanban, Crystal, etc. – you need to be cognizant of three touch points with the Toyota experience reported above:
- 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.
- If your company relentlessly pursues growth, the quality/technical debt liability it is likely to incur coud easily outweigh the benefits of growth. Consider the upside potential of growth vis-a-vis the downside of the resultant technical debt. When appropriate, monetize technical debt using the technique described in Technical Debt on Your Balance Sheet.
- In addition to monetizing the technical debt, evaluate the various kinds of risks indicated in The View From The Executive Suite. A sense of how devastating those might be is given by Toyota’s own experience:
Just as Cadillac used to be synonymous with luxury and BMW with sportiness, Toyota was a byword for quality and reliability… The danger in all of this for Toyota is that its loyal (and mostly satisfied) customers in America have long believed that the firm was different from others and thus hold it to a higher standard. The moment that Toyota is seen as just another big carmaker, a vital part of the mystique that has surrounded the brand will have been rubbed away.
Please remember – unless you work for Toyota Motor Corporation, chances are your company would not be able to take the kind of risk Toyota can.
I Found My Voice; I did not Find My Tribe
Various Agile champions within the corporation often find themselves stuck at “level 1.5”, in between the following two levels:
- “I found my voice/passion.”
- “I found my tribe.”
The Agile champion typically gets stuck at this level in the following manner:
- He/she finds his or her voice/passion in Agile.
- Various other folks in the corporation agree with him/her and constitute kind of “private tribe.”
- However, the folks that agree are hesitant to come out of the closet and throw their full weight behind Agile.
- The corporation remains ambivalent about Agile.
This “1.5” phenomenon is at the root of a vicious cycle that dilutes companies, particularly these days:
- A round of layoffs is implemented.
- Just about everyone takes notice and tries to exhibit the “proper behavior/values.”
- Folks in the “private tribe” don’t dare come out of the closet.
- 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.
- The company becomes more diluted on folks who are willing to try new things and have the drive to make them happen.
- The products and the supporting processes continue to be mediocre.
- Goto step 1.
IMHO The failure of many corporations to preserve Agile talent, and the resultant vicious cycle described above, is rooted in lack of appreciation how deep the connection between boredom and loneliness is. A young child does not know (nor does he/she have the vocabulary to express) what boredom is. The feeling the child expresses is that of loneliness. Only at a later stage does boredom get cognitively differentiated from loneliness. However, the two continue to be tied together emotionally.
Once the child grows up to become an Agile champion who found his/her voice, the boredom in the office is usually relieved. However, the twin sister of boredom – loneliness – cannot be satisfied through a “private tribe.” It requires full recognition and commitment within the corporation. In other words, it sort of demands that the corporation goes beyond recognizing the value (singular) of Agile and adopts the values (plural) expressed in the Agile Manifesto. If such adoption does not take place, an essential step to the formation of the tribe is curtailed . Without a full fledge tribe in his/her corporation, the induced feeling of loneliness sooner or later wears out the Agile champion.
This phenomenon, of course, applies to any professional passion an employee might pursue. John Hagel‘s Edge Perspectives post Pursuing Passion is a must-read for anyone who wonders how the corporation is impacted by losing the folks who got stuck at “level 1.5.”
Socializing Kanban with Your Executives
The topic Socializing Agile with Your Executives has been a major thread in this blog. A convenient to browse compilation of posts on the subject can be found in the Starting Agile category. In particular, two recent posts – The Business Value of Agile Software Methods and It Won’t Work Here – are quite specific on the data to use and the line of reasoning to follow in such discussions.
When it comes to socializing Kanban with your executives, you might choose to start the conversation by looking at the defect tracking system your company is using. Chances are your executive will “discover” the all important aspect of flow simply by examining the system with respect to some natural questions such as:
- Have more defects been closed than opened over the past month?
- What is the average time to close a reported defect?
- How many defects have been open (in one stage or another) in the system for more than a year?
- When a defect moves from one stage in the system to another, how does it get aligned with the various activities that need to take place in the release management system?
- If development and QA were to stop everything they do and just work exclusively on closing defects that have already been captured, could they clean slate in six months?
The power of this straightforward approach lies in the ease of making the mental jump from defect to Kanban in the context of the tracking system. The breaking down of an epic or a story to granular components that can be pushed to members of the Agile team is not always an easy concept to grasp (and often times a technique teams struggle with in the initial phases of an Agile roll-out). In contrast, one can simply visualize defects entered into the tracking system as inputs to a de-facto Kanban system. Obviously, the defect/Kanban maintains its identity as it “flows” through the system all the way from being reported by a customer to communication of its resolution to the customer.
If your defect tracking system does not easily lend itself to answering the questions listed above, you might try one of the public domain data sets from Mining Software Archives. The specific data, of course is not likely to be applicable to your company. The criticality of flow, however, could probably be demonstrated by making a few fairly straightforward assumptions on the operating environment behind the data.
The Agile Executive 