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.