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.
It Won’t Work Here
Two major obstacles to vetting Agile topics effectively with executives were identified in the post entitled The Business Value of Agile Software Methods:
- Lack of hard quantitative data.
- 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:
- Uniqueness: “Some very unique elements exist in our company. These elements render industry data inapplicable.”
- 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.”
- 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.”
- Affordability: “The company is strapped to the degree that investment in another software method is a luxury it can’t afford.”
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.
Double Wake-up
Computer Associates and Salesforce made the following announcement a couple of weeks ago:
SAN FRANCISCO – Salesforce.com Dreamforce Conference – November 19, 2009 – CA, Inc. (NASDAQ: CA), the leader in Enterprise IT Management, and salesforce.com (NYSE: CRM), the enterprise cloud computing company, today announced they have partnered to deliver agile development management in the cloud on the Force.com platform. Through the alliance, CA and salesforce.com intend to introduce CA Agile Planner on Force.com to help small businesses and enterprises alike accelerate development timelines while gaining control and visibility over 100 percent of their development initiatives. The intended result will be increased innovation and reduced time-to-market.
Following an e-conversation on the subject with colleague and friend Annie Shum, I would characterize this announcement as a Double Wake-up:
- To the premise of Agile methods; and,
- To the premise of Cloud Computing
How appropriate it is that Annie has recently posted in this blog on the two threads coming together - Cloud Computing: Agile Deployment for Agile QA Testing.
