During a PM Camp on 24^th August, Cornel and I organized our first Innovation Games inspired from the “Buy a feature” exercise. We already have a whole range of training materials available in our catalog drafted for the Incubator, our internal training center. However, for those who have already had some practice with agile software development methodologies and change management, mastering the knowledge is not enough. Individual behaviors are essential for project success.

It is within this framework that we are preparing a training session, “Agility within projects”. Its aim is to emphasize the valuable behaviors when working on a project, through several practical games. Of course, we do not claim to impose a unique behavior, as everybody has their own sensibility, but the purpose of the exercise is to increase the participants’ awareness of other behaviors in environments created from scratch.

For this game inspired from “Buy a feature”, we explained to the participants that each of them would receive a part of the budget from the technical management and that they had to distribute it to a total of 16 missions. They received 20 banknotes of 100 PentAgiles. They could distribute their budget as they saw fit, omitting to allot a budget to a less important mission.

Here is the list of the 15 missions that we selected. Of course, they are taken from real technical management missions.

1. Technical audit at the project start-up
2. Technical audit during project execution
3. Support during the project
4. Technological monitoring
5. Investing in production tools
6. Adapting the needs to the market
7. Making estimates for quotations
8. Appointments with clients
9. Training in best practices
10. Training in tools
11. Training in methods
12. Organizing the sharing of knowledge
13. External communication
14. Internal communication
15. Setting up production indicators

Once the banknotes were distributed, they all became technical directors and started allotting their share of the budget without trying to join resources with a colleague in order to improve the distribution. Therefore, some of them chose not to allot budget to missions such as communication and production indicators. In all cases, they made unilateral choices. In this situation, good agile methodologies practice would have been working in groups to share their opinions and to reach a collaborative prioritization.

This kind of behavior was anticipated. Thus, we have planned a second round, when they were specifically asked to split into two teams, each having the whole budget of the technical management. Various and diverse discussions took place. A team whose members work on Scrum projects decided to vote and reached a consensus. The other team, whose members had various backgrounds, discussed first of all on how they had to organize themselves. Then, they started discussing on the distribution of the budget. Both teams exceeded the time limit set for the discussions. I had set a 15-minute time limit for the first part. I had deliberately (and successfully) trapped them by not setting a time limit.

In conclusion, here are several lessons to be learned from this exercise:

- When it comes to collective work (sharing the budget), it is important to collaborate and exchange in order to ensure the needs are met.
- Even in an environment where there are few rules, it is advisable to establish some requirements (common methods, etc).
- The relationship with time is often complex, as each of us has their own sense of time, but we must manage time by imposing a time limit to a collaboration. It must remain effective.
- In an environment without a designated manager, one can notice that the people who take control are those who have the will to make the mission progress.

The participants will be able to express their views on this blog regarding this exercise, but it was rewarding as a first experience. For the future PM Camps, we’ll do other exercises, otherwise, we won’t be able to have 2 rounds anymore.

For those interested in these innovation games, I advise you to read Luke HOHMANN’s book, “Innovation games”. You’ll find the description of other games in this book (among others):

Speed Boat: Identifying what the client doesn’t like about your products or services.
Product Box: Identifying the most exciting product characteristics.
Remember the Future : Understanding your clients’ definition of success.
Show & Tell: Identifying the most important artifacts created by your product
Start your day: Understanding when and how your client uses your products.

I’ll have the opportunity to come back to the results of these experiments through Innovation Games. We are within an Agile cycle, we experiment, evaluate and decide (PDCA).