The Agile Executive

Making Agile Work

Archive for the ‘Companies’ Category

Connecting the Dots: Operational Excellence, Strategic Freedom and the Pursuit of Passion

leave a comment »

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:

  1. A round of layoffs is implemented.
  2. Just about everyone takes notice and tries to exhibit the “proper behavior/values.”
  3. Folks in the “private tribe” don’t dare come out of the closet.
  4. 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.
  5. The company becomes more diluted on folks who are willing to try new things and have the drive to make them happen.
  6. The products and the supporting processes continue to be mediocre.
  7. 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.

The Headlong Pursuit of Growth, and Its Aftermath

with 4 comments

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

with 7 comments

Various Agile champions within the corporation often find themselves stuck at “level 1.5”, in between the following two levels:

  1. “I found my voice/passion.”
  2. “I found my tribe.”

The Agile champion typically gets stuck at this level in the following manner:

  1. He/she finds his or her voice/passion in Agile.
  2. Various other folks in the corporation agree with him/her and constitute kind of “private tribe.”
  3. However, the folks that agree are hesitant to come out of the closet and throw their full weight behind Agile.
  4. The corporation remains ambivalent about Agile.

This “1.5” phenomenon is at the root of a vicious cycle that dilutes companies, particularly these days:

  1. A round of layoffs is implemented.
  2. Just about everyone takes notice and tries to exhibit the “proper behavior/values.”
  3. Folks in the “private tribe” don’t dare come out of the closet.
  4. 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.
  5. The company becomes more diluted on folks who are willing to try new things and have the drive to make them happen.
  6. The products and the supporting processes continue to be mediocre.
  7. 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.”

Written by israelgat

December 14, 2009 at 5:15 am

Double Wake-up

with one comment

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.

Predictability is Bad for Your Business

with 2 comments

I had the pleasure of meeting some old colleagues a few weeks ago. They work for a software company that pays a lot of attention to software engineering practices and invests heavily in software tools. Financial results, however, have not been great over the past few years.

Obviously, the disparity between the strength of the software engineering discipline and the relative weakness of the financial results is due to more than a single cause. One factor, however, was highlighted time and time again by my colleagues:

Predictability is killing us!

Paradoxical that this observation might seem, it is actually quite straightforward. Senior management in their company is really forceful about predictability. Hence, initiative, (affordable) experimentation and innovation have pretty much faded away. For most practical purposes it has become a check-the-box culture. All attempts to substitute reliable delivery for predictability seem to have failed so far.

One last “ingredient” to add to the story. This company is rich in talent. Generally speaking, the folks in the engineering trenches are gifted, knowledgeable, capable and dedicated.

How predictably poignant!

Written by israelgat

November 12, 2009 at 4:00 am

Teach Your Boss to be Agile with a Social Contract – Guest Post by Alan Atlas

with 4 comments

When I [Israel] joined BMC Software in Fall 2004, I made a promise to each and every one of the hundreds of employees in my business unit:

I commit to read and respond within 48 hours to any email you send me. My answer is not likely to be long as I am drinking from a hose right now. But, it will be substantive.

Till this very day, various ex-employees of mine tell me that this simple statement was actually the first step toward our adopting Agile – it created mutuality in our relationships. A few months later, when we started discussing the ground rules for Agile team empowerment, I was credible with respect to adhering to voluntary “contracts” due to the mutuality established in the “email policy” cited above (and other “it cuts both ways” steps we as a management team have taken along the way).

Fast forward five years to today. How delightful it was to get the guest post below from Rally coach Alan Atlas. His post has taken me all the way back to the very gratifying experience of starting the enterprise-level Agile “adventure” at BMC. Furthermore, Alan’s post made me realize I need to add mutuality as the fifth ingredient in my ‘secret sauce’ for large-scale Agile implementations.

Here is Alan:

Hey, how’re you doing? How’s the new Agile thing going? What? Oh, yeah. We had that same thing. The manager thing. Yep. It can be a killer! Wanna know what we did?

Dan Rawsthorne first introduced me to social contracts. He had put together an example that was called something like “Contract Between the Team and the Organization”.  Israel Gat’s work on Agile Social Contracts gives perspective on using them at the enterprise level.

I have put social contracts to good use more than once, and I am convinced that they are a tool that has much to offer to coaches, consultants, and maybe most importantly, internal Agile champions at companies around the world.

Most of us are familiar with the idea of Working Agreements. Working Agreements are a form of social contract that is often used to help a self-organizing team to establish behavioral standards without having them imposed from the outside (e.g., by a manager). Working Agreements are:

  • Established and changed by mutual agreement
  • Enforced by mutual agreement
  • Outside of established corporate legal structure, and
  • Made between peers.

A social contract, at least the way I have seen them created and used, is essentially a Working Agreement between non-peers.  In an Agile context, social contracts are written between a team and its management, or a team and its encompassing organization.

Of what use is an agreement in which each clause can be summarized as “I promise to do something that you want until I change my mind”? I think there are two really important benefits to be realized by using social contracts:

  • They codify and externalize the agreement, making the substance of the agreement clear, and
  • They form the basis of an “interaction between people” (i.e., a conversation).

Here’s an extract from a hypothetical Social Contract:

  1. The Organization and the Team agree that:
    1. Customer satisfaction is our ultimate goal
    2. Mutual respect will be the foundation for trust between all parties
    3. The Team promises the Organization that:
      1. It will develop the most valuable software, as defined by the Organization through the Product Owner, at all times
      2. It will provide transparency in all things related to its activities
      3. The Organization promises the Team that:
        1. The Team’s success will be judged by the production of working software
        2. The Team will have a Product Owner and a Scrum Master and a reasonable expectation of team stability

Yes, it does seem a bit idealistic and maybe even unrealistic. Yet, it is invaluable when used in the following way:

“Hey Boss. One part of launching the team on Scrum is to sit down with you and go over our social contract. Let’s take a look and talk about the things that are in here.”

The social contract is, above all things, a means to direct a conversation with your manager about roles and behaviors in the new world of Scrum. If you can all actually agree on one, and even sign it, Wow! But if you can’t, you can still use it to begin to teach your boss (I bet she wasn’t included in team Scrum training, was she?) how to be a good boss in an Agile world. If you are afraid of broaching certain subjects, arrange to have a neutral Agile coach supply you with an Agile contract, in which case you can’t be blamed for the content.

“The Organization promises the Team that impediments raised by the team will receive prompt and thorough attention at all levels.”

“The Team promises the Organization that it will adhere to all corporate quality standards when building software.”

“The Team promises the Organization that it will maintain the highest possible level of technical rigor through design and code reviews.”

And on and on…

Don’t be too disappointed if it never gets completely agreed and signed and put on the wall. Use it to open up a dialog with your management that you can build on over time.

Written by israelgat

November 5, 2009 at 7:46 am

Technical Debt Goes Generic

with 3 comments

Rally’s Richard Leavitt mentioned “his” technical debt in a conversation the two of us had last evening. As Richard is the head of marketing for Rally, I was expecting to hear about some deficit in the functionality, design, coding or testing of one of the market and customer facing websites his department deploys. I was dead wrong.

Richard was actually using technical debt in a generic sense. Anything in his department that they had to rush through and now plan to go back to and revisit/improve/fix is categorized as technical debt. The term applies to (say) laying the foundations for a marketing campaign as much as it does to re-architecting an application in order to improve its performance.

I don’t really know how wide spread the use of “technical debt” in this generic sense is. I am, however, impressed: another term of art is starting to get into the English language! How appropriate that such use of the term starts at a company that applies Agile values and practice to most of its operational and business processes.

Written by israelgat

November 4, 2009 at 2:58 pm

The Success of the Success Tour

leave a comment »

We started the 2009 Rally Agile Success Tour (AST) Series in March in Denver, CO; we just concluded it in London, UK. In between the AST “train” stopped at:

All in all we hosted about 1,000 participants in these cities. More than 40 panelists shared Agile experiences with their local colleagues. Some 200 meetings were held with various participants in conjunction with the events. Obviously, I cannot write here about the level of business generated by the success tour, but none of my Rally colleagues complained so far…

The breadth and depth of topics that were covered is mind-boggling. Here are a few of the most intriguing ones:

The success tour proved successful to a degree that actually perplexed me for quite some time. I had certainly expected a strong series of events from the outset and could point out to various things we were doing right along the way. Yet, the very simple ‘secret sauce’ that made the event series so remarkable eluded me until I collected my thoughts for writing this post:

The Agile Success Tour proved phenomenally successful because the Rally team is so much like the customers and prospects that participate in the events, license the Rally software and work hand-in-hand with Rally coaches.

A few words of explanation for what might seem on the surface like a somewhat banal statement. The various members of the Rally team – sales reps, coaches, technical account managers, marketing professionals and execs – resonated with participants in the events due to exceptionally high level of congruence in values, thinking and practices. If Ryan were the CTO of eBay he would probably have licensed Rally software; Jean would have re-architected the flow of eBay processes; Zach would have integrated the ALM tools eBay uses. As for Lauren, she would have single-handedly created a world-wide marketing events organization for eBay.

The power of being like your own customers is magnetic. Digital Equipment Corporation was immensely successful selling minicomputers to engineers like their own engineers in the 60’s and 70’s. Sun Microsystems rode the early Internet wave as their product designers were carbon copy of the folks who roamed the World Wide Web. Apple triumphed with the iPod because just about every Apple employee would have murdered for such a cool device. Nothing beats the intuitive understanding that comes with designing, marketing and selling the kind of product you will buy, play with and use yourself.

After the Santa Clara event, Forrester’s Tom Grant told me the following about Rally:

What a smart company – everyone gets it!

Though a slightly different perspective than mine, Tom had actually identified the outcome of the company-customer congruence I am highlighting in this post. Everyone at Rally gets it due to natural identification with his/her customers. Contexts and experiences of customers are exceptionally well understood and often replicated in Rally’s Boulder, CO headquarters and its various branch offices.

Fundamentally, the success of the success tour reflects the affinity between Rally and its clientele.

Scale in London – Part II

with one comment

What a grand conclusion for a year of Agile Success Tour events! High that my expectations of yesterday’s event in London were, the actual delivery and interaction with the participants surpassed them. As a matter of fact, I have not done as many customer 1-1’s in any of the previous events. Some of the interactions were with folks who came to the event from the continent. Remarkably, various customers stayed after the event to spontaneously dialog with other participants.

Speaking for Memex, Jim Mccumesty established the tone for the whole event. Agile to Jim is about:

  • Making a real difference
  • Changing patterns of individuals and teams
  • Transforming ‘life styles’

Have no mistakes – Jim had a lot of hard methodical and technical data that he shared with the audience. It was clear however that for Jim the whole things is about doing good things through Agile. His passion was contagious.

Trevor Croft viewed the decision to go Agile by Misys as a matter of fitting software methods to business circumstances. Agile was chosen to due to intrinsic characteristics of their Business Intelligence projects. Specifically, Trevor highlighted the following factors:

  • BI requirements would be constantly dynamic in breadth and depth
  • Needed to be quick to market from vision to delivery
  • Higher revenue –> emphasis on innovation
  • Break out of waterfall nexus of first trapping all requirements
  • Highly modularized factory production line approach for delivery

Trevor’s good points resonated with the trend highlighted by other panelists – the emphasis in Agile is moving toward:

  • Delivering the right products; and,
  • Delivering innovative products

Paul Lazarus of SpilGames equated Agile with growth. At the heart of it, SpilGame’s fast expansion from Holland to Poland and China was characteristic of the role Agile plays in the knowledge economy. Projects flow to the teams and to the talent, not the opposite way around.

David Hicks gave impressive highlights from the Nokia/Symbian/RADTAC work on the Symbian operating system over the past ten years:

  • >50 MLOC!
  • In a little over one year they are reaching the level of >1200 software engineers Agiling furiously in >120 teams
  • All these folks/teams on a single software product with synchronized release trains every 8-12 weeks

It is enlightening to combine David’s data with Dean Leffingwell’s reports on his experience at Nokia. The affinity of their insights is remarkable. Dean, in collaboration with Juha-Markus Aalto from Nokia, published an excellent paper on the subject. Moreover, Dean is actually ‘binding’ together his insightful blog posts to publish a new book entitled Agile Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise. The book will be published by Addison-Wesley in early 2010.

Much more could and should be written about the London event. Until I have the opportunity to do justice to the subject, I will just mention my overarching conclusion from the event. The business interest in Agile in both the UK and in EMEA is as strong as the one in the US, if not stronger.

More on the Social Contract

with 3 comments

The posts A Social Contract for Agile and Additions to the Social Contract established the dire need to reconstitute the social contract at a time when software development and test jobs migrate off-shore in an unprecedented manner. As stated in the first of these two posts:

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.

Colleague and friend Ryan Martens has just published an article on the subject in Dr. Dobb’s. Ryan examines the Agile Social Contact in the context of what it really takes to get Agile rolling. To quote him:

Can you see the simplicity of Agile Adoption when you apply appropriate commitment and structure? A truly effective Agile Social Contract that creates true trust and commitment requires clarity and discipline. With the transparency of a clearly communicated Agile Social Contract, you will establish a strong leadership mechanism that aligns all the stakeholders and teams within your Agile adoption. Of course Enterprise-scale agile adoptions take place in a larger context of the business and market. As Israel Gat stated in his personal Agile Social Contract, we cannot guarantee lifetime employment in this globally competitive world. But, by making a clear commitment to win-win agreements, we can change the conversation into a motivating one versus a de-motivating one. Don’t try to scale Agile without a real and personal commitment or without a clear rollout structure.

The fascinating thing to me is that Rally’s own social contract seems to have developed completely on its own. Best I know there had never been a conscious attempt to develop a social contract. Yet, the company is well-known for the strong affinity of its employees.

I will leave it Ryan to comment on this riddle…

Written by israelgat

October 27, 2009 at 3:26 pm