Visual Studio 2012 and Team Foundation Server 2012 bring a valuable set of features and capabilities to agile teams, providing an easy, simple-to-use experience on top of a powerful, customizable platform that is continually evolving.
We were the first users of the service and have been embracing and dog fooding the Team Foundation Service (http://tfs.visualstudio.com, previously http://tfspreview.com) since April 2011. Many things discussed by the subject matter experts (SME) as possibilities at the latest internal technical event (TechReady) have been part of our (Rangers) ecosystem and daily lives for months … hence this post.
If you would like to understand why we *love* dog fooding, peruse the post Why we believe in dogfooding.
This blog post intends to share our dog fooding experience and give the ALM Rangers an overview of the processes, practices and challenges.
Single team project model … why?
We have reduced the number of team projects from a 1:1 relationship of project : project team, to three team projects, of which one is active and two supportive. VisualStudio.ALM is the home for all new active or reactivated projects, VisualStudio.Help contains sample data as a help when working with the backlog and VisualStudio.ServMode contains projects which are in inactive maintenance (service) mode.
The Ranger_Sandbox is a separate playground for the Rangers to experiment with and use for demos, which does not form part of our operational ecosystem.
The relationship and move of projects is shown below:
The other Team Projects shown above are being retired as part of the ongoing maintenance.
Advantages we see
- Productivity gain … less context switching and better sharing of resources such as queries.
- Better visibility … aggregated view of all teams within a single team project allows make it much easier for the Ruck Masters to observe and mentor teams.
Challenges we have had to date
- When does a project belong in ServMode and will it remain forever?
We do not have the answer yet. We currently move all pre-VisualStudio.ALM projects and all VisualStudio.ALM projects that are not maintained to ServMode. When a project is revived, it moves back to Visualstudio.ALM as an active project.
Shared backlog … feasible?
As mentioned our team project VisualStudio.ALM creates a home for all projects and teams focused on ALM projects. It creates a shared and “single backlog to rule them all”, creating a single view of work items, status and visualization, as well as a source of unassigned Epics and associated product backlog items and tasks. To assign an Epic to a team, we simply reassign the Epic to an area path that is owned by a team. Simple!
Our Ruck support and mentoring team uses special root queries and the task board visualizations for a high-altitude view of all teams and their projects. They detect the smoke, avoiding the raging fires
Challenges we have had to date
- Ill-defined or assigned Epics, product backlog items and tasks are easily created unintentionally by Rangers unfamiliar with our Ruck process, polluting the backlog.
- A backlog custodian and regular inspection and maintenance is required to maintain an actionable shared backlog.
Different sprint cadence … practical?
We have divided the financial year into twelve (12) monthly main sprints and each month into two sub-sprint. Starting FY13 with sprint 1 on July 1, 2012 we are incrementing the sprint number by one each month, which means that sprint 13 will be the start of FY14.|
Teams are able to start projects on the 1st or 15th of every month, adopting monthly, 2-week or a mix thereof sprints. We are no longer starting projects together, but allow teams to start whenever their infrastructure, requirements and associated epics are ready.
Advantages we see
- Flexibility … projects can start when they are ready to start, with a worst case wait of 2-weeks.
- Better visibility … as mentioned before the shared backlog and single team project allows make it much easier for the Ruck Masters with aggregated views and simple query sharing.
Challenges encountered to date:
- Association of sprint and calendar months is difficult, requiring a calculation from July 1st, 2012 or a lookup of the iteration configuration data (see previous illustration).
- All teams have adopted a 1-month sprint cadence to date, giving us no experience with the 2-week or hybrid iteration models.
Version control branching strategies … be agile and adaptive!
Sitting in Micheal Learned branching sessions at TechReady we started to ponder over our branching strategy.
By default we use either basic (two branch) or feature branching scenarios to (a) dog food our guidance and (b) the TFSBranchTool.
Micheal Learned made a clear statement that we should not be afraid to change and evolve a strategy to suit our environment. Our FI’s from main to dev branches usually come up with “no changes”, which means we probably do not need the isolation and complexity. We are therefore busy changing most of the teams using the basic (two branch) scenario to the No Branch Plan or Basic (single branch) scenarios … watch the space on feedback.
Team ecosystem … in the cloud, we Azure you
We recently introduced the concept of a silent release, which allows us to make the final bits visible and accessible to all, gathering and auctioning feedback before making the release announcement and opening the flood gates.
Challenges we had to date
- Not all users take note of the version and stability of the silent release, resulting in support surprises and unfortunate disappointment. Although infrequent, these misunderstandings are unacceptable and something we are working on.
If you have any questions, please do not hesitate to add a comment, to contact the ALM Rangers nearest to you or pinging me direct.