Skip to main content

Rich Communication in Real Life

The agile community is full of people who say things like "communication must be as rich as possible," by which they mean, "in person, simultaneously in time, and proceeding from high level to detail."  Not content with this message, our community members often go the extra mile to say things like "there's no point in expecting good communication to occur otherwise. [heavy sigh]"



This leads to some seriously bad things happening when agilists attempt to communicate with each other in the environments in which they are normally employed.  REALITY CHECK:  how many of these are true where you are working today:
  • Your project members are distributed over multiple timezones (not to mention countries, cities, buildings, hallways, and or "cube bays")
  • Your communication platform is horrible.  You aren't allowed to use Skype (security risk!), you don't have any video access to anyone anywhere (next year's budget!), and even your conference phone bridges are prone to suddenly going bad after 10 minutes of conversation.
  • There aren't enough conference rooms, and they don't all have projectors, network connections, access to wireless or phones anyway.
  • Logistics around work spaces, communication, security, and software licenses are controlled by a faceless and cruel bureaucracy which moves slower than a glacier (or a smoke signal)
  • Everyone with customer-facing responsibilities who can tell you the requirements is doing (at least) two jobs
  • Some of those jobs aren't filled, either
  • All/most/many/some of the people you actually have access to on a day to day basis are not actually empowered to make decisions when you ask them
  • Meetings have to be planned eighteen weeks in advance and may still fall through at the last minute.
In short, if you're like many of us, you are working in the type of organization most likely to hire agile custom software delivery people:  large, corporate environments.  What to do, what to do?

Much to my growing aggravation, one thing a lot of us seem to do is pretend we're working in a small, co-located group anyway.  Because agile theory says "don't waste time on meeting minutes," and "writing is evil," we take a team which is ten people total, but working on four continents, and go ahead and build some kind of terse card wall with nothing on it but short statements in the form "as a...I need to...so that..." and some acceptance criteria, we schedule a daily standup (which devolves to weekly or monthly because people can't attend), we end up having side conversations to decide absolutely everything, but we don't tell people about them unless forced, (definitely not in writing! writing is evil!) and we roll our eyes if people complain that the decision-making process isn't democratic, and that nobody knows what's going on.  All of this in the name of "keeping communication rich."

I've ranted on this before, but I have a new angle today!  It's called "learning styles," and I think it can help us think about how to best provide rich communication in a different way, as well as throwing some light on some of the underlying prejudices behind the communication theory we agilists have been using so far.



North Carolina State University hosts an excellent set of materials on what they call the "Index of Learning Styles." They divide people into learning preferences on the following dimensions (each is a spectrum, and each person falls somewhere on each spectrum):
  • Active versus reflective learners:  "Active learners tend to retain and understand information best by doing something active with it--discussing or applying it or explaining it to others. Reflective learners prefer to think about it quietly first."
  • Sensing versus intuitive learners: "Sensors often like solving problems by well-established methods and dislike complications and surprises; intuitors like innovation and dislike repetition."
  • Visual versus verbal learners:  "Visual learners remember best what they see--pictures, diagrams, flow charts, time lines, films, and demonstrations. Verbal learners get more out of words--written and spoken explanations. Everyone learns more when information is presented both visually and verbally."
  • Sequential versus global learners:   "Sequential learners tend to gain understanding in linear steps, with each step following logically from the previous one. Global learners tend to learn in large jumps, absorbing material almost randomly without seeing connections, and then suddenly 'getting it.'"
So for me, the question is, "how best to accommodate all full-spectrum of learners" for communications needed during software delivery and subsequent support, rather than "how to make sure we don't waste time writing things down."
  • Communicating with active and reflective learners: in all written and verbal discussions, people who hope to transmit some kind of message to keep in mind that some people want to engage in a real-time discussion, but there will always be people who need to reflect on things before internalizing them.  This implies:
    • Active learners are going to be happiest having simultaneous meetings to hash things through in real time.  Simultaneous collaboration should be arranged for active learners.
    • Reflective learners may be more comfortable with iterating on a written document in their own time, rather than working on one simultaneously with others.
    • As a compromise, you could capture more of the full spectrum by having a combined approach:
      • For active learners, you need to have a real time meeting.
      • For reflective learners, it may be helpful to send "straw man" materials to be discussed ahead of the meeting.
      • For reflective learners, it may be helpful to solicit follow-up reactions after in-person meetings are held.
  • Sensing and intuitive learners:  Yesterday I had a senior person tell me he preferred for me to follow up with him casually in a hallway rather than setting up a meeting.  He didn't (and wouldn't!) but some theorists will go so far as to tell you to avoid scheduling meetings because that is "high ceremony."  That's why we have short stand-up meetings and avoid everything else.  Others of us, however, may hate to be interrupted.  This implies:
    • Intuitive learners don't like to wait for a meeting to discuss things.  Ensure that you have channels open in person, in writing, and over as many channels as you can, to free communication from spontaneous communicators.
    • Sensing learners don't like having to be interrupted all the time.  Ensure that you have regularly scheduled communications channels like meetings and scheduled written status announcements.
    • To accommodate both ends of the spectrum, 
      • For intuitive learners, you need to be open to sending and receiving messages spontaneously, likely using whatever means of communication is handy to people participating in the conversation.  You may need to take up twitter.
      • But for sensing learners, ensure that you hold meetings and/or make published roll-ups of all communications available on a regular schedule--the key here is that these should be comprehensive.  Don't penalize people for not being in that hallway that day with you and the VP.
  • Visual and verbal learners:  One insight the ILS provides is that written language is neither fully visual nor fully verbal.  "It is perceived visually and so obviously cannot be categorized as auditory, but it is also a mistake to lump it into the visual category as though it were equivalent to a picture in transmitting information. Cognitive scientists have established that our brains generally convert written words into their spoken equivalents and process them in the same way that they process spoken words."
    • If you are in an environment where you need to write things down to bridge a gap between two parts of the team, or to leave information for support people to follow later, please do go ahead and write it down.
    • But the bottom line is to accommodate both visual and verbal learning styles, ensure that anything you send out in writing has pictures.  "...to a visual learner, a picture is truly worth a thousand words, whether they are spoken or written. Making the learning style pair visual and verbal solves this problem by permitting spoken and written words to be included in the same category (verbal)."
  • Sequential and global learners:  on the ground we may sometimes be impatient with our peers who want to "spell things out" all the time, because it gets so tedious.  But that's how some people learn, so we need to handle that in our communications.
    • Global learners will appreciate your table of contents or meeting agenda.
    • Sequential learners will appreciate that you actually step through the contents and agenda, rather than just running away laughing after getting those out there.
In the end, when agilists say they prefer "in person, simultaneous and holistic discussions" without too many details, I think it's interesting to note that these preferences show an underlying prejudice towards communication at one end of each of the pieces of the ILS scale:  an agilist is probably someone we think of as "interactive, spontaneous, visual, and global" in thinking.

But of course ALL of us aren't like this, and for happy, productive teams who can get along even when not drinking beer together, the pragmatic communicator will build a project communication strategy which is friendly to people popping up in different areas of those continua.  And of course the ILS isn't the only theory of learning styles.  But it's all food for thought.

By the way, if you're interested in seeing what your own learning style spectrum looks like, and how to best to accommodate your own preferences for best learning, the ILS people offer this online quiz.  It's like Meyers-Briggs, only faster!


Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica