Author: matt.t.aaron@gmail.com

 

During World War II there were certain islands in the Pacific that the Americans and their allies would use as bases of operations. They would build landing strips, air traffic control towers, buildings and other necessary infrastructure.  These bases would allow for cargo to be delivered on a regular basis in order to keep the troops fed, armed and clothed.  The natives to these islands still lived in huts at this time and relied on the land and sea to provide for them.  They hadn’t seen modern technology until this time and didn’t quite know what to make of it.  They would stand at the fence of the military runway and watch as the cargo planes would fly in and out bringing the white men food and supplies.  They decided that these planes were being sent by their ancestors and the white men were stealing their stuff.  They decided that they needed to do the same things as the white men so that their ancestors would send the cargo to them instead.  So they cleared an airstrip in the jungle, they constructed an airplane out of bamboo and palm,  and they built air traffic control towers out of these same materials.  They even constructed earphones out of cocoanut shells.  They would paint themselves and try to dress as the soldiers did and would try to mimic their marching.  The natives would try to copy everything they could see the white men doing in the belief that by doing this they would receive the precious cargo from their ancestors.  This is what is referred to as the “Cargo Cult”.

As an Agile coach and an SPCT (Scaled Agile Program Consultant Trainer) I have the opportunity to work with companies at various stages of their agile transformation.  I often see “Cargo Cult” agile occurring in these companies on the agile teams.  The teams will have most (usually not all) the prescribed Scrum ceremonies such as Sprint Planning, Daily Stand-ups, and Retrospectives.  These teams call the pieces of work that they are doing “User Stories”, they size their work using Story Points or T-shirt sizes, they have some (usually not all) the Scrum roles such as Product Owner, Scrum Master and development team members, and they call themselves an agile team.  They are expecting to get the same great results (the cargo) that high performing agile teams get by just copying or mimicking the agile practices.  Most of the time they are having real difficulty delivering value, meeting commitments, maintaining a work/life balance and increasing quality.  Leadership is often frustrated and say to themselves and at times out loud “I thought this agile stuff was supposed to make us better”.  What both the Cargo Cult and these “Cargo Cult” agile teams are missing are the principles that bring the cargo or the great results.  Here are some of the behaviors to look for to see if you might have a “Cargo Cult” agile team.

• Not every team member has had Scrum/Agile training
• User Stories do not follow INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable)
• User Stories do not focus on the actual user of the system and are really just a big tasks
• Product Owner writes all the user stories including acceptance criteria without any input from the team
• Story Estimation is meant to be precise and takes a lot of time
• Definition of Ready does not exist or is not followed by the team
• Team brings user stories into the Sprint that do not meet the Definition of Ready
• Sprint Planning is about making sure everyone is highly utilized instead of a focus on frequently delivering value
• Lack of real commitment to Sprint goals and/or Sprint plan
• User Stories are accepted in the Sprint Demo and not as they are completed throughout the Sprint
• Sprint Demo is cancelled or does not occur
• Sprint Demo does not demonstrate working software
• Sprint Retrospective is just a complaining session without any actionable items placed in the team’s backlog for the next Sprint
• Manager and other non-team members come to the Sprint Retrospective
• Daily Stand-ups are status meetings given to the Scrum Master and not a team checkup on how they are moving the sprint goals forward
• Development team is just a group of individuals working on their separate stories or tasks and not working together to get value done
• Definition of Done does not exist or is not followed by the team
• Burn down of hours is the primary measure of progress instead of working software in the form of accepted user stories
• Velocity is the measurement of success instead of throughput of value
• Focus on outputs instead of outcomes
• Regular accounting is applied to innovation work instead of using innovation accounting
• Test automation is an afterthought and done by one individual or another team
• Quality is the QA engineer’s focus and not the team’s focus

I have seen the same type of behavior at companies that have “implemented” the Scaled Agile Framework.  Here is a list of behaviors beyond the teams to look for to see if you might have a “Cargo Cult” Agile Release Train.

• Not everyone on the train has had SAFe training
• Features / Enablers are not well defined and understandable by everyone on the train
• Features / Enablers do not contain benefits and acceptance criteria
• Features / Enablers are larger than what can be completed in a Program Increment (PI)
• System Architects do not work with Product Management and the teams and still define architecture in their ivory tower
• No System Architects
• Product Manager / Product Owner roles are played by the same people
• PI Planning is done in an agile tool with everyone glued to their laptop
• PI Objectives are not written
• PI Objectives are not given a business value
• No commitment by the teams or the train to the PI Objectives
• Program Board is not created
• PI Planning is done by only a subset of the members of the Agile Release Train
• Inspect and Adapt Workshop is skipped
• No actionable items from the Inspect and Adapt Workshop to improve the Agile Release Train are added to the Program or Team Backlogs
• Scrum of Scrums is not held
• Scrum of Scrums is not attended by all Scrum Masters or a representative of the team
• Scrum of Scrums is a status meeting for the RTE instead of an opportunity to synchronize and make sure that PI Objectives are progressing
• System demo is not frequently held nor held at all
• System demo is not a demonstration of working software and instead is a PowerPoint presentation
• Agile Release Train is just a group of individual teams working on their separate requirements instead of a team of teams working on delivering value to customers
• Team focus over team-of-teams focus
• Regular accounting is applied to innovation instead of innovation accounting
• The Agile Release Train only accomplishes less than 80% of PI Objectives after several Program Increments
• Business Owners and other leaders do not attend PI Planning or any System Demos
• Teams are measured against one another according to their velocity
• Focus on outputs instead of outcomes
• Focus on team utilization instead of getting highest priority value to customers as quickly as possible
• Team members are frequently added/subtracted from the teams
• Many of the team members are not 100% committed to the team or train
• PO Sync is not held
• PO Sync is held, but the purpose of reviewing progress and making decisions on scope adjustments based on economics does not happen
• Program Backlog is not prioritized using WSJF or prioritized at all

There are many more examples that I could give, but I believe you get the point.  You should ask yourself the question “Are we practicing Cargo-Cult Agile or Cargo-Cult SAFe?”  If the answer is “yes”, then it is time to go back to the values and principles.  Make sure that everyone has at least the knowledge of them and then make sure that the practices you have in place are reenforcing and realizing those values and principles.  As you have the knowledge around the values and principles and you practice them, you will gain the understanding you need to really get the benefits of Agile and the Scaled Agile Framework.

 

I was re-reading (actually listening to) the book The Five Dysfunctions of a Team by Patrick Lencioni and it made me think of the many Agile teams that I have come across or helped in my career.  Here are the five dysfunctions he mentions.

• Absence of trust—unwilling to be vulnerable within the group
• Fear of conflict—seeking artificial harmony over constructive passionate debate
• Lack of commitment—feigning buy-in for group decisions creates ambiguity throughout the organization
• Avoidance of accountability—ducking the responsibility to call peers on counterproductive behavior which sets low standards
• Inattention to results—focusing on personal success, status and ego before team success

 

Here are some signs of an Agile team’s “Absence of Trust”:

• Product Owner constantly challenges the team’s sizing saying she thinks the sizes are smaller or the team is sandbagging
• Scrum Master drills team members about individual tasks and burn down charts
• Team members refuse to do pair work
• Team members write defects pertaining to stories within a Sprint

 

Here are some signs of an Agile team’s “Fear of conflict”:

• Team members do not challenge one another on getting work to done
• Dev team members do not negotiate with Product Owner on scope
• Team members do not challenge the norm

 

Here are some signs of an Agile team’s “Lack of commitment”:

• Sprint goals and story acceptance are not met
• Retrospectives aren’t attended or valued by all team members

 

Here are some signs of an Agile team’s “Avoidance of accountability”:

• Do not want to give any dates or estimates
• Use words like “that wasn’t in the acceptance criteria”
• Continually do not meet Sprint commitments
• Do not hold a Sprint Review showing working software

 

Here are some signs of an Agile team’s “Inattention to results”:

• Individual utilization is more important than valuable finished work
• Having the attitude of “I finished my work so I am not to blame”
• Blaming team members for not doing “their job”
• Not making any changes in the next Sprint after not meeting commitments from last Sprint

 

What are some of the issues that you are seeing in your team?  This book is a great book to read as a team and then use the scorecard at the end to see how your team is doing with the five dysfunctions.  The audio version of the book is also good if you find yourself with little time to read, but a lot of time to listen to something.