ALM Rangers ALM Dogfooding and the “Angst” Factor – Part 3

This is a continuation of the ALM Ranger solution types and a practical walkthrough of the Quick Response concept (Part 2)  and especially the ALM Rangers switching to single TPC/TP and multiple Teams model discussions, in which we covered the solution types and the Ruck continuous process improvement respectively.

We decided to dogfood our own guidance, stepping through the Team Foundation Server planning guide to come up with the latest process improvements. Many are causing a lot of “Angst” with the LM Ranger leadership, but as our Ruck master (Brian Blackman) says … “nothing ventured nothing gained”.

The “Angst“ Factor for the Single Team Project and Shared Iteration Model

Let’s review some of the “Angst” feedback to date:

Angst

• 1: “Singe team project and Shared iterations just feels a bit scary, but it will be great dogfooding :) ”
• 2: “Shared Iterations: I think it can be hard to force projects to align to a schedule but if possible it is of course a good idea since we can hopefully get progress presented at the same time (for instance a "show-what-you-have" events. ”
• 3: “Shared iterations forces projects to run in synch, but you can't do this with different teams of volunteers. ”

Candid and great feedback, which raise valid concern.

Let us start by looking at what we mean with “shared iterations”.

Shared Iterations in the context of Ruck

As shown in the diagram below we started the new era on July 1st 2012.

• We sliced the financial year (FY13) into monthly sprints, starting Sprint #1 on July 1st. We will increment the sprint number by one each month, which means that FY14 will start with Sprint #13 on July 1st 2013.
• We further sub-divided each monthly sprints into two shorter sprints. For example, in July 2012 we have Sprint 1 (31 days), Sprint 1.1 (15 days) and Sprint 1.2 (16 days)

What does this mean for the ALM Rangers Ruck ecosystem?

1. Teams can select a sprint cadence of 1-month or 1/2 month. ALM Ranger project teams typically opt for 1-month sprints due to the challenging constraints, as outlined in ALM Guidance: Visual Studio ALM Rangers — Reflections on Virtual Teams.
2. Teams can start their project at any time, typically starting at the beginning or in the middle of the month. A team that starts their project on August 1st 2012, would start with sprint 2 or 2.1, while a team starting their project on January 1st 2013, would start with sprint 7 or 7.1. It is important to highlight that the first sprint for a team is not sprint 1, but the sprint that matches the start date.
3. Projects no longer started in two main annual waves, but instead are started when the Epic planning, the team infrastructure and the vision/objectives are ready. This means that throughout the year we will have projects starting at different times, running different with different sprint durations and even suspending and resuming as shown with project B.

To conclude what are we sharing?

1. The teams share the common breakdown of the year into the sprints as discussed within a common (Single) Team Project.
2. The teams do not share the backlog, capacity planning or version control folder, each of which are demarcated by the team Work Area.

 

Looking at our dogfooding environment

If we take a peek at the definition of iterations in our dogfooding team project, we can see the monthly sprints as discussed. The following illustrations show how the support team uses the FY13 node (left image) and how one of the vsarGuidance teams is binding their backlog to the shared Sprint 3, 4 and 5.

Iterations – Visual Studio ALM Rangers Support Team	Iterations – Visual Studio ALM Rangers vsarGuidance Team

 

The Dogfooding Feedback

Too end, let us look at the dogfooding environment. We will continue to transparently report back on the dog fooding, sharing both the good, the bad and the evil experience.

The support team has an aggregated view of the backlogs, monitoring everything in and under the FY13 node. The ability to see all of the Program Manager (PM) PBIs, the Epics and associated PBIs across the entire team project is proving to be great observation, coordination and even mentorship feature … out-of-the-box.

Switching to the Product Backlog board the support team has a consolidated view of all the backlogs, isolated with their Work Area, within the team project.

If we switch to the vsarGuidance – QR team we see a focused view of the backlog, as isolated by the selected iterations and Work Area.

Switching to the backlog presents a focused backlog view as expected.

For a more task-focused view we can switch to the respective sprint.

The image on the left shows the typical Work Items view. Our dogfooding approach, at this stage, is to create a folder for each team, which contains their fine-tuned queries. For example, the vsarGuidance – QR team has a node with three queries to display their Epics, their Backlog and a list of incomplete (todo) work. If we peek into the Solution Explorer, we see our current approach of creating a folder for each team. The default branching scenario is Release Branching - Basic (two branch) and in case of the vsarGuidance – QR team we are using the Feature Branching scenario. For more information on these scenarios and more please refer to: Visual Studio Team Foundation Server Branching and Merging Guide

Switching to My Work, I am presented with an even more focused view which greatly assists me in tracking my personal backlog.

Overall our experience has so far been very positive.

Coming back to the “Angst” factors

• Single team project Angst … the jury will remain to be out for a while. In the interim we will venture out and dogfood our own Visual Studio Team Foundation Server Planning Guide.
• Shared Iterations Angst … once the nature of shared iterations is understood, it should be evident that the teams only have to align to their own schedule and that projects do not have to run in synch or dependent on each other.

We are, as always, interested in your candid feedback. See you next time.