Wednesday, May 23, 2012

The importance of the Primacy Effect for learning



I recently attended the Scrum Gathering 2012 in Atlanta.  During the gathering, there was a great Keynote from Clarke Ching.  The theme of his talk was "Focus".  The second part was “Multi-Tasking is evil”.  During the keynote, I noticed that Clarke used the Primacy Effect for his keynote and was intrigued.

Primacy is something I learned about as a flight instructor and is a mandatory concept for teaching others to fly in Canada.  It is important that we use the Primacy Effect to teach both ground schools and the in-flight lessons.  The more complex the topic, the more important this is.

I realized that same knowledge and experience from something that teaches complex decision making skills required to fly could be used when giving lectures or teaching where we want to show positive and negative ideas or concepts. 

From Wikipedia: “The primacy effect, in psychology and sociology, is a cognitive bias that results in a subject recalling primary information presented better than information presented later on."

In flight instruction, we are concerned about “initial” impressions and ideas (what goes into the brain first).  Often during a crisis situation, reversion takes place and the first learned action or idea is the one that overrides.  Therefore, if we’ve taught something with the “undesired” behavior or idea first, this could be potentially dangerous.  During stressful times, the default decision making is to use first learned knowledge as the brain processes ideas.

Don’t get me wrong here.  I am NOT suggesting that we should be deciding what is right and what is wrong.  This is FAR from the intention of this article! I am trying to give thought to teaching style for right and wrong type demonstrations, exercises, and teaching. 

I’ve seen many people say “don’t teach people right and wrong", yet still spend an hour doing a presentation to “prove” their “right way”.  Sometimes we find ourselves in a position to demonstrate or show two sides during a discussion. 

Many of us come from a “problem solving” mindset.  We feel a need to show the Negative activity first and then to “demonstrate” how much better it could be the other way.  We show or call out the problem, and then we then show the “better” way.  

The example used during the gathering was a demonstration of how multitasking could change simple tasks into complicated ones.  Quality was significantly decreased and the exercise was very stressful when done the “difficult” way.  Actually, even without the Primacy Effect, I think the learning went better than if the exercise had been done the other way around (my personal feeling).

Clarke made the decision to show the “Easy way" first and allowed the audience to do that first (Primacy).  He then showed what would happen by allowing the audience to do the exercise while multi-tasking ("Hard way").  The effects were dramatic.  The second round was noticeably more difficult than the first.  

By following the concept of the Primacy Effect, the “non-multitasking” option was entered into the mind first and would have to be “unlearned” first to switch to the non-desirable multi-tasking mode. When I personally think back to the exercise, I remember the first method.  I then search my memory for the second, not so easy way.

If you are doing a keynote or training a concept where you are trying to demonstrate a “right and not so right” to make a point, CONSIDER the idea of Primacy Effect to encourage better learning.

I acknowledge that sometimes you just have to put a big pile of problems there for someone to see to fix them.  I have to ask, what if you taught the smooth way first and then showed what would happen if you did not do that?  

If you have taken it upon yourself to “teach” a concept with your perceived right and wrong, then perhaps you might consider teaching your right FIRST, and then move to the anti-pattern(s) afterwards. 

I consider it to be more respectful to learners to go through what you think is correct first, and allow them to recognize the “wrongs” for themselves.  Perhaps, if you present the ideas to the students as something to think and talk about after the initial training, it might be more appropriate.

Trying to “hide” the “right” way you intend on miraculously sharing with them does not really support the idea of the Primacy Effect.  

I have regularly heard other agilists mention the "habit" of managers and team members during a crisis.  Perhaps the root of these habits is how the behaviors were originally presented.

Of course, everyone should do what they feel comfortable with.  I present this simply as an option for those of you who might be having trouble to get your ideas and concepts to “stick”.

I also wanted to thank Clarke for a great discussion about this idea during the conference.

Comments always welcome.

by Mike Caspar

References : 

Clarke Ching – http://uk.linkedin.com/in/clarkeching
Clarke Chings' - The Agile Experience: Multitasking Is Evil (which is not how he did it in Atlanta :->)
Primacy Effect - http://en.wikipedia.org/wiki/Primacy_effect#Primacy_effect
Transport Canada Flight Instructor Guide (PDF) – https://www.tc.gc.ca/media/documents/ca-publications/tp975e.pdf  (search for Primacy)


Sunday, May 13, 2012

Is Communication the correct word for Agile in the Enterprise?


I was recently in a discussion with some folks where the topic was the acceptance of Agile principles by managers and employees.  Several times during this discussion, "communication" came up in the context of letting people in the organization understand why they were going through an agile transformation.

A manager in the meeting made the following comment;  "We have emailed, had meetings and told everyone why we are doing this.  There will be no talking to them and asking questions from them about it anymore.  That would be a waste of time.  We have communicated with them already."

An enterprise does not necessarily have the same meaning for the word "Communication" as many of us might think.

When discussing Agile teams and projects with stakeholders, I often will say (I think incorrectly) something such as "An important part of your agile adoption is communication."

I recently realized, I may have been using the wrong word when discussing human interactions in an enterprise.   Perhaps the correct word should be "Dialogue", "Conversation", or as the agile manifesto simply put it "Interactions".

Often, large corporations have a separate "communications" department.  In some cases, there may be an entire division just for "Communication".  These folks have some very specific ideas of what communication is.

Communication
Communications has a responsibility to let employees know about new company initiatives, plans and direction.  They have a responsibility to do Investor news reports, company news for the press, and a variety of other messages.  Think of it as Outgoing Communication, or something with a sense of being Finished.  It has been communicated.... Period.

Don't get me wrong.   I've talked with many people in Communications and they are definitely folks who care about the feedback loop.  Occasionally, they may even get to do a survey, or if they are lucky, some focus groups.  Unfortunately, like other industries, they often don't get to do what brought them to the field in the first place.

Perhaps, teaching people in Communications about agile would serve an organization well.  In fact, I know they would really appreciate the incremental feedback loop. Maybe I'll discuss that in a future post.

When talking with stakeholders, we should stop saying that a fundamental part of agile is communication, and instead say something like, "For an agile adoption to be successful, it is extremely important to keep interactions between customers, managers, and team members active and alive".

The point here is that Communication is not what's important to emphasize.  It is dialogue, interaction, conversation, discussion, talking, chatting, collaboration or whatever word you want to use.

The word "Communication" has a very specific context in an enterprise...Use with caution.

Mike Caspar


References:
agile manifesto  - http://www.agilemanifesto.org