ALM Rangers ALM Dogfooding and the age of the visual board – Part 4
This is a continuation of the dog fooding discussions:
- ALM Rangers switching to single TPC/TP and multiple Teams model
- ALM Ranger solution types and a practical walkthrough of the Quick Response concept (Part 2)
- ALM Rangers ALM Dogfooding and the “Angst” Factor – Part 3
Dogfooding update … where are we today?
We are in the process of migrating our operational TFS environment to one based on the Visual Studio Team Foundation Server Planning Guide and all new and active projects and teams are operating within the new ecosystem.
Single Team Project
- As shown, we are consolidating all active projects focused on Visual Studio ALM in a single Team Project named VisualStudio.ALM.
- Projects and their ecosystem are isolated using TFS Teams.
- Each team and in some cases feature teams within teams have their own team work item queries.
- VisualStudio.Help is a sample environment, with sample Epics, product backlog items and serves as an evolving reference environment.
- VisualStudio.ServMode is a team project that contains a team and the associated artefacts for all projects that have entered service mode. If one of these projects is dusted off in the future, a team will be instatiated in VisualStudio.ALM.
Consolidating the individual Team Projects
The consolidation of the operational environment is an ongoing process, running at a lower priority than projects, work and family 
- As mentioned, VisualStudio.ServMode is a container for the service mode projects.
- The list of service mode projects is growing and each project is isolated using TFS Teams
- Project teams can create their own work item queries in the Service Mode Projects folder
- The remaining team projects will be migrated one by one to VisualStudio.ServMode as they enter the service mode status. We are only moving the latest codebase and no WIT or other historical data as we do not need the historical data.
Retrospective … what are we learning?
It is important there is a mutual benefit to all stakeholders and that everyone sees value in undertaking the dog fooding. Observations are continuously fed back into our evolving Ruck process, we service the teams with a more effective environment, we are pushing the tooling to many boundaries and beyond, and through ongoing feedback (such as this) we are hopefully sharing value with the community.
What is going well?
Benefits to date:
- Productivity gains
- Aggregated and detailed view on feature teams and their backlogs
- Ability to see the “smoke” (smell) before encountering the “firestorm”
High-Altitude Rangers View
 |
As documented in previous posts we have a support team, that supports, mentors and assists the feature teams. The image on the left shows that the support team has “high-altitude” and aggregated view of work with crisp visual feedback. This has become my default view and one that I reference regularly for a visual and effective summary across all active projects within the Visual Studio.ALM team project. A small side effect is that I am also reminded of the total number of tasks I am responsible for. |
Low-Altitude Team View
 |
With the detailed team view we get specific backlog and status information. The visual feedback for the backlog, changeset and build information next to a real-time burn-down chart is a great productivity enhancer for the program managers, the project lead and team members. Using the boards is simple and effective, allowing us to perform quick and effective stand-ups, updating the board real-time with very little (seconds and clicks) effort. |
What is not going so well?
We are still battling to balance scope creep, enthusiasm and passion within a sprint, which results in 3/5 projects hovering above the ideal trend-line. What we are trying to determine is whether it needs a tweak in planning, program management or simply keeping the board up to date.
Looking at the illustration below you notice that the FY13 sprint runs from 1st July 2012 to 30th June 2012, whereas the burn down shows only the first 6 months. This itself is not a problem, however, the trend line intersects the X-axis in January 2013, not June 2013. Although the tool is not intended to be used with very long sprints, the team is investigating and we are expecting the trend line to adjust itself in one of the future updates 
What can we improve?
From a Ruck (see ALM Guidance: Visual Studio ALM Rangers — Reflections on Virtual Teams for more information) perspective we are constantly and continuously learning and evolving. Based on the latest batch of projects we will be focusing on:
- Managing the backlog, the expectations and the scope creep more pro-actively
- Work on clarifying the vision and sprint objectives earlier and re-enforcing them in every ((bi-)weekly) stand-up
… I am sure the Rangers involved in the latest projects have many more ideas