Introducing The Facilitation Kernel

Now that I’ve reposted a few older posts, I’ll give a new one…

One of the things I often get called upon to do is facilitate; meetings, workshops, retrospectives and other occasional agile ceremonies are all meetings I get called upon to facilitate.  I also find myself facilitating teams talking to one other (which actually goes into the encouragement to get together, not just the resulting meeting session) and sometimes what normally would be one-on-one sessions.

A few years back, I took one of the IC-Agile certified courses on Facilitation; they presented what they called the Facilitation Stance.  It’s useful.  (Because of possible IP ownership issues, I won’t present it here…) One thing that didn’t feel right was the treatment of maintaining neutrality as a facilitator; it wasn’t treated as core.  As I gave training to others on facilitation, they also seemed to question that lack of centrality.  Another area that I personally got, but others struggled with was the “stand in the storm”. So I began rethinking how to depict the concepts and came up with what I think is something easier to understand.


I call this the Facilitation Kernel.  It places Maintain Neutrality central to the entire concept.  This is important as if I am asked to render an opinion, where I am no longer a neutral party, the entire rest of the Kernel can be sacrificed.  This is particularly true if I am asked to give insight from experience or observations.  The Facilitation Stance doesn’t make this as explicit as I would like (though it does acknowledge it).

My personal feeling is that the ‘Stance’ over complicates itself with the internal “being” and external “doing” (of which maintaining neutrality is an external “doing”.  This may be just me, but I find neutrality at the core.  In the “doing” circle, I place Modeling Servant Leader Behaviors, Leading the Group’s Agenda, Promoting Dialog, Decisions, and Actions, and Harnessing Conflict. Let’s dissect these one by one:

Modeling Servant Leader behaviors is very important to exhibit as a facilitator; you are there for the team and to serve them.  You are not there to serve someone else or yourself.

By Leading the Group’s Agenda you are not just Stance’s Holding the Group’s Agenda; you are also leading them through their Agenda, whether explicit or implicit through design of the session or keeping a watchful eye and ear on what is occurring and needed.

In Promoting Dialog, Decisions, and Actions (which encompasses the Stance’s Upholding the Wisdom of the Group), you are gently nudging the group to a bias of action versus inaction and making assumptions explicit so that good decisions can be made.

And lastly by Harnessing Conflict you are doing more than simply “Standing in the Storm”, but are helping people through their differences to a positive outcome.

To do this, you need to maintain three states of “being”; self management (which IMHO encompasses self-awareness), group awareness, and situational awareness (this may be my aviation background talking to me). The alignment I have chosen in the model is important.  In order to Model Servant Leader Behaviors, I need to mostly manage myself; the situation and group awareness are far less important.  To Harness Conflict, I need to be able to be wary of where the group is currently (in terms of emotional state and energy) and the situation at hand (in terms of positions and opinions).

I places the Lean and Agile Values & Principles outside this Kernel as if I wasn’t facilitating in this realm, it may be replaced some other set.  I think this makes the Kernel fully aligned with what any general facilitator may provide.  I know I have found this useful when considering facilitating more generalized sessions such as Open Space (which I have had the opportunity to do twice) and various workshops.

What do you think? Is this congruent with your thinking on facilitation?

The Economics of Agile Communications for Requirements

This post originally appeared on my BoosianSpace blog on 28 October 2011. Some minor updates were made.

I’ve been reading Democratizing Innovation by Eric von Hippel.  One of the items he talks about is the cost of information transfer from innovation user to innovation creator.  In his context he’s demonstrating why uniqueness causes innovations to be grown internally by organizations as opposed to being bought off the shelf.

This got me to thinking on a challenge we see in Agile Adoption, explaining the reason we want lighter-weight documentation and more face-to-face collaboration.  I got a small inspiration on the economics of the two opposite ends of the spectrum.

Let’s start with the sequential phased-gate (aka ‘Waterfall’ or as I prefer to call it a ‘Canal’) approach.  Here’s what typically happens:

A set of business or systems analysts create a document. This gets approved by the business user(s) and often management.  This then gets distributed the development team.  They theoretically read the whole thing through once and understand it perfectly (single set of communication paths of one document to N people reading it).  So here’s what the formula would look like for the communication of that information throughout the entire team:

Xfer$W = Labor$avg x [[(Ncreators x CreationHrsavg) + (Napprovers x ApprovalReadingHrsavg)] x Cyclesapproval

+ [ ((Nteam – Ncreators) x ComprehensionReadingHrsavg)]]

In words: The transfer cost is equal to the creation labor hours (number of creators x average creation time for the documents as this is what communicates it to analysts creating it) plus the approval labor hours (number of approvers x average time to read the resulting documents as this is the communications to the business representative(s)) multiplied by the number of approval cycles plus the comprehension  hours (number of remaining team members that need to read the approved document x average time to read) finally multiplied by the average labor cost per hour.

Let’s see this in action as an example with a team of 6 and 1 business user that has to approve the requirements on a small application development effort:

Xfer$W = $100 avg hourly rate x [(1 analyst x 120 hours creation time) + (1 approver x 4 hours reading to approve)] x 1 cycle + [5 remaining team members x 40 hours to read and fully understand the requirements)] = $100 x[ [120 + 4] x 1 +[200]] = $100 x 324 or $32,400

Two primary assumptions here are that an approver won’t be as interested in reading it in detail as they supposedly know the requirements and thus will not pay as much attention to reading the document he or she is signing off on…AND more importantly the team can read the document ONCE and it contains EVERYTHING they need to know.  It is perfect, nothing is missing.  These numbers aren’t exactly realistic of course, most projects would take longer and would involve more signatories and more cycles to get sign-off.  I’ll be discussing the costs of change using this model in a bit.

Now let’s look at the same communications using an Agile approach…

In the Agile approach, the entire team is going to be involved with the creation, which will now include the business owner/manager.  There is no need for a sign-off as he or she is directly involved.  There also is no need to have the development side of the team expend time in reading the documentation since they are also directly involved in creating it. To reflect on the time, the people creating the knowledge (and artifacts) is equal to the by the number of paths of communication in the team multiplied by amount of effort (the average creation time) each person has to put in divided by the number of people assisting in the communications (i.e. the number on the team).  Also, since the business owner is involved throughout the development process there is only one cycle (for the lify of this project cycle).   Thus, our equation becomes the following:

Xfer$A = Labor$avg x [(Ncreators + / CommPaths) x CreationHrsavg]

Where CommPaths = ∑((Nteam – 1 ) + (Nteam – 2 ) + … +(Nteam – (Nteam – 1) )  

The assumptions here are the average creation time per person is the same as the creation time in a canal environment; i.e. the scope is the same.  Since this is done throughout the development by all members of the team, we know this will not be one solid time block and will involve more people.  The effort to distribute the information, however, is represented by the number of paths involved divided by thepeople trying to move the information along those paths. This is why the communication paths variable is the numerator and team members the denominator.

For our example of a team of 7 (since the business owner is now a part of the team),

CommPaths = ∑((7 – 1 ) + (7 – 2 ) + … +(7 – (7 – 1) )  =  21

Xfer$A = $100 x [(21/7) x 120] = $100 x [3 x 120] = $100 * 360 = $36,000

Your probably wondering where the savings is…  This looks like a wash. It isn’t.  What comes into play is the cost of change as it occurs over the project.  To truly understand the costs though, we need to discuss what happens over the life of the project.  In the ‘canal’ project, if we make a change, we have to go though the same expensive communications path as the initial development.

Xfer$W = Labor$avg x [[(Ncreators x CorrectionHrsavg) + (Napprovers x ApprovalReadingHrsavg)] x Cyclesapproval

+ [ ((Nteam – Ncreators)x ComprehensionReadingHrsavg)]]

Let’s use our example and say we had a change that requires roughly a quarter of people’s time to produce version 1.1 of the requirements specification:

Xfer$W = $100 x [[(1 x 30 hours) + (1×1 hour sign-off)] x 1 + (5 x 10 hours comprehension)] = $100 x [[30+1]x1+50] = $100 x 81 = $8100

So now total cost is the $32,400 + $8100 or $40,500 ; each time I go through a change the cost will go up by some amount.

Going back to the Agile side, because we are performing the requirements communication throughout the development and we defer to discussing only the requirements needed for the next piece of work, changes and more importantly the associated communications are already baked in.  We haven’t defined it all upfront an then distribute it for use once.  Thus, the additional costs for the next distribution are near zero.

We expect requirements to change.  We defer unknown things to as late as we can responsibly can (the last iteration possibly if the work can be done in one Sprint) so that the risk of needing to change it is minimized. Thus our costs are not going up with changes, they are remaining basically flat.  In the sequential phased-gate scenario, one significant change could ‘wipe out’ the supposed savings you saw in the simple calculation, which optimistically presumed that everything worked perfectly the first time.


Note: I am not a accounting type by nature; this just seemed like a logical fit and I am trying to find some empirical evidence to support it or that contradicts it; if you know of some, it would be appreciated!  Just post below and the sources you are using.

BTW, I have also toyed with the fact that requirements (stories) that need to change along the development cycle have the cost of the original one, but to multiplied by the probability that they are still in the backlog to be done and not done yet.  If you you added up the percentages as buckets of 10% along the project and divided by 10 to get the likelihood that this occurs as 50% (on average) then the cost would be akin to the following by example:

CommPaths = ∑((7 – 1 ) + (7 – 2 ) + … +(7 – (7 – 1) )  =  21

Xfer$A = $100 x 50% of [(21/7) x 40] = $100 x 50% of [3 x 40] = $100 x 50% of 120 = $100 x 60 = $6000 so the total cost of changes accumulate at a slower rate.

During a project execution, you could actually use a real rolling percent of stories closed over total stories.