Asking questions - why is it so hard?

Image by http://cdn.ilovetypography.com/

I am a journalist by training, and so I like to ask a lot of questions. My clients benefit from that, because they really have to allow me to dig deeper and to find out what really is the issue they want to treat in an innovation project, and I am not so easily satisfied with superficial answers, which leads to richer discussions and therefore to better understanding on both sides.

Asking questions is vital to any great project. Only if the flow of information is maintained into all directions and if anyone can ask anyone else any question about the project can we be sure that the project can be successful. Asking questions is important, but being available to answer them is also crucial. This does not necessarily mean being present in person, but just available, open and even eager to answer questions that come up during the process.

In my last post on my company blog I wrote about pull systems and how they are better at innovation than push systems. The same is true for cultures that allow for questions and discussions and where people are trained in asking good questions.

Often, in structures that come from push/command-and-control and are transitioning into something more agile or pull-based, this shift is very difficult. In push cultures people are used to second-guessing, assuming and "filling in the blanks" for the people who assigned them a task. There is not much flow going on during the project and thus vital information is not shared. Even worse, by taking assumptions people often proceed into completely undesired areas and produce poor results.

What is very important is that asking questions is not about getting instructions or approval. It is about maintaining the relational flow between all people involved in a project, be it clients, stakeholders, managers or team members.

Even for me, the journalist, it is sometimes hard in a project to ask questions. It seems much easier to assume because it will at first glance produce less friction or hassle for me. Long term, though, it creates waste and products that cannot be delivered.

We have it down in our code of conduct that "If I do not understand something I will ask", and "if the team cannot find the information, they will ask people outside of the team" as well as "I will not say yes to something I do not understand".

But to be honest, we have still a very long way to go from the written words to the lived culture, and so do many of our customers. 

Beware of the "agile as a set of rules" trap

There is a fine line between being convinced of agile/lean concepts and principles and using them as a framework and using them religiously and as prescription. I think we must be aware of this when we try to bring in new people into teams or build up completely new agile teams. If we do not make it perfectly clear that what we are talking about is a set of principles (versus "rules") and a framework (versus "process") we risk to loose people before they can even grasp the beauty of the whole thing.

This, partly, is one of the reasons why I think that every team and organization must find their own style of agile rather than following a recipe like SCRUM. It is good to use practices like SCRUM or kanban, but they have to evolve into something that the team (or organization) owns and adapts over time. (I am speaking specifically from a perspective of someone using agile/lean principles in a setting outside software development, but I think it is probably also true for software development itself).

It is normal, perhaps, to have new people on teams say things like "agile is like communism - it works perfectly in theory" (actually I heard that one last week), and then it is crucial that we DO have a conversation (or, more likely, several conversations or an ongoing conversation) about why agile is not a theory stuffed with useless belief points abd dogma , but a system that everyone can navigate and use together to create amazing things like great customer value, team satisfaction and performance. The word conversation gives a hint that over time, the team will reach a common set of principles and maybe even "rules" that they feel comfortable with, but that THEY established and own, which again means that they will feel free to inspect and adapt when they see that rules are no longer helpful.

As with every framework, theory, principle and system, it is always just as good as the people who use it. And therefore, conversations with people on how to use the principles and to make them their own instead of following rules made by others is absolutely crucial, as is the fact that starting to work like this is coupled with scepticism, fear and failure, but if a team overcomes this it can truly start using the power of agile and will probably not want to work in any other way anymore.

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.

Timeboxing needs some getting used to - and is a huge driver for innovation

One important concept of agile work practices is the notion of timeboxing. It means that the work that needs to get done - ideally a finished product or product increment that can be delivered to a client - needs to be finished within a specific time frame using a limited set of resources. Usually, those timeboxes are quite short. In many cases they only last days, sometimes two weeks, and in extreme cases even hours.

There are a number of benefits from this practice, and many of them have something to do with innovation.

First of all, timeboxing obviously creates a result faster. The team working on the product is under a positive pressure to create results and due to that pressure gets into better flow. Needless to say that this only works when also other agile principles are respected, such as a clear briefing, open communication channels, self-organisation in teams and others. If those elements are in place, the time pressure creates a positive flow.

Secondly, timeboxing helps get feedback from the client faster. If the team spends a few days on the creation of a product which is then shown to the customer, the product can then be adapted to the feedback to the client in following work cycles. This leads, over several cycles, to a better outcome that will be accepted better by the market. And this is, ultimately, better innovation.

Thirdly, and this is one of the most important benefits from my perspective, the team needs to take difficult decisions due to the limited time and resources and therefore need to have high quality conversations to reach conclusions. The trade-offs that are made should always be made in respect of customer value. What will truly add value to the customer, and what are merely sidetracks that the team can easily neglect?  This leads to high customer focus and, again, to better innovation.

And the last point is quite cool, really: Managing projects like that avoids tons of overtime, saves money and keeps everyone on the team in a nice work-life-balance.

Working with highly productive teams who are comfortable with the idea of timeboxing is a pleasure. But it is the teams that are new to the thought of timeboxing and feel uncomfortable and bewildered by it who really are the most interesting to me.

What usually happens in teams that are new to the process or where a majority is new is that the thought of timeboxing is so new that they filter it out and just ignore it, accumulate overtime and complain a lot about the limited time they have. When at the end of the work cycle the agreement they had committed to (finish the work in the agreed amount of time, with the allocated resources) is reviewed there can be quite long faces when this commitment is addressed. The nice thing is: It mostly only happens once, teams learn to deal with timeboxes very fast in the following cycles, sometimes they have to learn it "the hard way".

We are working with ad-hoc teams a lot, so they have to get used to the principles and the way of working in quite a short amount of time. We try to balance that by always adding people to the team who are more experienced in the practice and can help the team in the capacity of facilitator. Still, new teams have a hard time accepting the idea of delivering results in a set amount of time.

What comes into the picture at this time is the concept of scope. Managing scope is very important when you have limited time. Yet managing scope is again a complex idea that needs to be experienced over and over again to sink in. You can, actually, get almost anything done in a specific timeframe and at good quality if the scope is flexible. It means that you have to decide how you can fulfill the task in a good way but without all the frills and extras that you would normally add if you had no clear constraints.

I will need to write about scope in another post because we have had some pretty impressive findings, but this post is really dedicated to the idea of timeboxing.

In our journey into agile we have had more than one frustration moment with timeboxing at the beginning, because all people involved need to pay attention to the idea of the timebox when dealing with the project:

- The champ (we use this expression for the person who interacts with the customer and finds out what he really needs and then creates the backlog to create the product for the customer - in other agile practices this is called a product owner) needs to pay great attention when creating the briefing for the team and when choosing the work items for a work cycle. The items must be crystal clear, self explanatory, achievable and challenging at the same time.

- The team needs to pay attention what they commit to. They cannot enter that commitment lightly. They have to ask the champ a lot of questions and need to be sure that they know what they are committing to. This can take quite some time.

- The team needs to self organize and assume the responsibility for the outcome. There is no one coming in every day asking them how they are doing. They can tackle the workload in any way that they agree is best, using the allocated resources and time, without having to get approval for every step they are taking.

- It is very important that the team has access to a facilitator who makes sure that the team can work uninterrupted, makes good use of time and has the conversations that are necessary to take the tough decisions they need to take. In our version of agile the facilitator is chosen within the team, from the team, by the team. The role of facilitator can also change during the project.

To help the team accomplish their task they again use different tools, whether it be a simple tasklist or (preferred) a kanban board (we like www.kanbanery.com as well as www.kanbantool.com) is not so important. But visualizing the work in some way is. It must be clear for the team what the progress of each task is, who has pulled it and what it's status is.

When a team has gotten the hang of the idea of timeboxing, scope and self organisation, it is amazing what they can achieve in the time they are given.

My transition into agile land...

This is not going to be a very structured and well-rehearsed post. Infact, I am starting this blog to bring some order into my own confusion. If, along the way, I manage to convince some of my readers (hopefully, there will be some :-) ) this will be like a nice dessert for a good meal. But the main goal of this is to reflect and get some perspective about what is happening right now in my professional life. So why don't we start at the beginning?

I am one of the founders of a company called BrainStore. We are based in Switzerland and have been in business for 21 years. We are an Idea Factory, and we help companies come up with better innovation, build innovation teams and use processes and frameworks to make their innovation initiatives more successful.

We grew from 3 founders to more than 80 people and then downsized to roughly 25 over a period of two years because of the economic challenges we faced in the last 24 months. So far, we have been structured quite hierarchically with one of the founders being the CEO but also mainly leading all innovation, most of sales and most of operations. Though we knew that there are risks involved with this, we just never managed to organise ourselves in a diffferent way, mainly, probably, because we made the usual mistakes founders make when they cannot let go of their "baby".

This year, however, we realized that we need drastic change in order to prepare ourselves for a (hopefully) successful future. And we went looking for solutions. How should we re-organise so that the responsibility for the company, it's products, the interaction with clients and so on were in the hands of many instead of one or two decision makers?

I am documenting this process mainly for us, but also for others who are going through similar transitions and want to learn from us.