Tuesday, July 10, 2012

Intentional duplication of effort: learning and prototyping

When do you want to duplicate effort?  You often want to duplicate learning across a team.  What about prototyping?

Last week, I read an internal report from Maris Fogels at Canonical about the virtual sprint that he and his team ran. The goal of the sprint was to learn how to write Juju charms.

A virtual sprint means that they all met together online for several days in a row, continuously using some high bandwidth communication like voice chat. They used our company's Mumble servers. We, on our squad, probably would use Google hangouts. We have found that we really prefer being able to see each others' faces.

Maris' team had the interesting idea to all develop the same charm independently and simultaneously at the sprint. They intentionally duplicated effort among themselves.

Moreover, they were writing a charm for a service that already had a charm (and a fork, it seems).

Clearly, the reason for the duplication of effort in this case was educational. They wanted everyone on their team to have a direct understanding of what the challenges and best practices were.  However, since one of our squad's goals is to reduce rework and reduce duplication, this really jumped out at me. 

It struck me yesterday that this learning experience was very similar to our goal to build a prototype at the beginning of every project. I had been thinking that we would collaborate and build a single prototype, or possibly two, for any one given project. That might still be the best approach. But I wonder if it would be valuable to start with everyone developing a prototype individually.

I can see three dangers to that approach. First, if one prototype "wins" then the developers of the other prototypes might feel disappointed, or worse. Competing within a team is dangerous, I think. The multiple prototypes should be a learning experience, and not a competition.

The second, related danger is that the feedback loop in which everyone on the team learns from the mistakes and successes from others must not be too long. People often forget the problems they encountered soon after they solved them.  A quick feedback loop among the participants can keep sharing strong and active.  The format of the virtual sprint could help a lot with this – if everyone is always available on a voice chat, then sharing is only a word away. Beyond that, though, having a time to share at the end of every day might also be valuable. Everyone would report on what and how they had done.

The third danger is that the individual prototyping would add too much time to a project's start: you might lose the speed that collaboration can bring.  The format of a sprint could provide a clear timebox to the effort here.  As long as at least a couple of the prototypes got to completion within the timebox, this would probably work fine.  But there's no guarantee of that outcome.  Perhaps also the quick feedback loop from the previous point would also help.

I wonder if two developers who proved to be following very similar paths might want to join up after a day or two and consolidate their efforts. Would it lead to less individual learning? Would this lead to better, faster prototypes? How long would you "force" people to go it alone?  I don't know. It seems like an option to leave on the table though, and an experiment to try.

In summary, I thought that what Maris' team did sounded compelling and interesting, and I think it might be applicable to initial prototyping as well as learning a new technology. The two tasks seem very similar.

1 comment:

jml said...

Thanks for posting this.

I remember being told once about set-based design, where two or three teams/individuals build their own thing according to their own design, governed only by meeting already establish constraints (i.e. within a bounded "set").

Then, at the last responsible moment, the designs are merged. That might mean throwing one away, or abandoning a good part of one for a better part of another.

It's at the last responsible moment to maximize learning.

I've heard about this, and would like to see it tried one day. I think the dangers you point out are right.

"People often forget the problems they encountered soon after they solved them." ­– Truer words were never said.

When exploring new tech for explicit learning purposes, I keep a pretty detailed running log. This is partly so I can write snarky blog posts, but also so I can go through the hacks, kludges and work-arounds I made and learn better ways of achieving the same thing.

On the sprint you describe, I wonder if it they would have learned more if they tried to write a charm for actual use. "How does this actually help?" need not be a skeptical question, nor an antagonistic one.