The Agile Executive

Making Agile Work

Archive for the ‘Innovation’ Category

The Three Faces of Innovation

leave a comment »

To succeed with innovation, you need to simultaneously address all three aspects:

  1. Affordable experimentation through the Agile process.
  2. Empowerment of (self sufficient) local teams.
  3. Let go of the hierarchical control concentrated in corporate headquarters.
Click here for details how hyper-segmented markets and a new breed of value chains transform the pre-requisites for innovating.
Advertisements

Written by israelgat

September 30, 2011 at 8:00 am

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.

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

Agile Across the Enterprise: Prioritizing Value in Support and Training – Guest Post by Anne Gentle

with 6 comments

If I could choose a subtitle to Anne’s guest post, I would pick How to Produce a Book in Five Days. While this subtitle does not take into account preparatory work prior to the five days, it captures the essence of the revolution in social publishing. The  intensive collaborative authoring that takes place during book sprints leads to hyper-productivity that transforms the economics of various classes of books.

A thread of particular interest in the post is the path innovation took. Anne walks us from Cote‘s simple question “Why does it take three days to get a PDF out for review?” all the way to producing over 250 pages of documentation in a book sprint. Her story is a great proof point that Experimentation Matters.

Here is Anne:

One of the Agile Manifesto’s basic balance equations is valuing working software over comprehensive documentation. This line of the Agile manifesto can be confusing to some supporting roles in an Agile development enterprise. As technical support staff, trainers, and content creators, what are we doing to fit into this Agile methodology, and what’s working well? Let’s explore some old habits that need to die, and some new rituals to fill that space.

Nowadays, Google’s search power offers software users access to documentation through forums, mailing lists, even through blogs and wikis maintained by the developers and authors themselves. These new conversational methods for documentation, support, and education have opened new opportunities for those groups to add value to software adoption. Ways to provide additional value to the working software include helping people learn the software, troubleshoot the software, or do their job with the software. Education, uptake, and support are all integral to the overall value of a software product.

Value proposition

First, a discussion on the value added by good websites, updated and relevant training materials, and a helpful support staff.  Those departments want to avoid the continual cost center perception. To do so, they find ways to add to the bottom line, such as:

  • increasing sales (enterprise) or increasing adoption (open source)
  • keeping users happy and satisfied
  • adding contributors to the community, whether helpful troubleshooters or prolific coders
  • decreasing support costs (in time and money)
  • converting participation into value
  • increasing positive perceptions of the software

In my experience, these values are universal to both enterprise software and open source software. Let me share my story.

Wikis are an Agile tool

I have been a technical writer on Agile development teams, and working in tightly collaborative environments has taught me a lot about adding value in the customer’s perception. I still remember being challenged by Michael Cote when we were at BMC Software. He asked, “Why does it take three days to get a PDF out for review? Why aren’t technical writers using wikis for documentation?” Those questions prompted quite a bit of research that finally resulted in my book, Conversation and Community: The Social Web for Documentation.

I had a lot to learn to answer Cote’s questions. What to do? I decided a wiki apprenticeship was the answer. At the time, wikis seemed to be the realm of open source software. I was nervous about approaching an open source project with so little experience in open source to draw from, but when a former BMC director sent out a call for help with the One Laptop per Child project, I responded. They had a draft started and we put it on the wiki.laptop.org wiki to start with, as a too-long single article on the wiki. Soon after, FLOSS Manuals approached OLPC to see if they would like to have FLOSS Manuals host the wiki on their wiki site at www.flossmanuals.net. Adam Hyde, the founder of FLOSS Manuals, had built a wiki tool that allowed multiple chapters to be output as HTML or PDF. When I saw what the tool could do, I jumped at the chance. We copied and pasted the entire manual into the FLOSS Manuals site. Yes, copy and paste. But it got the content into a platform that enabled much more agility for the content.

Book sprints are one Agile method

After that initial content seeding, we discussed holding a book sprint to create a better book for more audiences, especially since SugarLabs had formed an organization separate from OLPC to work on the operating system separately from the hardware. A book sprint, much like the Agile sprint term, is intensive collaborative authoring in a week’s time. We run sprints as a five-day event, and use real-time collaboration tools, and sometimes bring all the authors in to a single location and have a bullpen of sorts. Lots of planning goes into a book sprint prior to the actual sprint, such as identifying sources of content that can be repurposed for the sprint, agreeing to the audience for the resulting documentation, and writing an outline for the deliverable, whether it’s intended to be a textbook, a curriculum workbook, an online help system, or a website.

After a sprint planning session on the Sunday of the sprint week, authors are ready to start writing immediately because the outline for the book is set in the wiki. Often we outline with Post-it notes on the wall to start, a familiar sight to many Agile practitioners.

Monday, Tuesday, and Wednesday are heads-down writing days from about nine in the morning until an enforced stop time at six each day. Just like a stand-up meeting, we use a daily conference call to stay in touch with the handful of remote contributors and find out if anyone is stuck or has questions. Thursday is a day for assessing how much we have so far, and what final tasks should be done to make the sprint a success. Thursday night we intentionally plan for a fun event, as the writers certainly have experienced an intense effort like no other and need to have some fun and allow for a release of built-up pressure! Friday is a clean-up and review day, and the final PDF is uploaded to Lulu.com for creating a bound book. We can also export the wiki content to HTML, and either embed it on a website or ship it with the software product itself. In the book sprint for OLPC and SugarLabs, we produced over 250 pages of documentation. You can learn more about book sprints (including examples of the budget for this sprint) by reading the free chapter from my book, or by reading the book about Book Sprints hosted on FLOSS Manuals.

In my journey towards Agile value-add across the enterprise, I learned that wikis are much more likely to be used internally for collaboration, and that there are far fewer examples of wikis where customers and Agile team members are collaborating on training materials, tutorials, reference information, or strategy guides for enterprise software. To shift that adoption rate towards external collaboration, I’m interested in book sprint experiments in the enterprise, as well as additional collaboration methods. Along the way, I’m finding ways to transfer lessons learned in open source to corporate environments. I offer this story as one way that Agile methods applied to other departments and their processes can increase overall value to the software developed.

About the author: Anne Gentle works as a senior technical writer at Advanced Solutions International in Austin, Texas on an Agile development team. She just finished a book with XML Press about using social publishing techniques for technical documentation titled Conversation and Community: The Social Web for Documentation. She volunteers as a documentation maintainer for FLOSS Manuals, working on manuals for One Laptop Per Child and SugarLabs, both education projects dedicated to providing technology for children in developing countries. She writes a blog at justwriteclick.com and welcomes feedback and conversation there. As the mom of two young boys, she loves to be busy while upholding the value of an Agile principle of individuals and interactions (and sometimes refereeing battles over toys).

The Changing Nature of Innovation: Part II — National Policy

with 4 comments

Michael Porter makes two interesting observations about innovation in the US in his BusinessWeek interview entitled Why America Needs an Economic Strategy:

… U.S. entrepreneurship has been fed by a science, technology, and innovation machine that remains by far the best in the world. While other countries increase their spending on research and development, the U.S. remains uniquely good at coaxing innovation out of its research and translating those innovations into commercial products. In 2007, American inventors registered about 80,000 patents in the U.S. patent system, where virtually all important technologies developed in any nation are patented. That’s more than the rest of the world combined

In contrast to the effectiveness of utilizing research and technology for entrepreneurial purposes, Porter notes a worrisome trend:

An inadequate rate of reinvestment in science and technology is hampering America’s feeder system for entrepreneurship. Research and development as a share of GDP has actually declined, while it has risen in many other countries. Federal policymakers recognize this problem but have failed to act.

Viewed in light of Part I of this mini-series on innovation, a natural question posts itself:

Do the new forms of experimentation, which enable the US entrepreneurial system to be so very effective in coaxing innovation out of research that has already been done, mask a fundamental decline for which there will be hell to pay?!

Written by israelgat

November 24, 2009 at 5:30 am

The Changing Nature of Innovation: Part I — New Forms of Experimentation

with 4 comments

Colleague Christian Sarkar drew my attention to two recent Harvard Business Review (HBR) articles that shed light on the way(s) innovation is being approached nowadays. To the best of my knowledge, none of the two articles has been written by an author who is associated with the Agile movement. Both, if you ask me, would have resonated big time with the authors of the Agile Manifesto.

The February 2009 HBR article How to Design Smart Business Experiments focuses on data-driven decisions as distinct from decisions taken based on “intuition”:

Every day, managers in your organization take steps to implement new ideas without having any real evidence to back them up. They fiddle with offerings, try out distribution approaches, and alter how work gets done, usually acting on little more than gut feel or seeming common sense—”I’ll bet this” or “I think that.” Even more disturbing, some wrap their decisions in the language of science, creating an illusion of evidence. Their so-called experiments aren’t worthy of the name, because they lack investigative rigor. It’s likely that the resulting guesses will be wrong and, worst of all, that very little will have been learned in the process.

It doesn’t have to be this way. Thanks to new, broadly available software and given some straightforward investments to build capabilities, managers can now base consequential decisions on scientifically valid experiments. Of course, the scientific method is not new, nor is its application in business. The R&D centers of firms ranging from biscuit bakers to drug makers have always relied on it, as have direct-mail marketers tracking response rates to different permutations of their pitches. To apply it outside such settings, however, has until recently been a major undertaking. Any foray into the randomized testing of management ideas—that is, the random assignment of subjects to test and control groups—meant employing or engaging a PhD in statistics or perhaps a “design of experiments” expert (sometimes seen in advanced TQM programs). Now, a quantitatively trained MBA can oversee the process, assisted by software that will help determine what kind of samples are necessary, which sites to use for testing and controls, and whether any changes resulting from experiments are statistically significant.

On the heels of this essay on how one could attain and utilize experimentally validated data, the October 2009 HBR article How GE is Disrupting Itself discusses what is already happening in the form of Reverse Innovation:

  • The model that GE and other industrial manufacturers have followed for decades – developing high-end products at home and adapting them for other markets around the world – won’t suffice as growth slows in rich nations.
  • To tap opportunities in emerging markets and pioneer value segments in wealthy countries, companies must learn reverse innovation: developing products in countries like China and India and then distributing them globally.
  • While multinationals need both approaches, there are deep conflicts between the two. But those conflicts can be overcome.
  • If GE doesn’t master reverse innovation, the emerging giants could destroy the company.

It does not really matter whether you are a “shoe string and prayer” start-up spending $500 on A/B testing through Web 2.0 technology or a Fortune 500 company investing $1B in the development and introduction of a new car in rural India in order to “pioneer value segments in wealthy countries.” Either way, your experimentation is affordable in the context of the end-result you have in mind.

Fast forward to Agile methods. The chunking of work to two-week segments makes experimentation affordable – you cancel an unsuccessful iteration as needed and move on to work on the next one. Furthermore, you can make the go/no-go decision with respect to an iteration based on statistically significant “real time” user response. This closed-loop operational nimbleness and affordability , in conjunction with a mindset that considers a “failure” of an iteration as a valuable lesson to learn from, facilitates experimentation. Innovation simply follows.