When leading high tech innovation projects you usually face some recurring problems:

• How do you exert indirect pressure for requirement freeze?
• How do you transition from R&D to factory?
• How do you improve the team's autonomy and release the lead innovator?

I'm going to touch briefly on a simple micro-team structure that addresses these requirements in a simple manner. Simple is Good because you won't forget ;).

The Innovation Module Micro-Team

I call the following 3-man configuration an "Innovation Module", consisting of one lead developer and two wings:

In this setup, the lead ( top ) is normally a subject expert who keeps tight contact with the customer and is given a preponderant weight in the team. The role of the other elements initially is mainly to support and offload the lead, remove roadblocks, fix bugs and undertake blocks of well-defined tasks. This is a highly agile structure for early stages of innovation and high customer contact and works particularly well with small scoped, specialized projects.

Dynamics and Evolution

The distribution of work is dependent on the stage, overall flux of requirements and complexity of the project. If an initial requirements gathering phase is taken and requirements are defined to great extent, then more work can be routed to the “wing” developers and lead appears sparsely. The more they stay in flux, the more work that has to go through the lead.
This is a way to transfer some control on innovation, design and research overhead to the customer so he can make adjustments regarding their own involvement and their commitment to the requirements ( lead time is usually much, much more expensive ). Therefore, this is an effective way to exert indirect pressure.

As the project evolves throughout agile iterations and specific business requirements become clearer, the team can move onto a different PMO supported structure and adopt a more scalable product oriented methodology such as Scrum (which we use internally for product development) to undertake more requirements across more projects.

In an ideal situation, the lead developer will be eventually replaced by a generic, shared project manager or PMO, and he will be free to bootstrap a new Innovation Module somewhere else.

Conclusion

I know of similar approaches, but this is my extreme simplification. Keeping it simple allows me to fit it into other methodologies, get the message across to the customer and remember the core principles.