Tuesday, October 28, 2014

Hotels, anonymity, and peace

Random hotel thoughts. Sitting here in a hotel at UNC Chapel Hill, in town for the Scrum Coaching Retreat, I get this funny sense of peace and security.

It's like once that heavy door shuts, with its reassuring clunk, the world goes away. Not really, of course, but it feels that way sometimes. To think - no one else here knows where I am, and few know who I am.

It's unusual in life to be able to have nearly complete control over interactions. In a hotel, no one can really bother you unless you choose to.

Maybe I'm just strange. But I find it to be a unique and fascinating aspect of travel. 

Sunday, April 28, 2013

Training in India - The feedback cycle

Over the past couple years, I've traveled to India three times, and visited three different Indian states.  Now, that's far from a large amount of experience with India - it's paltry when you consider there's coaches and trainers that are here several times a year for weeks at a time.  But, at least through my limited experience, I've been able to form some limited observations and I've learned a lot.  As I write this post, I'm sitting in a hotel room in Chennai, on India's East coast.

My teaching style tends to involve a lot of feedback loops - I'm teaching Agile after all - so I like to introspect, retrospect, and modify my content as I go.  Every class is a little different.  Some are a LOT different.  It's a matter of who the people are that are taking the class, their organizations, and learning styles.  And I always try to add something new and interesting each time I teach - as much for the benefit of the class as for my own.

The point of mentioning this feedback mechanism is this: It doesn't work very well here.  I tend to ask things like "Does that make sense?" or "What do you think?"  Those questions are very often met with a deafening silence when training with Indian teams.  Up til recently I didn't understand why.  I often even took it personally; I thought that I either wasn't being effective, or that the classes didn't like me.

Lately, though, I've had the opportunity to watch a colleague of mine present training as well.  The breakthrough came when he asked the same questions and was met with the same silence.  I thought, then, that perhaps it wasn't my fault - or at least not entirely.  I should also mention that my colleague (who I will give credit to, if he agrees) is Indian - he was born here, but now is a permanent US resident.

In my quest to learn what I was doing wrong, and more about Indian culture in general, I began to read.  The first book that I started with (and I'm still reading - but I was so impressed by the message that I decided to write about it already) is Speaking Of India by Craig Storti.  This book, as you might infer from the title, deals with communication - specifically, communication between Indians and Westerners, as well as between Indian folks themselves.

Here's what I found interesting....the answers to my feedback failure were clearly laid out almost immediately.  I had known some of this before, but only informally - but now, here was the detail and the reason.

A cultural difference between Indians and Westerners is the way that we give what could be perceived as negative feedback - or, in this case, the fact that Indians don't. Indians do not like to give negative feedback at all - it constitutes a loss of face and embarrassment to the recipient.  Indians are far more empathetic than their Western counterparts - they care much more about how others feel. So they avoid hurting the feelings of others by giving negative feedback.

Ok.  So no negative feedback.  But why would that interfere with retrospective training feedback?

The missing piece was this; By saying that they didn't understand a particular piece of training, the Indian trainees would, in effect, be giving negative feedback about the instructor.  By their misunderstanding, it reflected negatively on the teaching skills of the instructor.  Wow - I never thought of it that way.  I, as a trainer, would never be upset or disappointed if someone told me they didn't understand - It's just a cue that I need to explain it differently. 

On a side note, it's pretty interesting to find people who care so deeply for the feelings of others that they will not give negative feedback even though it could affect them negatively. 

So, all this is interesting stuff, but utterly useless - unless we do something about it.  So, how can we address it?  I think a big part of it is sticking to our Agile roots and frequently pausing to evaluate our progress - by breaking the training into small pieces and allowing time for questions, we can easily redirect the session's path.  Here's the difference: Questions, especially when asked individually, are not tantamount to negative feedback.  It allows the trainee to indirectly give feedback, which is not considered an affront to the instructor.  So - we stick to small iterations. 

The next thing that seemed to work well was to ask for acceptance of the training topics - just like we would ask for acceptance of a user story at the conclusion of a Sprint.  This is yet another time for students to ask questions, or place items in the parking lot.

And finally, I've found that holding a daily retrospective during multi-day training sessions is important.  That way, even negative feedback can be given by the students that will redirect the session for the next day, or help us to adjust our instructional style.

It all comes down to being indirect.  That's the biggest thing.  Allow for indirect feedback through frequent question sessions, acceptance, and retrospection.

Last week I wrote about a parallel of Agile in medicine - this just highlights another one - Education.  A good educator, and indeed a good training program, would do well to be as Agile as possible.  Education truly must be a customer focused business.  They're the ones paying the bill - adapt to their feedback and provide the best possible experience by employing iterative, Agile methods.  That works everywhere - not just India.

Farewell from Chennai!

Sunday, April 21, 2013

Agile Resuscitation


One of the things I’ve always enjoyed while working with clients is finding parallels that relate Agile to everyday life.  When you stop to think about it, life is largely an Agile process in a lot of different ways.  Think of one proven thought model – the OODA loop.  OODA stands for Observe, Orient, Decide, Act.  Humans have a tendency to follow those steps in a lot of interactions.  We watch what’s going on, decide what to do about it, then act upon it.  Then, that process repeats.  It’s iterative.  It’s natural.
One parallel that I particularly enjoy exploring is the Agile nature of medical science.  Think about that for a minute.  What do doctors and other medical professionals do?  They observe symptoms.  They decide on a course of treatment.  They act on that course of treatment.  And then, after a period of time, the doctor will re-evaluate the patient’s response to treatment. 

So – there’s the parallel.  Plan, act, retrospect, iterate.
Let’s take a look at an even more rigid, iterative medical process: Resuscitation.  This one is near and dear to me – along with being an Agile coach, I’m also a paramedic – so I get to see this particular process in action often.

When a patient’s heart stops, there is limited time to get it started again, and there’s a rigorous, tested process to do so.  Not surprisingly, the rescucitative process is arranged into iterations.  First, we start CPR, followed by analyzing the heart rhythm, giving appropriate drugs, and providing defibrillation.  This is all done in two minute cycles – our miniature medical iteration.
Every two minutes, we stop CPR, check for a pulse, and analyze the heart rhythm.  In that moment, we’re reviewing the previous “Sprint” – did what we did work?  And just like that, we’re into planning.  What do we need to do this time around?

This process repeats until one of two things happens: The heart is restarted, or the patient dies.
Also built into the process is a continual retrospective process.  A provider is always thinking about what we call the “H’s and T’s” – a mnemonic that tells us what things we may have missed that may have either caused the cardiac arrest or is causing it to continue.  There are 6 H and 5 T words – Hypothermia, Hyper/Hypokalemia (High or low potassium), Hypoxia, Hydrogen Ion (Acid/Base Imbalance), Hypovolemia, and Hypoglycemia.  For the T’s, we have Toxins, Thrombus, Tension Pneumothorax, Tamponade, and Trauma.  By evaluating each of these things continually, or at least at the end of each two minute iteration, we avoid missing any reversible causes.

What parallels can you find in your daily life or hobbies?  I bet there’s more than you’d ever imagine!

Welcome

Ah, yes.  The obligatory first post!

Among other things, I'm an Agile Coach, and I travel often as part of my job.  So - my purpose for this blog is to talk about interesting stuff - Agile, travel, technology, and life.  Welcome, and enjoy!