Monday, November 9, 2009

Agile Besançon

So tonight we held the first meeting of what I’m calling Agile Besançon… it builds upon some organizing work that Ludovic, Olivier, and Regis have done in the past—going back as far as the coding parties that Olivier held at his house.  Tonight’s meeting was held in a conference room at Temis Innovation, the incubator for the startup I work for, Smartesting.

Ludovic and I facilitated a discussion on Managing Multiple Projects at Once. Conventional Agile wisdom recommends against multi-tasking, and against running multiple projects with the same team, because task-switching incurs a heavy performance cost.  Still, some teams cannot get their management or their customers to focus—so how can they cope?

We started the meeting with a brief check-in, describing how we hope to have monthly meetings where we can play, practice, and discuss topics/skills that we don’t normally address during our work day.  Then we showed how we planned to use the time for the evening—check-in until 7:15pm, game until 8:15pm, and retrospective until 8:30.  We all introduced ourselves with name, job title, and company affiliation, 11 in total, 3 companies represented. 

Ludovic and I had invented a group exercise to help people warm up to the ideas we’d be presenting—the object of the game was to use an assembly-line of workers to build paper airplanes—15 copies each of 2 different models.  We started with a 5-minute prototype phase—and the Acceptance Test for completion was that the plane had to be able to fly across the room.  After a brief pause, we gave each team (of 4) 5 minutes to build their planes—but they were forced into a Taylorist mini_P091109_19.41[02]production model—one person rips out a page from an old magazine, next person puts one fold into the sheet, next two people are plane builders—of the kind of plane they had prototyped.  In 5 minutes each team had built about 6 planes—and we then talked for 5 or 10 minutes about what we noticed.  Then each team had a 5-minute huddle on how to improve the assembly line, followed by another 5 minutes of production.  This time each team produced 16 planes—but one team focused on model A, while the other team built both types.  Only one team noticed a hidden requirement written on the whiteboard—that the customers only pay for completed batches of 15 planes.  mini_P091109_19.41[01]Afterwards, we talked about the strategies the teams used to speed up (moving more people to the plane-building role, thanks to Theory of Constraints), and we talked about what might help them reach the goal of selling both plane types.  mini_P091109_19.41Someone suggested re-negotiating the batch size requirement—and we said that is an excellent way to deal with multiple projects—that as soon as we can get to small releases (minimally marketable features), it’s not as penalizing to switch off to another project—but to switch before releasing means shelving the unfinished investment and therefore indicates waste.  We followed this discussion with a perfection game on the game itself:mini_P091109_20.19

The notes, translated from French, indicate that we should keep the:

  • short iterations
  • brief reflection after each iteration
  • simple materials
  • prototype phase

For next time we might consider changing:

  • construction targets—different objects, like a boat and plane, or simple folds instead of more precise objects
  • don’t run an acceptance test for everything?
  • the number of projects (have more than 2), and find a way to get people more actively involved in decision-making/collaborating
  • making different objects worth different prices, maybe depending on the construction cost

Points of confusion, open questions:

  • what was the overall goal?
  • how can we help people be more collaboratively involved?
  • deliver airplanes?

We ended the night with a quick Blond-ROTI chart (Return-On-Investment):

mini_P091109_20.29   

Translated, on a scale of 1-10, people rated the following:

  • Worth it to come to the meeting tonight:  8
  • I learned something: 5-8
  • I will change something tomorrow: 1-7
  • I’m ready to lead a discussion for the next Agile Besak: 2s and 8s
  • I’ve encountered this problem: 1s and 9s
  • Would it be interesting to have more of us: 8-10
  • I will invite someone the next time: 9-10
  • I’m ready to come the next time: 10
  • There should have been more experience reports [tonight]: 10

No comments: