Tag Archive: communications

I have been revisiting the Popendiecks’ 2003 book: Lean Software Development: An Agile Toolkit.  One of the tools in the book is Set-Based Versus Point-Based approach.  This tool is based on Lean principle of amplifying learning. 

Point-Based approach is based on choices.  The authors represent this via the following an illustration:



Whereas, Set-Based approach is described as one about “constraints, not choices” and that it requires “significantly less data to convey far more information.”

I inadvertently stumbled on an opportunity to try out this tool, exactly in the way it is described in the book.  While facilitating a community of practice which has 9 team members, I had a need to schedule a meeting.  But, since we all work on different teams, coordinating simple schedules for this part-time effort is usually a challenge.  It would be simple to see everyone’s calendars and schedule a meeting.  However, many people don’t keep their calendars up to date.  Or they have blocked off time, but are actually available.

Even during face-to-face meeting, since people don’t have their schedules in front of them, they are reluctant to commit.  So it becomes hard to converge on a time.

My initial instinct was to use the point-based approach by letting everyone know the best time that worked for me.  But I decided to try the set-based approach.

Here is how I communicated the constraints via email to all the team members:

  • Apart from me, one particular team member needed to be present, as she had the key information on the topic
  • Additionally we needed 2-3 more team members
  • I provided 2 blocks of 2 hours each that I could meet for an hour long meeting

And lo and behold, within few minutes, I got the needed response.  What had in similar circumstances took a flurry of emails, and still no convergence; with this approach, we converged on time with just 1 email each from the team members.  Few let me know which time worked, others let me know they weren’t available.  And I was able to quickly pick a common hour that worked for half the team to meet.

It was great to see the tool in action.  Next, I am keeping my eyes open to use this on a development project.

NPR recently reported that TSA will now use behavioral profiling called “chat-down” and “require every single traveler to go through a quick interview with security officials trying to spot suspicious behavior.” 
A federal security director, George Nacarra said, “We are looking for behaviors that are out of the norm – some kind of indicators of intent to cause a problem.”  To illustrate this concept, Marc Salem, another expert had the reporter do a simple demonstration: 
“Pick a two-digit number, between 50 and 100, both digits even,” he says. He explains that he can’t guarantee 100 percent success, since he won’t be able to read all of the clues he usually gets from face and body language. On the phone, his only clues are things like voice quality, hesitation, pacing and breathing.
“Say nothing aloud,” he says. “I’m just going to work off of breath. Hold your mouth next to the phone,” and he begins to count as fast as he can from 50 — until he stops dead at 68.
“[It’s] 68!” he announces. He says he heard a faint tongue click right when he said the number.
It’s subtle, Salem concedes, but he was listening for something like that; he knew I would try to control my breathing, since he mentioned he was listening for that.
“If you hold up something, if you clog one channel of information, it’s got to come out somewhere else,” he says.
In agile development process, we have chucked the heavy tomes of documented requirements.  Good riddance!  Instead, we write simple user story and flesh out the details through conversations.  So for agile teams, engaging in rich communication becomes crucial.  An expert like Salem is trained to look for audio and visual cues.  Many of us may not have his level of acuity.
What’s more, we’re now finding through studies that we engage in attention prioritization and attention management, but we do this at the expense of missing other details.  See the video below.  And count the times the people in white tshirts pass the basketball?
Did you correctly count to 15?  But, did you see the gorilla.  It turns out there are 50% of the people who are so engrossed in counting that they never see the gorilla.  For agile teams, it is important to not only engage in rich communication, but also that we have many of our teammates around when we are having these conversations.  This way, even if one person misses something important, then someone else on the team will catch and remember those details. 
Engaging in rich communications, especially face-to-face ones, can uncover clear intent, quicker clarifications, and has fewer chances of miscommunication.  Co-located teams have this advantage, due to proximity to each other.  There is less need for them to write things down, and instead, all team members can be part of all the communications streams.  But what about distributed teams, which according to State of the Agile Survey for 2010, make-up two-thirds of all agile practitioners? 
With my distributed teams, we found few things that was effective in creating the type of shared space, shared knowledge base, we are talking about.  For you, the answer will depends on your team’s particular circumstances.  From my experience, here are some of the things that were effective (roughly, in descending order of priority):      
  • Co-locate for project/release inceptions
  • Co-locate for iteration demo, planning, retrospectives
  • Use web-cams and video-conferencing whenever available
  • Tele-conference when more then 2-3 people need to be part of a conversation
  • Use of IM, Chat and use of LiveMeeting or WebEx or other online collaboration tools.
  • Brief synopsis of side-bar conversations or chat/IM transcripts posted on team’s common workspace (such as wikis, etc.)

What about your teams, what works for you?

%d bloggers like this: