We are about to post the triage #8 results. Before we delve into the results, let us review how we triaged the ideas and what has changed with the triage process.
triage process changes
We embraced three innovations as part of the eight triage, which impact the results and the way we will process future triages. Our intent is to select projects which are a better win-win for the ALM Community and the product groups, improve the transparency of the triage process and become more responsive and adaptive to the rapid changes in the world of bits and bytes.
In the past we performed a quarterly triage and had near-quarterly waves of new projects. In future we will trigger a triage whenever a project enters its last sprint.
- This does NOT mean that we will start a new project every time a project finishes!
- This means that we can start PLANning the next project and potentially have a rolling triage and wave of new projects.
As introduced in which visuali[s|z]ation catches your eye we are introducing the quadrant triage view, which divides the ideas into four quadrants (reject, community, product group and ranger projects), based on ALM Ranger/Community value and Product Group value.
The intention is to remain aligned with strategies, technology innovations and select the win-win ideas for future ALM Ranger projects.
quality over quantity
|1-3 Projects per PM||For geographically distributed teams we recommend that the number of projects is n<=3 per Program Manager (PM) allowing the PM to focus on the teams and associated flights.|
As part of the triage we now select a maximum of three projects per available program manager (PM).
Impact –> The ALM Rangers can have anything from one to a maximum of six projects in flight.
Every project lead (PL) is responsible for one project, with one or two feature teams, each with seven team members.
- Impact #1 –> Each project engages 1-14 ALM Rangers.
- Impact #2 –> A total of 6-84 ALM Rangers, excluding PM, PL and RM, can be active concurrently.
We are in the process of documenting these innovations, the concept of a TRP (training-research-planning) and QP (Quality-Planning) sprint, and our in-the-field experience with distributed teams. Watch the space!
We are often told the triage process is not transparent and that it takes too long. Agree on both counts!
Duration … the process and elapsed time will not change much as the calculations, alignment, discussions and negotiations with stakeholders, if done properly, takes time. But, as we are switching to a rolling process we will see feedback more frequently and be in a position to action new project ideas more effectively, and most importantly, quicker.
Transparency … the process has been discussed, but it has evolved quite a bit behind the scenes as we evaluated and dog-fooded new ideas. Shown below are the seven steps of the triage process, with a brief explanation. Ping me with a bang(!) or ad a comment to this post if you have any question.
- Start by harvesting ideas from Visual Studio UserVoice, forums and ad-hoc discussions at events such as TechReady.
- Update our backlog on VSO, which also feeds an instance of the flight plan board, similar to aka.ms/vsarflightplan which shows flights in progress.
- Feed the VSO backlog data into our triage workbook, which in turn produces the “raw view” as shown in which visuali[s|z]ation catches your eye. This view shows the value as perceived by the ALM Rangers and their ALM Community.
- In collaboration with product group product managers (PM) and other subject matter experts, we agree on a product group value for each idea, which produces the “quadrant” and “stacked” views as shown in which visuali[s|z]ation catches your eye.
- Submit the triage results and recommended next project candidates to our stakeholders (see aka.ms/vsarindex for details), revise the PG values and return to (4) if needed.
- Publish the triage results and recommended next project candidates to our ALM community (as per this blog post), revising the ALM Ranger values and return to (3) if needed. At this point ideas in the quadrant …
- Reject –> are typically rejected or deferred for the next triage, which allows the community to strengthen the value by increasing support through Visual Studio UserVoice votes.
- Community –> are transferred to the ALM Community for triage, as outlined in ALM Ranger Solutions – Proposed innovations … a byte for your thoughts.
- Product Group –> are transferred to the product group for triage.
- Ranger Project –> are prioritised and queued for “kick-off”.
- Initiate the “kick’’-off’ of the top priority project(s) at the next opportunity and return to step (1) when the next project enters the last QP (quality-planning) sprint.
Right, now that you know how we work behind the scenes, let’s review the latest triage 8 results in the next triage post.
Have we missed anything? Thoughts?