Tag Archives: Yoda

The Big Bib

“I need a name for something,” I told Kyle, as we slid into our chairs inside of The Big Bib.
Kyle had discovered this little gem his first week in San Antonio.

Shortly after Kyle started coaching he executed one of the better team building moves I’ve ever seen. He treated his entire team to a free Barbecue lunch (paid for out of his own pocket). Of course, since to Kyle any group is an audience, he used the time they were eating to talk about the fundamental differences between Waterfall and Agile.

I, of course, wanting great barbecue, crashed the lecture–hey, free barbecue. I enjoyed the food so much we scheduled the restaurant as a coaches dinner destination. The talk was good too.

I had no idea it was literally a hole in the wall. About eight of us took up over three quarters of their chairs.

“What is the problem?” Kyle asked in response to my statement about needing a name.

“You know how we radiate stories, tasks, and status on a task board with the team seated nearby?” I continued, between bites of potato salad.

“Yes.” he said, devouring a rib like a starving crocodile.

“Well, even when the team isn’t doing their daily stand-up meetings they still see those items posted.” I noted, “They are continually reminded on what is being worked on, what they need to work on, and what the progress is on the project.”

“Go on.” Kyle stated, now cutting into a brisket.

“I calculate,” I continued, knowing of course that Kyle would immediately begin checking my math, “that the team is exposed to the information on the walls literally hundreds of thousands of times during the life of a typical project.”

I could see his eyes dart for a moment. I waited for him to finish the calculation. Kyle says he calculates using clocks. I have no idea what that means.  However, it seems to be fast and accurate, so I don’t ask any questions.

“OK,” he concludes a second or two later, already having completed his own estimate and finding it close enough to mine.

“Every time they look up, walk by, or see someone updating the task board they are potentially engaging in closing feedback loops.” I continue. “What if only a tiny fraction of the time they actually act on their observations.”

“They are closing hundreds of loops.” Kyle added. “Without even thinking about it.”

“It motivates them to move more quickly when they see others mark their tasks as done.” I declare excitedly. “It prompts them to ask a question about something they don’t understand.”

Geri, who as also been tracking the conversation chimes in, “It also lets a person know they need to pitch in, just by observing a task isn’t completed yet.”

“Absolutely” I continue, “And this goes on all the time!”

“So what is the question?” Kyle says, moving the conversation back to its original intent, and taking a sip of a large beverage I would swear was 10 percent tea and 90 percent cream.

“My question is, what do we want to call this type of feedback?” I said, gently pounding the table. “I want to lecture on it but it needs a name.”

Kyle sat silently for a moment,

“I think I know,” he said.

“Although the words are not perfect, they may do the trick. And there are two words that we need.”

I smile.

“Peripheral and visceral.” Kyle states, matter-of-factly, licking sauce off of his fingers, “Visceral is probably the wrong word, but it is the best I can think of for now.”

My next presentation now had a title, “Peripheral and Visceral Feedback.”

My goal, to explain the subtle psychology behind agile that most software professionals miss. To explain it in terms of feedback loops operating all of the time in the background, if we do agile correctly.

New teams always try to immediately disable all of these feedback loops.  “Lets not put story cards and tasks on the wall,” they’ll say, “lets put’em in this fancy new fangled dater base. The people who sold it to me said it is really good.”

In our experience this is always a bad idea. But, it has been very difficult to explain why without sounding like a mystic. The job I assigned myself was to explain why, and to do it in terms that people could actually understand.  I instantly suspected the words “Peripheral and Visceral”  would help, a lot.

In the end we would write the presentation as a team and call it “Peripheral, Physical, and Visceral Feedback.”

Kyle, of course, gave it to anyone walking too close to his desk.

I think, maybe, we are moving agile from mysticism to pragmatism, with a little help from feedback loops.