On Roadmaps and Teams, Part One

I agree with most of what Christoph Otto posted earlier this month on roadmap items. But I think the relationship between roadmap items and the teams of Parrot developers who will work on those items needs a sharper focus. Here are my thoughts:

  • The Parrot Developer Summit to be held on the weekend of Jan 29-30 must set roadmap items for next 4 supported releases.
  • Roadmap items are those we pledge, to ourselves, our users and the world, to deliver in the specified releases on the specified dates.
  • Roadmap items should therefore be few in number and have strong support among our developers. Few enough that we can under-promise and over-deliver.
  • We need to draw a sharp distinction between roadmap items and everything else. Absolutely no "wishlist" or "nice to have" items may go on the roadmap. None whatsoever! There is no such thing as a "secondary" or "second-tier" roadmap item.
  • Because of our high degree of commitment to roadmap items, we cannot consider anything for placement on the roadmap unless it has a team of people committed to implementing it.

So what do we mean by 'team' with respect to roadmap items?

For a group of our developers to be considered as a team with respect to roadmap items, the following are required:

  • A team must have a name. (If the team is one of our 'permanent' teams -- Architecture/Design or Product Management -- that name will suffice. But it's more likely that the team will take its name from that of the roadmap item.)
  • A team must have more than one member. A 'team' of only one member is no team at all.
  • A team must have a designated leader to whom project members outside the team look for news about the roadmap item.
  • Each member on the team must acknowledge that he or she is on the team. (Otherwise, team members are not accountable to each other for results.)

Let me stress: Anyone can work on a roadmap item and is encouraged to do so. Anyone can work on non-roadmap goals as well and is encouraged to do so. Anyone can be a member of a team, work on its roadmap item, and still work on non-roadmap goals as well.

What sets team members apart is that they are publicly pledging to deliver on the roadmap items.

What sets roadmap items apart from all other goals is that the Parrot Project as a whole is publicly pledging to deliver on them.

Now, you might say, "kid51, you're taking an awfully hard line on this. Why are you drawing such a sharp distinction between roadmap items and all other goals? And why are you drawing such a sharp distinction between the role of team member and the role of a contributor working outside a named team or on his/her own?"

I am taking a hard line, and I have no regret about doing so. I'm emphasizing the importance of teams committed to implementing roadmap goals because I believe that otherwise we will never create a virtual machine that other software developers will be enthusiastic about using.

More about that in my next post.