Visual Studio ALM Rangers Ruck and Engineering v2 enhancements?!? … getting ready for the next wave of Ranger projects

We are preparing for an imminent and huge wave of new Ranger projects, which are based on the Visual Studio ALM Ruck process. A MSDN Magazine article titled “Visual Studio ALM Rangers—Reflections on Virtual Teams”, scheduled for September, takes a more detailed look at Ruck within the challenging Rangers environment.

Unfortunately we missed the milestone for the article to add the numerous enhancements we are considering for dog fooding with the latest wave of projects. Instead we will summarise the enhancements in this blog post, share our thoughts and will hopefully encourage some candid feedback and discussions under the comment section.

Enhancement Description Objective(s)

Epics defined before & for kick-off meeting

Epics were a bold new drive to define the “low hanging fruit” and the “eye of the problem” for each project, from which the product backlog, the tasks and eventually the deliverables evolve.

The Epic enhancement we are planning is to define 2-3 Epics before the project is “kicked off”.

  • Define a manageable scope and expectations by limiting the Epics to 2-3 per release.
  • Deliver a clear vision by presenting the Epics at kick-off.
  • Reduce the usual delays, black-holes and churn after kick-off, allowing the team to hit the ground running.

Small single digit teams

In the past we used to invite as many Rangers as were interested to participate in projects.

Going forward we are looking at constraining project team size to single digit size (1-9) and constraining rangers to commit to 1 (recommended) – 2 (max) concurrent projects.

  • Reduce the administrative overhead we experienced with large, distributed and virtual teams.
  • Create focused, dedicated and passionate teams.
  • Create collaborative environment within distributed and virtual team environment.

Dev and Epic Leads will scribe deliverables

Project Leads are expected to use consistent templates (mentioned below) to create a base set of deliverables to define the scope.

In addition they will add pseudo-structures/content to the key deliverables which will guide contributors in terms of style and content.

  • Reduce misunderstandings in terms of expectations.
  • Reduce wastage of invaluable bandwidth on  features that are not aligned with Epics.
  • Reduce the frequent fall-off of invaluable resources, passion and interest, due to uncertainty of expectations.

Engage Contributors early & Reviewers late

In the past we used to invite as many Rangers as were interested to participate in projects, asking for both contributors and reviewer roles/

In future we will only ask for contributors at the start of the project, inviting all Rangers as observers from the start and as reviewers when there is content to review.

  • Reduce the administrative overhead we experienced with managing potential reviewers.
  • Focus all energy on contributors early in the project to ensure early delivery of features.
  • Focus reviewers on available content.
Consistent use of templates
The past projects have been based on templates already.

We are planning to not only introduce a revised library of templates, but introduce the concept of a standard set of deliverables for guidance, out-of-band or both solution types.

One checklist guides project leads with the project process and a second checklist with the minimal deliverables, and associated templates.

  • Consistent look&feel for all deliverables.
  • Reduced merge and formatting efforts by subject-matter-experts (SME) and project leads when consolidating features and content.
  • Improved content  and format when delivering to reviewers.
  • Improved navigation through deliverables.

We are casting the foundation and the concrete needs to be set at the end of this month. Thoughts … comments?

Skip to main content