Rolling triages and fire-and-forget projects enable us to increase responsiveness and diversity

In continuous process innovations, many of which are outlined in Managing Agile Open-Source Software Projects with Microsoft Visual Studio Online, we evolved the rolling triage and the fire-and-forget project type.

Rolling triage

In the past we processed quarterly triages of project ideas, many originating from UserVoice, creating four main waves of projects per annum. As shown, some side-effects were last-minute spikes of activity as teams realised they needed to wrap-up, and troughs during which resources are on the bench, waiting for new projects.

We introduced the concept of a rolling project idea triage, triggered whenever a project enters its last scheduled sprint. The rolling triage allows us to investigate new project opportunities, and resources to engage, while we wind up a project. While we have not been able to nudge the last-minute spike to extinction, the occurrence and impact hereof are on the decrease.

Fire-and-Forget Project

In Managing Agile Open-Source Software Projects with Microsoft Visual Studio Online we share our default and Program Manager (PM)  managed process, with geographically distributed, and part-time resources. It starts with an idea, planning, a fairly detailed roadmap, planning and proceeds with the development and release of a solution, aligned with a common iteration / sprint plan cadence. We often refer to this type of project as a formal project, or project that comes with a lot of ceremony, and a weekly scrum.

Pros

• Predictability, based on roadmap.
• Near real-time insight into status and impediments.
• Can work with one or more feature teams, each with 6+-3 team members.

Cons

• Volunteers with only 15min to spare, find it difficult to engage on projects with pre-defined milestones and priorities.
• We are limited to ~five concurrent projects, based on PM and resource bandwidth.

The new fire-and-forget project begins with the same triage and investigation, but less planning, process, ceremony and typically no detailed roadmap and milestones. Teams self-organise, work through their backlog at their own pace and meet with the PM less frequently, typically every second week or monthly.

Pros

• We can support an infinite number of concurrent projects, constrained only by the available part-time bandwidth.
• Teams can self-organize and work when and how they prefer.

Cons

• Insight into status and impediments is less frequent.
• Does not scale well beyond one team with 6+-3 team members.

As the Program Managers never “forget” a project or associated team, we should really call these projects fire-and-self-organise, but fire-and-forget is simpler and more common.

If you have been keeping an eye on our status board (aka.ms/vsarflightplan) you would have noticed that our first two fire-and-forget projects have taken off, under the leadership of Gordon Beeming and Utkarsh Shigihalli.

We will share the evidence of this new project type as it emerges.

What do you think?