The role of the facilitator

Reflections on the role of the facilitator

The role of facilitator in an agile team is a role that we at BrainStore have still less experience with than the role of team member and champ. Although the team so far has always selected a facilitator for each cycle, the role has been more of a “manager” than a real facilitator in my opinion. 



Per definition in our agile principles, the facilitator
Helps the team move towards higher performance and greater personal satisfaction.

• By helping the team to discover barriers and help the team to remove them
• By promoting constant exchange of relevant information between team members
• By helping the team to have higher quality conversations
• By helping the team to optimally deal with time, resources and scope based on the allocated resources per backlog item
• By helping the team to decide on when and how to exchange information including stand up meetings and retrospectives

As long as cycles were short and team members knew each other well, the role of facilitator was a little bit easier and a little bit less crucial than now that we start working with remote teams and much longer cycles. Also, the role was never really taken as seriously as it should have been taken.



In short cycles and projects of low complexity, the facilitator also was or is able to take on team tasks in addition to his or her facilitation role. With larger projects, this becomes a conflict, because

• the facilitator cannot focus on the crucial role of facilitating when taking on tasks of his or her own.
• there are multiple moments of conflict when the facilitator is part of the team, because if the facilitator becomes part of the team he or she is part of the “we” and thus takes on the responsibility of the team. This means that he or she is no longer focusing optimally on the above mentioned elements that are crucial for making the team more productive.

In discussions with our agile coach I realized that the facilitator should focus mainly on the following activities during the facilitation of a team:

• 40% reflection (thinking about the role, learning more about it, improving self awareness, studying different techniques etc.)
• 30% observation (bringing the observations to the team in the form that seems best suitable at the moment)
• 20% inquiry (asking questions, being curious, mentioning things that are interesting etc.)
• 10% action (intervention, steering, removing impediments etc.)

I also realized that (mainly because of the fact that I was at the same time team member AND facilitator, the balance was much more on the action (more than 60% of the time).



What are examples of things that happen when the facilitator takes on too much action?

• the facilitator “thinks for the team” and thus does not give the team the opportunity to self organize and to grow
• the facilitator becomes part of the “we” and gives up his unique opportunity to observe, reflect and inquire.
• the facilitator becomes a negotiator for the team, e.g., speaking to the champ, communicating with the client etc. (tasks that need to remain in the team)

If the facilitator can focus on his/her facilitation role, numerous benefits arise for all:

• The team can focus on the task
• The team can start using the most of all resources
• There is not “someone” who thinks for the team, but the whole team
• There is always someone reflecting, observing and asking questions without providing the answers

Continuous improvement
Facilitation is not easy. The faciltator will always, also after many cycles, feel the urge and need to take action and intervene rather than observe and inquire. That is ok. The important thing is that gradually the facilitator learns to deal with this and to reflect, observe and inquire more



Examples
Examples of reflection

• Reading about facilitation techniques
• using agile resources
• reflecting about own behaviour
• writing learning materials for others, 
• coaching others etc.

Examples of observing
Listening to the team without intervention, from time to time offering an observation. Open remarks that start with words like

• “From what I hear,...”
• “It seems to me,...”
• “I get the impression,...”
• “I observe...”

It is specially important to voice observations of gaps, e.g. gaps between the goal and the status the team is in, information gaps etc.



Examples of inquiring
Questions that are open ended and help the team start a conversation, such as

• Actively problem solving: “What might help?” “What do you think will happen next?”
• Reflecting on experiences: “What would you do differently if you did this again?”
• Generating ideas and goals: “How could you figure out the answer to this problem?”  etc.

Examples of interventions

• Taking on a task from the team
• Researching something for the team
• Removing an impediment for the team
• Steering the team into a certain direction

Dealing with timeboxes, part II

After having written about timeboxing for inexperienced teams, an interesting incident came to my mind that can be helpful to understand the concept even better, and it is, coincidentally, also a great anecdote.

One team working on a complex project of building an innovation team for a client in India had committed to a cycle with 10 working days per person to get applications for the job, preselect on those applications and then conduct an assessment day for the client in India to select the best team for the client.

The team had 4 people on board. Three of them were totally new to the idea of agile and of timeboxing; one person (me) was more experienced. The team decided that I should therefore take on the role of facilitator, which I gladly did.

Along the way, the team worked and I inquired regularly how we are doing on time, myself assuming that it would be totally clear to everyone that our time allowance was 10 days each and that everyone else on the team knew exactly what that meant (false assumption, of course). I also tried to steer the team to have valuable discussions about the use of time and the trade-offs it involved. 

I had the nagging feeling that the team was acting in a "we will do whatever it takes" way instead of discussing the use of time and resources properly. But as I was a very inexperienced facilitator at the time (and I will share my findings about facilitating here, to, at some point), I did not quite know how to address the issue.

At the end of the cycle, shortly before the review, the team suddenly started to address the issue of overtime. I was quite astonished and asked them what kind of overtime they had accumulated (because I was aware of none). There were 2, 3 and 5 days overtime in the cycle, so a total of 9 extra days. Ouch. 

As a facilitator I realized that I had not fulfilled my role very well and told the team that we would need to take up the issue with the champ (product owner) who had initiated the cycle.

When we did this, there were two very interesting findings:

- In the briefing, it was not made 100% clear to the team what timeboxing meant

- One person of the four had commited to only 7 days instead of 10, but this fact was unknown to the team, so the team falsly assumed they had 3 days more. 

Here comes the interesting conclusion that we arrived to when discussing the issue between champ and team: The champ was NOT going to pay overtime (because that would be sending a false signal to other teams and it really was not in line with our agile principles and the concept of timeboxing), but the champ would pay a penalty for not making it 100% clear to the entire team what timeboxing meant and for not informing them that one person on the team was working 3 days less than the others.

The team discussed the amount of penalty that should be paid and how it should be distributed in the team (I, as a facilitator, did not want a share of the penalty because I felt partly responsible for the problem), and the champ agreed to the amount. 

I am quite sure that these particular team members will act very differently when working in a timeboxed cycle in the future.

The setbacks

So we have been agile for about two months now and in general I would say that it goes really well. We get much more done than before and in general I think we focus on the things that are really important. But there are setbacks and bad days as in any adventure.

Today, I am just not in the mood of being either product champ, team member or facilitator. I just want to be left well alone. I want to sit in front of my computer and do nothing at all.

Of course everyone has these days, and before agile we used to cope with them in a different way; we just sat in front of our computers doing nothing and then had to catch up on the work later, let's say, in the evening or on the weekend, which was not great, but, well, we knew that we had to.

There is no hiding in agile. In that sense, it's extremely brutal. You have to be very present and very focused every moment of the day or at least during the times when you are involved in cycles, which in our case is from 8 to 12 and 1 to 5. Also, all your flaws and your bad moods are part of the experience. You have to learn to communicate better with others and to work on your shortcomings.

The good thing, though, is that outside of these times, no one expects anything from you. You are not expected to perform. And, most of the time, you can't, firstly because you are utterly and totally exhausted from the days hard work, and then also because you get so used to working in a team that it seems plain silly to "do it alone" again.

At times, of course, you wish the old times back. But most of the time, agile is just pretty amazing.