Training, 100% "pull".

Since many years, we train clients to run successful innovation projects. We have a very good process to generate, assess and implement leading ideas, using different tools and communities to come up with a diverse set of ideas. All of this has been tested in thousands of projects and is very successful.

What was missing was the knowledge - both within our company (www.brainstore.com) and with our clients, how successful innovation projects are managed over a long period of time. I mean, it is all great if you use a wonderful process to come up with ideas and identify the leading initiatives, but the truth is, innovation is complex. So even if you have wonderful ideas that are tested and "might" work well, you need the right process to manage successful implementation. This was a kind of missing link for us for a long time, until we discovered agile principles and practices.

Agile allows clients to "implement" the ideas that they found in the BrainStore process (we call it "The Idea Machine 3.0) in a cyclical way, coming up with a "Version 1" very fast and adding features in future cycles. This is true whether they implement new products, services, software or even processes.

But should do we "teach" this agile way of working to teams who are thoroughly used to siloed organisations, command-and-control environments and "top-down" decision making? We first tried to teach them by explanation. That was total failure (and as we learned: Fail early, recover quickly, right? :-)).

One morning, just before such a client training was to happen again, we got quite frustrated and discussed within the teams how we could change the approach. Our Enterprise Champ (the person responsible for the top level enterprise backlog) suggested: "Why don't we do the whole training in a 100% agile way"? We resonded, somewhat exasperated: "Yes, yes, but HOW?".

We thought it through for a few minutes, and here is what we did, and are doing since:

Step 1: Trainees come to the training program with a "I will be tought something now" attitude. They get coffee, have a chat and are seated in a circle and then addressed by the training champ (person responsible for this training). The training champ will tell them that they are the clients and that they are getting to tell us exactly what they want to learn in this training. What do they expect? What do they want to know? What is te purpose of the whole training for them? These needs are noted in a briefing.


Step 2: Based on the purpose and the briefing (goals, expected results, criteria) the backlog for the training is established. The backlog contains different items that the participants want to learn, and each item is described with a short story (as a trainee, I want to xyz, in order to xyz) and gets a clear "definition of done". Each backlog item also gets an estimate of time or size by the participants. A time for the review (usually this is sometime in the afternoon at the end of the first day) is agreed upon.


Step 3: The training champ will now ask the participants whether they are ready to commit to this backlog and  to "produce" all the items on the backlog as a team until the time of the review. It is made clear that the team is responsible for the results and that they are to self-organize to reach the results. To do that, they choose a facilitator from within the team. If needed, the champ can become a team member for the time of the training, or alternatively, there are some experienced people in the team who can help the team reach the learning goals. The team commits, most of the time after asking additional questions, negotiating some terms, changing some backlog items.


Step 4: The team starts learning by working on each backlog item and exploring the issues. Learning material is provided in a "Knowledge Bureau" (Desk of drawers containing "how to's", checklists, exercises etc., both available on paper and online.


Step 5: The team presents the results of the cycle at the review. The trainig champ listens and asks questions. 


Step 6: The team has a retrospective where they discuss what went well, what did not and what they will change on the next training day. 


Step 7: Training champ provides feedback to the team, based on the results of the cycle and the retrospective findings.


The next day, the team meets again and goes into the next round of learning. In cases where training days are happening over a longer time span, teams might also commit to a backlog for in between training sessions, committing to exploring and learning some issues until the next training session happens.

This approach works so well because it is a 100% immersion. We do not need to explain a lot of the "how to do agile", "how to be agile" stuff, but can launch directly into the experience. A team that has experienced this will afterwards reflect on what they did and adapt their style of agile to their needs rather than having a theoretical knowledge about the whole thing that they will not be able to digest properly.

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.