Team performance dashboard
Supporting managers to track developer team performance on Walhall platform
What is Walhall?
In an article I wrote, I describe what Walhall is and how it could be of use, not only to developers but also to UX designers. Being a new product, the USP is constantly being improve upon. However, my article describes a possible benefit of Walhall marketplace tot he UX research process. For this case study, an understanding of Walhall shows the need for separate team performance reports from those already supplied by popular project management tools like Jira Software or even Git issues in Github or the likes.
One of the unique selling points of the Walhall platform is the introduction of framework agnosis in the development cycle. Typically, developers perfect specific tools and frameworks holding the product hostage. This makes adapting to better trends slow, hectic and costly. For example, a team that has adapted Angular framework for their frontend may be limited in hiring process to developers familiar with Angular, leaving out hordes of other developers who can add value to the product.
With Walhall, developers can combine microservices built with various frameworks, both backend and frontend, into one functioning application supported by the core API. This means that teams no longer have to be restricted to working with specific frameworks. At the moment, Walhall supports Angular and React for frontend and for backend and blueprint templates to build microservices it provides Django, Express and Flask frameworks. These are planned to keep including popular frameworks in the future.
Having said that, the most important benefit is that teams with already existing products in any of these frameworks can pull their repositories in Walhall and carrying on working. everyone loves low switching costs! However, this introduces a new challenge: decentralised teams, especially large ones with several products in multiple geographical areas may have the very problem of having their multiple products using different code and project management tools. This means that issue management and team performance analysis becomes pretty complex.
To address this challenge Walhall has considered its own team analytics dashboard that aggregates data across various issue management tools. Currently, Walhall considers Github issues and Jira but in the new future it will include Bitbucket and Gitlab. These tools individually provide team performance reporting but nothing exists in the market currently to combine data across several tools and produce one comprehensive report. Walhall promotes tool agnostic project management.
Design challenge
Existing issue management tools are designed with custom data points to produce reports for their own dashboards. This means the naming convention and the data points used are different from one tool to the next. It is possible to export data to spreadsheets to be used with third party BI tools but that means that complex migration scripts might be required to aggregate data from the different tools. The challenge for Walhall is to generate aggregated dashboards from supported issue management data sources.
The process
User needs
The user of this tool would be the dev team manager. This need was based on internal needs by current project managers which became the assumptions for the typical persona who would use this feature in Walhall.
The main needs were
- to aggregate performance data from all repositories whose issues are managed using different project tools
- to break down performance data based on individual team member contribution
Researching existing tools
As mentioned, several tools already exist in the market to manage issues. Walhall currently considers Github and Jira Software. The first thing I did was to get really familiar with Github issues. This would be the basis of the design because Github is very popular and offers issue management already. Companies can then opt to extend project management functionality by purchasing other tools like Jira.
In addition, Github issue management has a basic feature set that can be used to design the proof of concept for this stage of Walhall design. From Github, we would be able to consider additional and custom data points that may be introduced in future when the platform incorporates other tools. I kept Jira in mind just to note any future major conflicts that can already be considered in design.
For instance, Jira has specific sprint boards while Github doesn’t, per se. In Github, users can use milestones feature to define sprints and with the use of extensions such as Zenhub, they can view sprint boards. This understanding was important to know whether it was at all possible to display sprint based reports.
Wireframing
Following an understanding of existing tools, I proceeded to do sketches and wireframes that would be the first point of discussions. I was required to produce 3 types of reports to begin with. The included bug/issue, pull request resolve time and issue lead time all with a section showing team performance in each situation.
My previous brief stint as a project manager for TolaData made my understanding of user needs better. Some of these were the data points I was reporting on at the project management meetings including how individual developers were performing per sprint.
Several discussions were done with the CTO, project manager and developers to consider the minimum product we could implement. As at the writing of this article, the developers are working on the implementation. We also have no real users on Walhall currently who can test the system with actual data. We based the designs on what internal project managers would like to see. I shall update the results of this design when we get to test real data.
