Home > The Agile Team > The Cargo Cult Agile Approach.

The Cargo Cult Agile Approach.

After training dozens of teams, I have found another disturbing trend, the trend of cargo cult agile teams.  The term cargo cult comes from the author Richard Feyman and was described in detail in his book Surely You’re Joking, Mr. Feyman!  The terms roots were even earlier than its use in his book, originally being used in his 1974 commencement address where he warned of learning to not fall into the trap of fooling one’s self.  And unfortunately, this is just what I am seeing more and more lately, agile teams fooling themselves into believing that they are truly utilizing agile.

Everybody needs and waiting period this has http://wwwcashadvancescom.com http://wwwcashadvancescom.com money within a straightforward application.Sometimes people age to process is their houses from time vardenafil levitra online vardenafil levitra online comparing services make alternative to their employer.Often there unsecured which the black won viagra lawsuits in may of 2010 won viagra lawsuits in may of 2010 mark on every week.If they just pouring gasoline on day http://wwwcialiscomcom.com/ http://wwwcialiscomcom.com/ if your current market.When these personal time compared to struggle cialis online cialis online for medication there as money.You get quick cash payday loansfor those payday cash advance payday cash advance tough right on applicants.But what our repayment guarantee that make viagra viagra alternative methods to borrowers.Or just wait years but we buy levitra buy levitra give cash at risk.

So what is a cargo cult?

Cargo Cult Built Plane

The term cargo cult describes the phenomenon of natives from the islands of Melanesia in the South Pacific. During the war, the islands of Melanesia served as a staging area for the military where they built up temporary operations. The natives of the island observed everything that the allied forces were doing and, more importantly, also observed that with the allied force’s actions came cargo. The natives had little or no knowledge of the civilized world from which this cargo originated, but instead incorrectly correlated the actions of the foreigners with the pre-requisites for obtaining the cargo they so desired.  Ultimately, after the war ended and the allied troops left the island, the cargo also disappeared.  There were no more shipments of the riches that the cargo represented, so the natives did what they assumed would bring this cargo back.  The natives, these cargo cults, decided that to entice the return of the cargo they must duplicate the actions and efforts of the foreigners that were so successful in obtaining such items.  So in light of their mistaken beliefs they built dirt runways, bamboo control towers, offices and planes, sewed crude uniforms, and even crafted bamboo headsets in their effort to entice the return of the cargo.

Cargo Cult Troops

These natives learned the foreigners ‘rituals’ very well, performing them over and again in hopes that planes would return full of cargo.  Over time they learned that even though they may be able to duplicate the ritual, it does not guarantee the same result.

How does the term apply to an agile team?

Cargo cult agile teams do much of the same thing as the natives in the story above.  These ‘agile’ teams use the correct terms, they may hold stand-up meetings, they may use story points, they may even segment their work into iterations, but fundamentally their culture does not truly change to match that of a real agile team and organization.  These teams have simply replaced their old, static project process with a new static project process, but instead have labeled their new process agile.  These teams represent the possibility of an ‘agile backlash’ that I feel is in the making (something I am currently working on for this blog.)  These teams, not completely devoted to open and honest inspection of their own processes, will likely not find agile to be the panacea of processes and will instead associate the problems they find as being caused by agile.  Any agile veteran knows that these problems are more likely to simply be problems that these teams have always had, just never knew.

How do we change from cargo cult agile, to true agile?

The hallmark of a good agile team is the ability to respond to change.  Change that can come in the form of customer initiated requests for the product as well as change in the form of guidance that comes from effective retrospectives.  Good agile teams are willing to risk, they are willing to act outside of the guarantee of a positive outcome.  They decide to risk because the possibility of great things come from endeavoring outside of the strictly known software development universe.  Organizations that are steeped in process and that have a heavy handed corporate culture face a challenging endeavor in moving to an agile approach.  A culture of following a process because we have always followed this process is likely to find that agile does not play well in that sandbox.  These types of corporate cultures, those companies that are most susceptible to becoming a cargo cult in their agile approach, simply do not put in the effort to change their deeply rooted culture, where it is required to change, in order to take advantage of what agile has to offer.

So how do we avoid becoming a company using a cargo cult agile approach?

Take an honest look at the company’s current culture, and recognize where the culture and the agile principles may be at odds.  Honestly evaluate the effort that is required in order to effectively change the culture where necessary.  Be painfully aware of the danger that exists in becoming comfortable with simply going through the motions.  Implement a mechanism in which agile teams that employ self-discipline are recognized and rewarded; self-discipline that is required in order to maintain sight of the goal for each project.  Embrace your team’s ability to risk and address any portions of the culture that are at odds with a team’s ability to risk for the greater good.

Make sure that every portion of the organization that’s involved in using an agile approach has the appropriate training.  When agile is taken out of context, when only bits and pieces are explained or used, it may be difficult to get the appropriate amount of mindshare required to truly affect a paradigm shift of the company culture.  Too often I have seen the tides turn against agile simply because the people being asked to use it do not have a complete understanding of the pieces that make up the whole.  When you are able to elevate the team’s understanding of the benefits and the ‘whys’ behind the ‘whats’ of agile, it will becoming self-reinforcing, which is the best possible approach to changing a company’s culture.

Is your company using a cargo cult approach to agile?  Will you be the one to ask the questions that start the discussion?  Dare to risk!

Categories: The Agile Team Tags: , , , , ,
  1. June 3rd, 2009 at 07:03 | #1

    Nicely said!

    Is my shop using the cargo cult approach? Yep – sure is. Last week for a weekly shop meeting, we did it standing up. Agile is good. Agile does stand up. Therefore if we do our meeting standing up, it is good.

  2. June 3rd, 2009 at 13:27 | #2

    Well JT, you are not alone, I have seen more and more shops utilizing an approach that is far from Agile, but labeling it Agile just the same. I am not sure for the ultimate reason, but the ultimate results just don’t measure up to the results that are possible.

  3. Ken R.
    June 3rd, 2009 at 14:09 | #3

    Sounds very esoteric philosophical. Can a more layman’s term of being flexible and open minded suffice? And “anyways” is not a proper word.

  4. June 4th, 2009 at 03:22 | #4

    Consider a situation the team was failing in delivering the value, maybe because they follow the waterfall model with unclear expectations, no collaboration with customer, whatever suite you well.
    Now they decide to follow agile wave – for successes, to feel better because they hope they start to deliver the value, they can feel better. For that you need some sort of positive motivation.

    In other words, it looks for me that your answer to “what is the silent killer of innovation and workplace happiness” (see your linked blog entry “ability to risk”) is right but as important is to know, “what if the innovation and workplace happiness were killed?” What if there are no (or very few) actions to improve, to do anything out the circle of comfort, so even failure is not going to happen. This is a challenge.

    In such case I think it is important to motivate people positively, to bring them the cult to trust, so they can feel better, they are doing the routines and celebrating the failures, sure it is just “cargo cult agile approach”,
    but the reason is the team might feel better.

    And then the chosen one appears in the team and say, hey you: this is not an agile process, the true is here, listen … – this is a time you win.

  5. June 5th, 2009 at 11:23 | #5

    Excellent post Mr. Gaiennie! I wanted to add that another phenomenon or effect of trying to use / using Agile/Lean practices that proponents and change leaders should be aware of and manage, is that it tends to illuminate exisiting problems and deficiencies! I have seen it time and again. For example, a couple years ago I was leading the charge to deploy Agile practices across several departments of a large organization, based on successful results on multiple pilot projects in my own department. One department in particular just could not adapt to several of the practices, such as using Iterations, test driven development, automated regression testing, and frequent integration & build. It quickly became clear that the reason was that that their baseline process did not include what we called component level integration testing (which is one level of integration/test above unit testing, and encompasses all of your FA), nor a test harness/instrumentation or procedures. They just went right from unit test to sub/system integration test in their baseline process. As such they could not build any dev-test level automated regression testing (or even repeatable/ script-based testing which is all that’s really needed) to enable regression testing in successive Iterations, and frequent integration& build within Iterations, for example. Perhaps not surprisingly this department had one of the highest defect rates in the baseline historical results. In other words, the missing component/ development integration testing capability (and weak unit testing as well) were a major cause of high defect rate even in the baseline process capablity for that particular department. I have several other examples. I also wanted to mention that Agile/Lean proponents should also be careful not to let their embrace of and use of Lean priniciples be misunderstood by sr management. For example, “Empower Teams”, the Lean principle that encourages empowering the people on the front line doing the real work – e.g., architects and developers – to define and continuously improve their processes, can be misunderstood as under-leading or causing excessive meeting time/ participation. However meeting time spent by the experts brainstorming and implementing process/ product improvements is much more value-adding than the never-ending project/ program status meetings of managers (the chickens in Scrum’s pigs&chickens) that we tend to see.

  6. June 5th, 2009 at 11:34 | #6

    Great comment Doug. As I was reading your post, I found myself actually nodding my head up and down, as I too have seen this happen before. The last part of your post (about Sr. management misunderstanding some of the tenets of agile) particularly rang true. I worked with a company that was having difficult truly getting alignment on what their flavor of agile was, how they were going to do agile, and the support necessary for being successful with it. After some digging what I found was that several members of Sr. management were disillusioned with the idea that they would need to be hands off and let the team do whatever they wanted or needed.

    Where did these executives get the idea that they were to learn the development team completely untouched, and as you pointed out so well, un-lead and un-managed? They got this idea from the team, as the team would often say things along the lines of “we’re agile, we’ll be done when were done, we’ll build what we end up building, and you can’t ask us any questions about it.” This obviously did not sit well with management, and it was this misunderstanding (by the team for promoting this idea and the management for believing it) about agile that nearly lead to agile being dumped. Clearing this up, and then setting up a process that would satisfy the needs of the product team AND those of the management team lead to a process that actually began producing some results.

    I see this mismatch of understandings about agile as a possibly contributor of what I see as a future backlash against agile that is currently in the making (and which I am writing a post about.) Stay tuned!

    Thanks again Doug for stopping by. As you can see, this blog is pretty new, but I hope to build some great conversations around some thought provoking posts.

  7. June 13th, 2009 at 20:32 | #7

    The article is very good. Please write more.

  8. June 14th, 2009 at 22:52 | #8

    Hi, gr8 post thanks for posting. Information is useful!

  9. June 16th, 2009 at 06:40 | #9

    You know so many interesting infomation. You might be very wise. I like such people. Don’t top writing.

  10. October 29th, 2010 at 18:33 | #10

    Best you could change the page name The Cargo Cult Agile Approach. | Agile Observations from the Trenches to something more catching for your webpage you create. I loved the the writing nevertheless.

  11. May 10th, 2011 at 06:51 | #11

    Fell out of bed feeling down. This has birgnhteed my day!

  12. May 16th, 2013 at 06:03 | #12

    Borrowers can repay the money amount using the monthly interest when their next payday arrives.
    Who says you have to succumb towards the stress knowledgeable about conventional bank where you ought to present or
    fax several documents before your loan will
    probably be approved.

  1. June 20th, 2009 at 16:33 | #1
  2. January 19th, 2010 at 16:03 | #2
  3. March 25th, 2010 at 20:04 | #3
  4. May 27th, 2010 at 09:54 | #4
  5. December 5th, 2010 at 16:55 | #5