How we built a project management system based on Azure DevOps

Four trackers mean four different processes, project templates, assembly and deployment systems we supported. The road to the single tracker began with an experiment — moving one of the teams from the non-Microsoft stack to Azure DevOps. Coincidentally, the experiment was conducted virtually before the pandemic quarantine, but it didn't stop us. And in less than a year, all of our engineers shifted to Azure DevOps. 

Why Azure DevOps

We studied the capabilities of different trackers meticulously and chose the Microsoft Azure DevOps (formerly TFS) platform. In its basic purpose as a universal planning tool Azure DevOps boasts several advantages: 

• Convenient task distribution and individual team member workload planning interface that takes vacations and switching to other projects into account;
• In the dashboard mode, task parameters can be adjusted in one click, the same for task creation;
• Remaining task work is automatically recalculated when reporting the duration, and gets reset to zero when it is solved;
• One can plan at the level of features, epics; and an analogue of a category can be set in the Area field.

In general, the features of the platform go beyond a project tracker; it combines virtually all the components required for development: project management, builds, tests, releases, and a code repository which was quite important for us. 

What we got from shifting to a single project management platform

• We developed best practices and swift experience sharing between teams without issues caused by varying approaches and tools.
• 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 trackers for staff who are simultaneously working on different projects (designers, technical support, QA).
• We standardized managerial processes: performance analysis, invoicing, staff deficit calculation, and strategic planning. All of these are quite challenging when each project is run in its own way.

Single platform transition stages

We moved the teams one by one, and each time the process was split into several steps. 

1. Preparatory stage: project management principles. First of all, we introduced a single set of project management rules and principles. Our managers were put in charge of operational project management in trackers. We seized manual task creation, moved everyone into trackers, and abandoned the timesheet check procedure. Thus trackers became a place for both managing and accounting the team’s workload.
2. Introduction of a single project template. The template records simple and clear statuses and rules for shifting between them: rules for nesting tasks and bugs within PBI, PBI decomposition into tasks, their statuses, categories, rules for using tags and handling bugs we receive from clients. 
3. Consolidation within one project management system. Then we started moving all teams into the single tracker — Azure DevOps.
4. Integration with Git. At this stage, the teams were retaining a hybrid work model when Azure DevOps was already used as a tracker and Gitlab was used for code versioning and managing CI/CD. This simplified the transition since the teams didn't have to learn to work with three tools at once. The changes proceeded gradually: first the tracker, then Git, then CI/CD. But the use of Gitlab required creating a special Gitlab - Azure DevOps integration so the statuses in the new tracker would change automatically following the actions with the code.
5. Shift to Azure DevOps Git and building CI/CD pipelines. The final stage was creation of new assembly and app deployment pipelines utilizing Azure DevOps CI/CD. In recent years, Azure DevOps has been refined significantly, and the pipeline creation principle is practically the same as Gitlab's — this allowed the teams and the DevOps engineers to redesign Gitlab pipelines into Azure DevOps without changing the paradigm. The presence of assembly and deployment pipelines allowed the teams to move to Azure DevOps and abandon Gitlab entirely. The transition to Azure DevOps created a kind of an out-of-the box integration. For instance, while creating a Pull Request, the task is shifted into Code Review status; and during assembly and release, all related tasks are marked so what was included in the release can be seen.

Plan of moving teams to the new tracker

We had a separate plan for each roadmap element. Here we will describe the steps in transferring the teams to the new tracker. The rest are topics worthy of separate articles. 

1. We launched double integration when a team was working in the old tracker, but copies of tasks were already generated automatically and moved by statuses into Azure DevOps.
2. We picked a date at the sprint junction so that the maximum number of active tasks would be solved, and “toggled the switch”. The developers saw all their statuses in the new system.
3. We examined the changes in the project structure and formed a new list of business categories for task classification.
4. On D-day we set up the project and switched it to Azure DevOps. The team started to work in the new tracker.
5. In the process, we performed a daily task register revision to check congruence of task types, their parameters, sprint presence, statuses, planned and actual labor costs between the two trackers. When discrepancies were found, integration errors were corrected.
6. In parallel, a demo of the new project structure and its operation rules was conducted for the team and the client.

Tool development: how Azure DevOps was customized for individual needs

During operation, we had already modified the platform to fit our needs. For instance, we added the following services. 

Dashboards with key development process and time-to-market product measurements. The main qualitative and quantitative development metrics were unified. We entertained the idea that true usefulness is virtue of dashboards born by life itself. So practically all the analytics that are now shown on the board used to be collected through queries, Excel registries or direct downloads from the tracker.

Image

It is important for us to monitor the unfinished tasks for the current sprint in real time, track tasks without assessment, unsolved tasks in production, and 'release candidate' tasks. All these are potential sources of risks that must be addressed (change priorities, adjust customer expectations, etc.). 

In the past this required additional efforts: remembering about the next sprint statistics gathering, asking the team the same questions. Now there are analytics in the tracker and the process of managing tasks which grants immediate picture of the situation after just looking at the schedule. 

Any team member can use such analytics, and the manager doesn't have to remember each time what exactly a chart displays. When a common coordinate system is spread over several teams, processes can be scaled. And unification is exactly what we strive for within our development platform. 

Associating autotests with the test plan. Azure DevOps pipelines enable automated tests to be run and reports to be got from them. Yet it was unclear how to compare such a report with the checklist, and shape it in the way we needed. Therefore, as a part of the transition to the Software Developer in Test (SDET) concept, we developed our own custom extension for Azure DevOps which associates autotests and test cases.

Image

Integration with Jira, ServiceNow and other systems. We need to synchronize our tracker's data with clients' trackers and other systems. A standard scenario — a ticket from the client's Service Desk comes to tech support, is transformed into a task in the sprint, and then after its deployment in the product environment the status must be returned to the client's Service Desk.

This can be solved simply and elegantly using BPMN Camunda which ensures automatic status movement across tasks and their correct depiction both in our and the client's systems.

Integration with MS Teams. We use Microsoft Teams to communicate within the company and with clients. The integration helped organize the process when client's questions regarding the tasks must be answered quickly while communicating with the team and monitoring if the comments got updated.

This was solved with a separate channel in Teams where comment events from Azure DevOps are gathered. 

Summary

Shift to Azure DevOps and refitting the tool for our needs let us:

• Erase boundaries between different technologies (.NET and JAVA, mobile development) in process management, and evaluate time-to-market in varying products in the same way.
• Provide all company staff with a common vision of the development management 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.
• Reuse good practices in task and team management between projects (settings, dashboards, metrics).