ALM Rangers ALM Dogfooding – What is a silent release?

ALM Rangers are passionate about technology and about adding value to the ALM community. Many have said that they do not have a 24x7 job … they are having fun 24x7. It is extremely important that our “hobby” and the “fun” does not turn into a “job” … otherwise we will loose the passion, the innovation and the sheer endless energy that many of the Rangers are pouring into the ALM community.

The objectives of the dog fooding is not to introduce rigid processes, but to experiment with concepts and ALM technologies to create an environment in which we can deliver better solutions, quicker and more regularly in an environment which is productive and “fun”.

What are we dog fooding?

To keep track of the dog food we are chewing on, let us summarise the main initiatives and the reference material ion this blog:

Overall	How the ALM Rangers are using Visual Studio ALM … in a practical nutshell
Ruck Process	World-Wide Virtual Teams from the ALM Rangers perspective (Part 1) ALM Rangers ALM Dogfooding and the “Angst” Factor – Part 3 ALM Rangers ALM Dogfooding and the age of the visual board – Part 4 ALM Rangers ALM Dogfooding, Ruck and the new TLAs – Part 5 ALM Rangers ALM Dogfooding … dealing with bugs on tfs.visualstudio.com – Part 8
Documentation styling, usability and content quality	ALM Rangers – Raising the Quality Bar for Documentation (Part 2 ... ‎ ALM Rangers ALM Dogfooding … pondering over documentation – Part 6
Tooling usability and quality	ALM Rangers – Raising the Quality Bar for Tooling (Part 1)
Quick Response solutions	ALM Ranger solution types and a practical walkthrough of the Quick Response concept (Part 2) ALM Rangers ALM Dogfooding … proving the new process and lifting the last confusions (we hope) – Part 7

So what is a silent release?

2013/02/23 UPDATE
This process feature has been incorporated into Ruck. Refer to the ALM Rangers Practical Ruck Training and Reference Guide on Supporting Guidance and Whitepapers for the latest version.

When a team gets to the point where the Epics are crossed out, bugs asleep, features packaged and the consensus is reached that the solution can ship, we usually refer to the state as DONE.

What followed was typically a final technical review and edit. Afterwards a release, followed by feedback from the community a seemingly endless cycle of revision of review, signoff, ship to get to a point where the product owner, the team and the community are aligned and happy with the solution.

Pushback from the community (you) has often been for us to release bits earlier, so that we can gather feedback and incorporate it before going “public”.

Welcome to the silent release dog food

 

In essence we have two options for a silent release:

• Option 1 – We get product owner (PO) approval to do a silent release before completing technical review and assessments.
• Option 2 – We complete all reviews and assessments before we get product owner (PO) approval to do a silent release. (Recommended option)

When we ship silently we release the latest bits to the community as a BETA, without making a public announcement. We notify the ALM Rangers and selected community members, action their feedback and eventually get to the point where the product owner (PO) signs off, we ship and make a public (bells and whistle) announcement.
Make sure you always look at the Dev status property on CodePlex, whereby Beta usually indicates an early (silent) drop and Stable signals a final release. 

Peruse https://aka.ms/vsarsolutions where we will indicate which solutions are currently in a silent release phase.

Thoughts?