Building successful R&D lecture

Yesterday ended with a networking party at the business center. The music was not too-loud for people to talk, and the space was divided to many areas to allow easy flow and interaction. The partners stands were grouped together at the center of the hall, something I view as a miss (should have been positioned around the walls). After almost not sleeping for 3 days during the Startup Weekend I gave up at around 11pm and went to my room.

I'm currently at Yoram Yaacobi's talk about "Building and Running Successful Product R&D Teams" where he tries to list characteristics for successful R&D teams in recent history (Skunk work, Manhattan project, etc) and in Microsoft.

Anecdotes:

• The explanation behind the "Service Pack 1" approach. Apparently this is a result from having too-passionate QA & developers, keeping finding bugs and postponing the deadline to produce the "perfect product". To solve this an announcement was made - if the bug is not a "Show stopper" (meaning the product can work even with this bug), it can be fixed after shipping with a service pack.
• When developing Windows 95 they had to make sure all DOS games ran on it, so Raymond Chen took a pickup truck, loaded the entire games contents of a large store and installed and tested each and every game, fixing what was needed.

He described the Microsoft development model - A combination of Agile/Scrum and the waterfall model for the long-term. Iteration is between 3 months (for products like Office) and a single month (for smaller scale products). The developer to testers ratio is 1:1.3, but this is probably unique to Microsoft.

Apparently Microsoft tries to predict the market years in advance and plan accordingly. Personally I think this is a little cheating since Microsoft has a major effect on market trends on it's own.

These are the key characteristics he recommend for success:

1. Common language (make sure people terms with same meanings)
2. Clear responsibility
3. Clearly defined expected results each step of the way
4. Progress reports
5. Single primary focus
6. Build or use the best tools (and knowledge repositories) out there
7. Encourage team members to work on their own
8. Driving the team to continuously improve
9. Positive feedbacks to the team