Cargo Cult Practices (post hoc ergo propter hoc)

It is very difficult to reach the sustained execution success of a high-performance, agile software development team.

Many bromides and quick-fix management practices are slapped together, and attempts are made to institute the best way^TM for a few weeks.  But soon, this panacea of the moment is quietly cast aside as the next breathless emergency distracts management from its commitment and sweeps the team into old habits and back to their comfortable, low-performance practices.  Profound and deep insight into these concepts are well-articulated in The Five Dysfunctions of a Team.

One cannot communicate the feelings each individual  on a high performing team has, and it is even more difficult to produce the settings, environment, chemistry, and conditions to achieve sustained high performance.  Most importantly, it is nearly impossible to use the “act as if” approach that is effective in many individual endeavors.

Self-proclaimed "agilistas" who strive for the actualization and group success of an enterprise by the application of the nuanced principles behind the agile manifesto are frequently frustrated by “scrum but” and the mis-application of scrum terms to the diametrically opposite practices.  One of the funniest, most-frustrating phenomena and dysfunctional misapplication of agile labels to team practices is cargo cult scrum.



Managers looking for a quick-fix send their teams to certified scrum master (CSM) training, refuse to “waste time” getting trained themselves as product owners or chickens, and sabotage their own success by completely perverting the process.  However these same managers expect great success and demand that their teams perform the meaningless rituals of scrum.  The thinking is as follows:

“That exemplar agile team over there has sustained high performance.  They practice scrum.  I need my team to be high performance.  If we execute the rituals we shall be high performing.”

This thought process is a perfect example of the logical fallacy “since event Y followed event X, event Y must have been caused by event X,” or more succinctly: “post hoc ergo propter hoc,” (after this, therefore because of this).  It is the cargo cult mentality and can be quite hilarious when you watch it unfold in a competing enterprise.  But when you watch it happening in your own organization it is exasperating.

What to do?

Phase in agile principles slowly, meticulously, patiently and relentlessly.  Think big and start small.

Start with the daily stand-up.  [link to my own blog entry inside eBay CORP] Get buy-in from everyone involved; iterate; be patient.  Improve the communication.  Ask the team questions to get them to discover and embrace the agile principles behind the purpose of the ritual.

Phase in the visual in-your-face workflow.  Point to it; ask the questions behind its purpose:  What can anyone else here do to move that higher-priority task to completion?

Retrospect, improve, constantly remind the team of their commitments and the principles behind the practices.

If you are an eBay manager or in a position of strong influence over a team, read my deck on “agile for managers.”