Jul 312012

Has agile crossed the chasm? Unambiguously: yes and no. To apply the concept of Geoffrey Moore’s book, we must first answer the question, “Is agile a disruptive technology?” To me, that answer is yes. If you do not agree, this is a good stopping point.

Next, we must answer the question in regards to the market. Let us first focus on the software industry, both software product companies and IT. Then we can answer the question: yes, agile has crossed the chasm, from the perspective of the total addressable agile market. Certainly, mainstream has adopted agile. Traditional manufacturing organizations such as Caterpillar, Boeing, and Ford use agile methods. Insurance companies like Farmers, United Healthcare, and State Farm use agile methods. Financial companies such as Capital One, Fidelity, and Wells Fargo use agile methods. Government agencies, including NASA, the FBI, and the US Department of Defense and their vendors, all use agile methods. These lists are not the exceptions. It is now normal to have some agile methods in any company but the laggards. For many companies, like those listed above, agile projects represent less than 20% of total expenditures. But do people do agile well? Generally, mainstream companies that have adopted agile will have pockets of agile that do well. Conversely, this also means many aren’t doing agile well.

So, if the total addressable market has crossed the chasm, where are we on the technology adoption curve? I’d say that we are near the crack between early adopters and late majority. The market for agile is well developed at this point. Evidence of this can be found in the explosion of agile consultants, coaches, trainers, certifications, and analysts supporting agile. Further, demand for these services outstrips supply. From the total addressable market perspective, agile has crossed the chasm and is migrating from early to late majority even though companies generally do not do it well. Thus, we face the problem of technology competence, an indicator that we are in “the mainstream.”

If we change our viewpoint and define each organization as a market segment, then from this view, few have crossed their own chasm. Within organizations, there are different market segmentations and thus different realities. Agile certainly has begun to disrupt, but the organization struggles to adopt the technological paradigm. Here, the technology adoption curve is different. Agile takes a different form. For the early majority to truly adopt agile, much more has to be given up. People must fundamentally change their perspectives, learn new approaches, and unlearn many of the truths they once held as self-evident, as Israel suggests. To make matters worse, unlike technologies such as the personal smartphone, crossing the chasm in agile is not about self-discovery. Instead, we must collectively navigate the world we do not understand by actively changing the world we know. If agile weren’t so disruptive, it would never have a chance.

Consider Yahoo! as an example of an organization with some great agile teams; they can respond quickly and deliver incredibly well. Yet there are also entire groups at Yahoo! that will say that agile has failed spectacularly. Within this company, few would say it has crossed the agile chasm. In other words, Yahoo! has not been able to take advantage of what agile has to offer because the company itself hasn’t increased its business skills enough to support agile technology. While I would never say that lack of agile is the only reason for the challenges Yahoo! faces, the competencies required to take advantage of agile do relate to the company’s bigger problems. Thus, Yahoo!’s position skirts the chasm between early adopters and early majority.

So, from a total market perspective, agile has indeed crossed the chasm. Yet, we now must face the burden of the heavy lifting required for organizations to take advantage of this new technology so that they can cross their own chasms. Importantly, the signatories of the Agile Manifesto came to agreement on the following success factors at the 10-year anniversary of its writing:

  • Demand technical excellence.
  • Promote individual change and lead organizational change.
  • Organize knowledge and improve education.
  • Maximize value creation across the entire process.

Every organization today can be comforted like never before since agile is now mainstream and thus better understood. But beware: the chasm in your organization may still be in front of you.


Brent Barton

Brent Barton applies agility, pragmatism, persistence, organizational constructs, and process disciplines to help organizations outperform their status quo.


  9 Responses to “Agile Has Crossed the Chasm, Agile Hasn’t Crossed the Chasm”

  1. Brent,

    nice article, but agile is much older than the agile manifesto. In the beginning of IT there was agile, waterfall came later when the ammount of non documented and unmanaged code was just getting too large. Waterfall then created longer time to market, usually much too big implementations with more magers then doers and much too costly.

    I personally think that this will go unless people get honest and accept the following formula:
    Take the following 5 areas that are constantly fighting against each other and always will and assign them percentages on importance totalling on 100 % Quality Dependability Speed Flexibility Cost . Then go and spent only the time and effort on each you assigned. The problem is that many IT mangers want 500 %, which is just not real.

    • avatar

      Hi Cay,

      Thanks for the comments. I agree that agile in many forms existed from the beginning, thus agile is evolutionary. One of the biggest issues with Agile I hear in practice is “no documentation.” My experience is that COBOL made this mainstream with its “self-documenting” structure.

      I like your quality attributes. I am not sure I would choose only these when considering which things to do and applying budgets to them though.


  2. Good overall article. I believe the points about the organizational challenges are more about the need for a culture change rather than a technology change. Some companies believe they are succeeding in agile methods due to the use of Scrum or Jira, yet they have not yet adopted a culture that values people and quick value delivery. This is likely where the chasm must be crossed, and why a company can have successful teams but not a successful agile culture.

    • avatar

      Hi Evan,

      I totally agree. An agile culture is more important than technology.

      On the other hand, I find that many organizations are challenged because they cannot get the technical feedback they need to inspect. When this happens, delays can occur. These issues compound and after problems are discovered very late, it feels like un-managed waterfall to managers. Agile teams that have well-covered code (with the right balance of tests) and run a Continuous Integration environment who must integrate with other waterfall teams usually help make integration far less painful and benefit all teams.

      – Brent

  3. avatar

    The title of the article really caught my attention because I am big fan of Geoffrey Moore. This is a nice article which really hits on the notion that “People must fundamentally change their perspectives, learn new approaches, and unlearn many of the truths they once held as self-evident”. However, the word “technology” as it refers to Agile is perhaps inappropriate, ie, “Yet, we now must face the burden of the heavy lifting required for organizations to take advantage of this new technology so that they can cross their own chasms”. Or as stated in the beginning ““Is agile a disruptive technology?”.
    Agile is not a technology, it is a product develpment framework.

    • Hi Farid,

      Yea, I struggled with that very definition and application of Moore’s work to Agile. After a fair amount of research, I found numerous applications of “Crossing the Chasm” applied to non-productized systems that I considered valid. The disruptive technology I refer to is the entire set of values, principles and practices Agile addresses. I kept the word “technology” to remain consistent to the Moore’s arguments.


  4. I am not sure if the author intended this, but I took he was saying that Lean and Agile are the same. I wonder about this because Boeing and Ford are well known for having adopted Lean, not for having adopted Agile. Perhaps they are using Agile as well, but it is Lean that has made them more successful. I hear this all of the time in the Agile community. Lean and Agile are far from the same and not entirely consistent with each other.

    When one talks about crossing the chasm, one must be clear about which chasm. Agile has definitely crossed the team process chasm. Many many teams are now using Scrum (the most popular and somewhat generic form of Agile). However, few companies have successfully adopted Agile across the organization. As far as I know, all that have have either done so under the mandate of a CEO or used Lean as guiding their efforts. This is not a coincidence as popular Agile methods, Scrum in particular, do not embrace management as a useful role – but tend to be neutral to it at best, shunning it at worst.

    So, I think there are two chasms here – the more important one -Agile at the organizational level, is still in the early adopter phase. In this area, I believe Lean will have success well before Agile does – which is why I feel it is important to make a distinction between the two.

    I have written several blogs on the distinctions between Agile and Lean. You can find them at http://www.netobjectives.com/blogs

  5. Thank you for the interesting article. I agree with Farid in that I too am a huge Geoffrey Moore http://www.geoffreyamoore.com fan. He has seemed to me like a modern day guide showing us the territories with is maps (frameworks) so that we can traverse them with some sense of what will be there rather than going in blind. I agree with you in your application of Geoffrey Moore’s work to agile. Many people consider Geoffrey Moore’s work only to apply to tech companies, but I feel that his frameworks can be applied to almost any methodology with only minor adjustment. Thanks again for the interesting article.

  6. Thank you for this note. We have a long way to go before Agile is mainstream. Based on my experience the last ten years – a VERY long way. Herewith two statements from an RFP Questions Response document open on my desktop at the moment:

    “Yes, the Software Development Plan must be finalized before actual software development begins”

    “…it is preference that an agile software development methodology be used”

    One might quibble that it is possible to create a Plan and still be Agile, but let me assure you that having read the rest of the document, this would be a gross misinterpretation of the purchaser’s frame of reference.

    In another embarrassing example, one of my staff told me this morning that the project he just finished was done with Extreme Programming – because no discipline existed whatsoever, the only environments were dev laptops and prod, at the end a few people worked days non-stop, and the customer was playing dev lead – going so far as editing code until the day it dropped to prod. Now, admittedly he’s just a UX guy, but… Yikes, shoot me now!

    Please, continue writing and communicating with stakeholders of software development. The insanity has to stop.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>