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. 

10 drastic changes in the world of work in the next 10 years

1. De-routinization of WorkThe core value that people add is not in the processes that can be automated, but in non-routine processes, uniquely human, analytical or interactive contributions that result in words such as discovery, innovation, teaming, leading, selling and learning. Non-routine skills are those we cannot automate. For example, we cannot automate the process of selling a life insurance policy to a skeptical buyer, but we can use automation tools to augment the selling process.

2. Work SwarmsSwarming is a work style characterized by a flurry of collective activity by anyone and everyone conceivably available and able to add value. Gartner identifies two phenomena within the collective activity; Teaming (instead of solo performances) will be valued and rewarded more and occur more frequently and a new form of teaming, which Gartner calls swarming, to distinguish it from more historical teaming models, is emerging. Teams have historically consisted of people who have worked together before and who know each other reasonably well, often working in the same organization and for the same manager. Swarms form quickly, attacking a problem or opportunity and then quickly dissipating. Swarming is an agile response to an observed increase in ad hoc action requirements, as ad hoc activities continue to displace structured, bureaucratic situations.

3. Weak LinksIn swarms, if individuals know each other at all, it may be just barely, via weak links. Weak links are the cues people can pick up from people who know the people they have to work with. They are indirect indicators and rely, in part, on the confidence others have in their knowledge of people. Navigating one's own personal, professional and social networks helps people develop and exploit both strong and weak links and that, in turn, will be crucial to surviving and exploiting swarms for business benefit.

4. Working With the CollectiveThere are informal groups of people, outside the direct control of the organization, who can impact the success or failure of the organization. These informal groups are bound together by a common interest, a fad or a historical accident, as described by Gartner as “the collective.” Smart business executives discern how to live in a business ecosystem they cannot control; one they can only influence. The influence process requires understanding the collectives that potentially influence their organization, as well as the key people in those external groups. Gathering market intelligence via the collective is crucial. Equally important is figuring out how to use the collective to define segments, markets, products and various business strategies.

5. Work Sketch-UpsMost non-routine processes will also be highly informal. It is very important that organizations try to capture the criteria used in making decisions but, at least for now, Gartner does not expect most non-routine processes to follow meaningful standard patterns. Over time, we believe that work patterns for more non-routine work will emerge, justifying a light-handed approach to collecting activity information, but it will take years before a real return on investment for this effort is visible. In the meantime, the process models for most non-routine processes will remain simple "sketch-ups," created on the fly.

6. Spontaneous WorkThis property is also implied in Gartner’s description of work swarms. Spontaneity implies more than reactive activity, for example, to the emergence of new patterns. It also contains proactive work such as seeking out new opportunities and creating new designs and models.

7. Simulation and ExperimentationActive engagement with simulated environments (virtual environments), which are similar to technologies depicted in the film Minority Report, will come to replace drilling into cells in spreadsheets. This suggests the use of n-dimensional virtual representations of all different sorts of data. The contents of the simulated environment will be assembled by agent technologies that determine what materials go together based on watching people work with this content. People will interact with the data and actively manipulate various parameters reshaping the world they’re looking at.

8. Pattern SensitivityGartner has published a major line of research on Pattern-Based Strategy. The business world is becoming more volatile, affording people working off of linear models based on past performance far less visibility into the future than ever before. Gartner expects to see a significant growth in the number of organizations that create groups specifically charged with detecting divergent emerging patterns, evaluating those patterns, developing various scenarios for how the disruption might play out and proposing to senior executives new ways of exploiting (or protecting the organization from) the changes to which they are now more sensitive.

9. HyperconnectedHyperconnectedness is a property of most organizations, existing within networks of networks, unable to completely control any of them. While key supply chain elements, for example, may be "under contract," there is no guarantee it will perform properly, not even if the supply chain is in-house. Hyperconnectedness will lead to a push for more work to occur in both formal and informal relationships across enterprise boundaries, and that has implications for how people work and how IT supports or augments that work.

10. My PlaceThe workplace is becoming more and more virtual, with meetings occurring across time zones and organizations and with participants who barely know each other, working on swarms attacking rapidly emerging problems. But the employee will still have a "place" where they work. Many will have neither a company-provided physical office nor a desk, and their work will increasingly happen 24 hours a day, seven days a week. In this work environment, the lines between personal, professional, social and family matters, along with organization subjects, will disappear. Individuals, of course, need to manage the complexity created by overlapping demands, whether from the new world of work or from external (non-work-related) phenomena. Those that cannot manage the underlying "expectation and interrupt overloads" will suffer performance deficits as these overloads force individuals to operate in an over-stimulated (information-overload) state.

Additional information is available in the Gartner report "Watchlist: Continuing Changes in the Nature of Work, 2010-2020." The report is available on Gartner's website at http://www.gartner.com/resId=1331623.

is this really something for teamwork?

When you begin to work in an agile way, you work much more in a team than before. Things you did alone before are now done in a team, and you rely on each other to get things done. While I find teamwork something very helpful in 80% of all cases, in some cases I can not help to think - before we start working in a cycle - "well, is this now really something for teamwork? Wouldn't it be easier if someone sat down and just figured this out?"

Today I had such a moment again. We were asked by todays product champ to come up with a system that would allow all people working for the company to sell our products and to make it in a way that would be transparent and corresponding to the agile principles (so, for instance, to make it in a way that would allow different people to work on the same client account and sharing responsibility).

My immediate response was: "Well, I know a lot about sales and about systems, so shouldn't I just sit down and write the concept?" But the other team members convinced me that it was a good thing to do this task as a team and so we started deciding on the best way to do this.

The other team members started by brainstorming on all the questions they might have about selling our products, while I came up with a basic suggestion of the structure and system. Then, we swapped the results, and the team members started to improve my system (they actually changed it completely, which was totally beneficial to the result :-) ) and I started taking their questions and formulating "how to's" and checklists to answer all the questions.

After only half a day we had a basic system in place with all the manual and checklists to go with it. In the afternon we then started testing our system together and improved it a great deal  over the course of the next three hours.

At 4.15 we had a review with our product champ and presented him the results. At 5, we all went home, feeling a great sense of accomplishment. Wow. I am starting to become a true believer in teamwork (needless to say, I am already a fervent advocate for agile).