Post 2- Value Stream Mapping for ALM Ranger’s VSTS Extensions Work Stream

In my last blog post, I wrote about benefits of Value Stream Mapping (VSM) in the realm of software development. I also wrote about how we, the ALM | DevOps Rangers, plan to use it in our VSTS Extensions work stream.

Our first target was to produce an “AS-IS” Value Stream Map. For this, our biggest challenge was to ensure that all relevant people were included. Since, ALM | DevOps Rangers is an independent, self-managed community with people working around the globe, it wasn't easy. We identified that for VSM, we needed to include our Champion Rangers and our community program manager (Willy Schaub). We held a number of sessions with selected people during which we discussed all aspects of our VSTS Extensions projects. Our discussions revolved around our decision-making process, release pipeline and dependencies. We also talked about some of the gripes in our work process and came-up with the following AS-IS value stream map.

<CLICK> on images for a crisper view

Reading our AS-IS Value Stream Map

The VSM diagram might looking daunting at first look but as I explain, you will see that it’s quite straightforward.

Let’s start with defining what each of the symbols in the VSM mean

A typical Value Stream Map contains three pieces of information

1. Process Map
2. Direction of goods / information, and
3. Timeline

For ease of reading, we also included “process areas” in our Value Stream Map. These are depicted by blue rectangles. This helps compartmentalize our Value Stream Map. I will explain the VSM by going through each process area.

The timeline shown in the top or bottom of process area depicts the passage time and gives a good indication of how long each process takes. The peaks in the timeline is when we are working and the trough indicates the time when we are waiting on something to happen or someone to respond.

VSTS Extension Identification

The first stage of our VSTS extensions development is to identify the requirement and need of a new extension. This process area is highlighted below

The process starts with one of the Champion Rangers floating out an idea of a new extension. The idea is typically originated from a work experience or feedback from community.

The idea is shared in an email with all active Rangers. Rangers respond to the email with their views. If the idea gets some traction, the Champion Ranger works further on it. He/she story boards the idea, makes a formal presentation and sometimes also creates a prototype. Our community's program manager (PM) makes sure that an Epic is created for the idea so that work stream is tracked. He also finds relevant people in Microsoft’s VSTS team to get their views.

The idea is presented to the Rangers community as well as selected teams in Microsoft. Microsoft being the Product Owner of all ALM | DevOps Rangers projects have a say in the feedback loop. Once the VSTS Extension has gone through approval process, it is included in the list of in-flight Rangers projects and discussed in the sprints.

The timeline above shows that our identification process typically takes 3 weeks. This includes time when we are waiting for approval or gathering feedback.

Planning

We follow a lightweight process for planning our VSTS Extension projects. Two major activities happen in this process area.

1. The project is initiated. The team is given a name, a team project is created, a wiki is set up, etc.
2. The project team is set up. This is done by PM sending out an email to the wider Ranger community asking for their participation. Rangers reply with their interest and a choice of Rangers are selected.

The following VSM snippet shows the process area in our AS-IS Value Stream Map.

As shown by the timeline, our planning is swift and usually happens in a day.

Build & Release

The build and release process area is when the actual development work of VSTS extension is done. It is highlighted below

During this process area, teams work autonomously . It’s up to the team to decide on how often they do stand-ups, what methodology they pick, how work items are created and distributed. The status updates from the team are fed back to the other Rangers through sprint reviews.

The project is kick-started by generating files using VSTS extensions generator tool. The extensions generator is created by us and help us in creating boilerplate code files needed for an extension. This ensures that the project starts on a sound footing. We also create continuous integration and release pipeline builds for the project. We use our Roll-Up Board widget as a reference project for creating our release pipeline.

A typical VSTS Extension takes about 3 sprints to complete, although this might vary for different extensions. Once the project team has completed development work, a call is sent out to the wider Rangers community to do some testing. We also ask Microsoft’s UI quality assurance team to undertake user interface testing. The extension is then released to a limited set of people, who would install the extension and give their feedback

Once the feedback loop is completed, the project is then ready to be released. The release of VSTS to market place needs to be approved by Microsoft, our community program manager and the Champion Ranger running the project.

Quite often, during the development process, the VSTS extension team identify features that they would like to add to the extension. So, once an extension is released, the team immediately starts work on the next version of extension.

Some times, we learn things while developing an extension that we would like to incorporate in other extensions as well. For this, a maintenance release is created for each of the other extensions. This results in the start of a new project and the extension’s development team works on incorporating the changes identified in the maintenance request.

Maintenance Release

Maintenance Releases are started because of findings / lessons learnt from other VSTS Extensions projects. Maintenance Release projects are like new extension projects except that typically they complete in a sprint. The release process is light-weight as well and approval of either Microsoft, PM, or Champion Ranger is enough to release updates to market place.

The process area is shown below.

Bug Fixing

Even after a VSTS Extension is shipped, there is a continuous feedback loop from the wider development community. If a bug is reported on the VSTS Marketplace, the Champion Ranger reviews it and assigns it to the relevant team. The team fixes the bug, the change undergoes testing and the change is released as a lightweight release. Similar to Maintenance Releases, either the Champion Ranger, PM, or Microsoft can approve the release.

The process area is shown below.

VSTS Extension Deprecation

We monitor all published extensions for feedback from the community and to assess the usage count. Once we find that an extension is no longer relevant or its not being used any more, a deprecation request for the extension is started.

The request is reviewed and once both the Champion Ranger and PM have agreed, the extension is removed from marketplace and the VSTS Extension team is disbanded. The process area for extension deprecation is shown below

What Next?

The work we did for producing our AS-IS Value Stream Map helped us identify a number of improvement areas. The first area we are looking to change is to reduce the dependency on our community program manager. The role is currently vital in bringing people together, decision making and facilitating the development process. Going forward we would like to work as a self-managed community. We are working on this and will share our learning in future blog posts.

THANKS TO REVIEWERS – Rui Melo, Ken Muse, Henry Been