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.
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.
No comments:
Post a Comment