Are the ALM Rangers for me and vice versa?

At the recent technical event we had the opportunity to discuss a number of questions that have emerged for the ALM Rangers face to face, as well as dry-running our Ruck process in an instructor led lab again.

Last edited 2013/07/29

Why are we not presenting at ALM Summit and TechEd?

Good question … we would appreciate your feedback in the comments section on why we should extend the ALM Ranger sessions to TechEd, ALM Summit and other events.

What is the ALM Rangers eBook concept all about?

ALM Ranger guidance projects used to ship one or more guidance documents, one or more quick reference posters / sheets and one or more Hands-on Labs. This resulted in a mountain of content which becomes daunting to consume and maintain. With the Better Unit Testing with Microsoft Fakes (Visual Studio Test Tooling Guide) project we performed an experiment to unite guidance, walkthroughs and quick reference sheets into one PDF document that looks and feels like an eBook.

Based on the phenomenal downloads 30,000+ and positive feedback from the community the new format is definitely finding favour.

A walk-through is essentially a hands-on lab, which assumes a certain level of knowledge and takes a higher-altitude view. For example, in traditional hands-on lab manuals we included 2-3 pages on how to create a team project. In a walkthrough, this would be a one liner, with an optional hyperlink, i.e. create team project X (see @MSDN_ref for more information).

The proposed change reduces the documentation “noise” and screenshots which are costly to maintain.

Ideas

1. Keep eBook guide <100 pages.
2. Include a checklist with hyperlinks, instead of a verbose step-by-step walkthrough.
3. Include core walkthroughs and quick reference sheets in the eBook.
4. Focus on core scenarios, moving outliers and highly specialised guidance to separate whitepapers and/or blog posts.
5. Supplement the guidance with one or more videos which walk through the technology.

Objectives

1. Reduce footprint
2. Improve readability
3. Focus on practical guidance, avoiding step-by-step product feature coverage which is where MSDN excels. 

How do I join / get nominated to join the ALM Rangers?

Peruse aka.ms/vsarunderstand and get an active ALM Ranger (aka.ms/vsarindex) to nominate you. Thereafter await the assimilation process.

How do I know if I am suitable to join the Rangers family?

If you answer yes to all of the following questions you are likely to be an active and successful ALM Ranger.

• You are passionate about Visual Studio ALM.
• You are passionate about ALM communities.
• You are passionate about working with other ALM Rangers.
• You are able to work in transparent, autonomous, virtual and disconnected team environments.
• You are able to work with ALM Rangers you may never meet in person.
• You are able to balance work/home/Rangers balance … see rule #1 below.
• You are able and keen to invest an average of 0.25h/day of your personal time in the ALM community.
• You are a self-starter and self-motivated individual.
• You are able to work with other cultures and across time zones.
• You are able to and keen to share testimonials in using the tools or guidance to allow us improve quality of service
• You are not afraid to assume ownership of an ALM Ranger solution feature.
• You are not expecting to be spoon fed with requirements and what-to-do-next.
• You will not go DARK, ever.
• You will not over commit.
• You are not joining for the t-shirt or other swag.
• You are not looking for glory.
• You are not looking for lonely one-person projects … Rangers == transparent team!
• You see the ALM Rangers as your extended family.
• You agree with the ALM Ranger core values (aka.ms/vsarunderstand)
• When at events, such as TechReady, you are committed to find and meet other ALM Rangers face to face.

How do I “hit the ground running” when I join the ALM Rangers?

When you start with the Rangers write rule #1: Family > Job > Rangers > Other on your bathroom mirror. Prioritise your involvement and commitment (bandwidth) to the Rangers accordingly and preferably start with non-critical paths, for example reviews or testing support. Once you have been assimilated into the Rangers “family”, collaborate transparently and keep an eye on the Ranger discussions, monthly show-what-we-have events and in particular the monthly Ranger flashes to find the project that you are most passionate about. Anisha Pindoria, for example, is a good example of how not to start your ALM Rangers adventure. She landed as an Associated ALM Ranger, engaged with 2+ teams as contributor and UX advisor, completed the Ruck Certification program … a tough adventure if you know our Judge Ruck (Brian Blackman) in person) … and ended up amongst the top 5 active ALM Rangers during FY13 (Ranger Flash – June 2013) in less than one Ranger year.

What is Ruck? A process, standard, guidance?

The Practical Ruck Guide and ALM Guidance: Visual Studio ALM Rangers — Reflections on Virtual Teams  talk about what Ruck is and how it got its name from the game of Rugby, where it means “loose Scrum”. What I want to emphasis at this point that it is not a standard, nor a formal process. It is guidance based on dog-fooding and project experience within the ALM Rangers world and should be used by Ranger teams as a guide, not as a Judge Ruck set of rules. Every ALM Rangers team has the autonomy to morph the recommended guidance to suit their requirements, as long as it does not break the ALM Rangers infrastructure.

What is the process of submitting ideas for new projects and how are they selected?

An idea should be submitted on Visual Studio UserVoice, using the Rangers category or including “ALM Rangers” in the description. During quarterly triages we look at all ideas in the Rangers category, ideas that contain the text “ALM Rangers” and top ideas in terms of votes. We create a list, ask the ALM Rangers to donate their vote and finally sit around a virtual table with all stakeholders to prioritize the backlog of ideas.

To get the “thumbs up” to pursue an idea we need a passionate product owner, passionate project lead, 3-4 Epics/Features and a healthy amount of community support (votes).

If you have “the idea”, capture it on Visual Studio UserVoice, add as much detail as possible and engage with your community to support your idea through their votes. Keep an eye on https://blogs.msdn.com/b/willy-peter_schaub/archive/tags/ideas+triage/ which summarises the “what happened to your idea” after triages.

Why are User Stories and especially tasks often sparsely documented on Ranger projects?

The ideal ALM Rangers project has a product owner, a project lead and 4-5 contributors, all of whom are passionate about the context of the project. Each contributing Ranger takes ownership of an area of the project, which is typically contained within a User Story, refines the user story description, confirms the acceptance criteria and then creates the tasks, descriptions and time estimates to implement the user story. There is complete transparency, autonomy and most importantly zero spoon feeding or mandating.

The ideal ALM Ranger project therefore starts with a set of well-defined Features/Epics, owned by the product owner, optionally a set of lean User Stories and tasks needed to implement the feature.

Now that the FY is over, when are we starting new projects?

Two years ago we switched to a two wave of projects per year cadence, a year ago to a quarterly wave of projects cadence and as discussed below, are pondering over a continuous “ripple” cadence of rolling releases. Our project idea triage and project schedules are not aligned with the financial year.

For more informationperuse ALM Rangers Dogfooding of the Team Foundation Service which summaries a lot of the new era concepts that we have been dog-fooding.

If a solution ships version X, do we have to raise another idea on UserVoice for version X+1?

The Ruck guide recommends a time-box of 3-4 months to ensure the team has a peg in the ground to aim for major releases, i.e. v1, v3 … vN. As mentioned an ideal team starts with a small core team, which grows by adding reviewers as and when needed.

In the past the project team used to disband until new request was received from the community to do an update or new release. Going forward we would like to see small core to remain focused on the solution, actively manage the solution discussion forums and continue work on revisions, i.e. v1.1, v1.2 … v1.n, which are not time-boxed and ship when and as the quality bars are met. In essence we would like to see a rolling release of revisions as and when updates are available, rather than waiting for major releases.

Lastly, why was Willy smiling so much at the TR event?

Last time we checked we had an average of 4.77/5 across nine ALM Ranger sessions, which is a phenomenal 95%. More on this in the upcoming Rangers Flash.