Value Management Office (VMO)

Agile Programme Assurance using Azure DevOps for Product and Portfolio delivery teams through a Value Management Office (VMO)

Prior to COVID-19; Product and Development teams tended to work in groups at the same location with infrequent remote working. 

Usually every Friday would be a day to catch up on emails and then produce Programme / Project status reports using project templates.

The Programme Management Office would then consolidate these reports into a single tracker and distribute them as per the defined governance routes. Lots of time taken, lots of backward and forth clarifying status would be the norm.

In less than 4 months, all of the clients globally dispersed Product and Programme Management community coupled with engineers were enthusiastically shifted to Azure DevOps.

Enter the Value Management Office

Agile Programme Assurance using Azure DevOps for Product and Programme delivery teams through a Value Management Office (VMO) is a concept that began as an experiment, moving one client's team from a non-Microsoft stack to Azure DevOps.

The team chose the Microsoft Azure DevOps (formerly TFS) CMMi Template which complemented the Product and Scrum processes required by the business. By using Azure DevOps, the team was able to track benefits, governance meeting details (RAID), milestone tracking, task distribution, and individual team member workload planning. The final solution combined virtually all the components required for benefits tracking: development, project management, builds, tests, releases, and a code repository.

By shifting to a single project management platform, the migration team brought a number of distributed teams that now work predominantly remotely into a OneTeam approach to delivery, standardised managerial processes, developed best practices, assembled a single CI/CD pipeline, and simplified email communication.

Also Risks, Issues, Assumptions and Dependencies (R.A.I.D) coupled with Change Requests, Milestones and Benefits were all linked and associated with each Requirement in the Product Backlog.

The end result was OneTeam with One Version of the Truth for real time Benefits tracking against all elaborated Requirements (User Stories) with their associated test cases fully captured.

Why Azure DevOps

The team chose to use Azure DevOps because it complemented their Product and Agile Scrum processes. The final solution combined all the necessary components for benefits tracking, including development, project management, builds, tests, releases, and a code repository. This made it a great choice for the team.

From the outset the team studied the capabilities of different Azure templates (Agile, Scrum, Basic and CMMI) meticulously and chose the Microsoft Azure DevOps CMMi Template.

In its basic configuration as a universal planning tool Azure DevOps boasts several advantages:

• Benefits tracking, utilising the inbuilt Delivery Planning capability;
• In Dashboard mode, we surfaced all the details required for each governance meeting – such as number of requirements delivered in each sprint / iteration, number of change requests in flight and delivered (with associated benefits), number of risks and issues open / closed and those that needed updating;
• Milestone tracking through Azure Boards assigned to each major requirement delivered via each sprint / iteration surfaced via summary dashboards;
• Very convenient task distribution and individual team member workload planning via the summary dashboards interface that takes vacations and switching to other projects into account;
• Product Owners / Managers and Project Managers can plan easily at the level of features, epics; user stories can be set in the area field (Tailored Work Item types).

What we got from shifting to a single project management platform

The solution went beyond the standard project tracking method and was fully equipped with all necessary components.

• We brought a number of distributed teams that now work predominantly remotely into a OneTeam approach to delivery;
• We standardised managerial processes: performance analysis, Product Lifecycle management and strategic planning. All of these are quite challenging when each Product / Project was run in its own way;
• We developed best practices and swift experience sharing between teams without issues caused by varying approaches and tools through global, follow the sun workshops that captured the import Ways of Working (WOW) the solution must provide;
• We assembled a single CI/CD pipeline with automatic task movement by status;
• We simplified employee rotation between projects so they don’t have to learn new technologies;
• We simplified work in several trackers for staff who are simultaneously working on different projects (designers, technical support, QA).

OneTeam transition stages

We migrated each geographical team one by one, and each time the process was split into several steps.

Preparatory stage: project management principles. The first step in our process was to establish a unified framework for project management using the Azure DevOps CMMi template. This involved assigning key stakeholders to lead the migration and implementing automation to streamline task creation and requirements capture;

Introduction of a single project template: we tailored and configured the CMMI process template to align with the requirements identified in workshops, including clear work item statuses, rules for nesting tasks, and handling of risks, changes, configuration management items, defects and test cases. We also established guidelines for task decomposition, status definitions, categories, acceptance criteria, and the use of I.N.V.E.S.T guidelines.

How we did it!

We implemented a separate subscription and plan for each geographic location and roadmap element to ensure seamless transition for teams. The process of transferring teams to the new tracker was executed in several steps and is a topic that deserves further discussion.

• To ensure a smooth transition, we implemented a double integration approach where teams continued to work in their legacy processes while copies of tasks, requirements, and test cases were automatically exported and migrated to Azure DevOps. The delivery team then conducted a thorough accuracy check of the imported data;
• To minimise disruptions and ensure a successful transition, we carefully planned the implementation date and chose a time that coincided with a sprint junction, when the maximum number of active tasks would be completed. This allowed us to "toggle the switch" and immediately provide Product/Project Managers with visibility into all task statuses in the new system;
• After conducting an examination of the project structure, it was determined that adjustments were necessary. To ensure alignment with business objectives, all task categories were mapped to corresponding delivery plans. This approach improved the overall efficiency and effectiveness of project execution. The adjustments made to the project structure were validated and have been implemented at the executive level;
• In parallel, a number of workshop demos of the new project solution structure and its operation rules was conducted for the team across all geographies;
• Licences: To track licence consumption we enhanced our ability to report in real time through deploying PowerBi.
• Integrations: As we learnt new ways of working we deployed PowerAutomate for richer capabilities with our integrations.
• On D-day, we set up the project and switched it to Azure DevOps. The team started to work in the new solution with minimal hand holding.

Tool development: how Azure DevOps was customised for individual needs

To improve transparency and decision-making, dashboards were developed to showcase key metrics related to product and programme management activities, including development process and time-to-market measurements. These metrics were carefully calibrated through collaboration with key stakeholders during a series of workshops. By leveraging the "Overview - Dashboards" feature of Azure DevOps, we were able to establish a centralised source of information, known as a Single Version of the Truth, to clearly communicate the benefits achieved through our efforts.

This approach enabled executive leadership to stay informed about the progress and impact of our product and programme management efforts.

We needed to keep track of what we have done and what still needs to be done in real time. These dashboards helped us to identify and solve any potential problems that may have arisen. In the past, this was difficult and time-consuming, but now we have Azure DevOps working to make things easy.

Going forward Azure DevOps can be used by anyone on the team, and it makes easy for the manager to understand what is happening.

Integration with Jira, ServiceNow, MS Teams, Slack and other systems

We needed to ensure we could exploit other tools in our inventory. A standard scenario was a ticket from the businesses Service Desk comes to Product management and Tech support, this needed to be transformed into a task in the Back Log and or the next sprint, and then after its deployment in the product environment the status must be returned to the Service Desk.

We adapted these tools to work well across different teams, so we can work together more efficiently.

Integration with MS Teams. We used Microsoft Teams to communicate within the business and across different time zones. The integration of MS Teams helped organise each workshop into a requirement gathering session with tracked outcomes in the tool.

This was helped by creating a separate channel in Teams where requirements where elaborated and migrated into Azure DevOps as tracked tasks.

Summary

The Shift to a Value Management Office utilising Azure DevOps as a single source of truth let us:

• Provide all company staff with a common vision and single version of the truth of the product management and development processes and tools. As a result, cross-project processes, rotation of specialists between teams, and staff work in several teams at once — all these became easier and less of a barrier.
• Best industry practices in task and team management between projects were reused across all geographies. These best practices spanned across planning, dashboards, metrics, risk and change, testing and benefits tracking.
• We adopted what had been learned and used in the Atlassian suite of applications and migrated the best of that into Azure DevOps, making the transition less of a potential road bump.