You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
About the Author: Yuhui Gan, 10+ years’ experiences in software engineering management and system architecture, worked in the IT department of an international bank and large consumer enterprise. Rich practical experiences in Scaled Agile implementation, cross-product team collaboration and IT project management.
In the current age of VUCA, we are facing many challenges in delivering software with high efficiency and quality. However, seems there are always some conflicts between fast implementation and overall management. It’s no doubt that the implementation team is keen to be more agile in order to make faster delivery, in the meantime, overall management is also important for quality assurance and risk control. Is there any way to make a balance of the two so that we can deliver software or service faster and better?
Started from mid-2017, after 1.5 years’ hard working, we completed the transformation of our IT department (over 500 IT staffs) from extensive management to delicacy management, built the collaborative management model and setup quantitative metrics based on Jira. We successfully implemented the combination of Scaled Agile and Delicacy Management, and Jira had also become a core management tool in our company. The below system diagram shows what we have implemented so far. While looking back on the whole process of the transformation, there are many stories that we would like to share with you.
Get a hard mission and a “problematic” tool
Two years ago, our company put forward the strategic goal of “Optimize organization & Efficiency oriented”. For our IT department, in order to achieve this objective, we worked out an implementation plan with two targets, 1st is strengthening IT cooperation, improving engineering efficiency, 2nd is enhancing IT management maturity, building the management model for IT projects and set up performance indicators in software engineering.
This is complicated work, and for the implementation, it requires proper tools. At the time, for the management tools, our first choice is Jira, because our IT department had already purchased Jira along with a series of plugins, and Jira had been used by most of the IT teams for nearly two years. We assumed that everything should go smooth, based on Jira, following the implementation plan to fulfill the IT needs, and finally achieve our IT’s and also the company’s objectives. However, the reality is not as smooth as expected. On the contrary, due to the lack of professional guidance and maintenance, Jira had been complained by almost all the IT teams. In an important meeting which we aimed to collect the feedbacks of existing management tools, our core development team raised a number of issues about Jira and hoped that we can replace Jira with other management tools as soon as possible.
“To give up Jira or not” was really a hard decision. If we give up Jira, that means the previous costs and efforts on Jira will be wasted. To adopt a new management tool, other than the applicability of the new tool, we also need to consider the stability, extensibility, and system data migration. If we continue using Jira, we must prove that Jira is able to fulfill our usage scenarios, so that to address IT colleagues’ pain points with Jira. Whatever the choice is, we need to ensure that all the IT teams can have an agreement on the usage of tools, build up the IT collaborative management model, and finally achieve the objectives.
Find out the root cause
To find out a proper solution, we must figure out the root cause. “What is our management needs, and why Jira is not able to satisfy our usage scenarios”. To find out the answer, we took the core development team as the start point and interviewed various roles of the team. By synthetic analysis of everyone's feedback, we finally came to an important conclusion, we need a “Product-Project Management” model, which our Jira couldn’t fulfill at that time. Below diagram illustrates a full picture of our needs.
First of all, let’s take a look at the "Product" part on the left. Based on the current software architecture designation, a comprehensive platform is normally divided into front-end and back-end. Front-end system mainly consists of the applications for mobile and PC. Mobile applications will have iOS, Android, WeChat and other compositions. For PC, by following the SOA designation, subsystems or modules will be built according to their functionality, such as CMS subsystem, product module, a payment module, and so on. Backend system is about the middle ground and background services, this part normally will have over 20 services bases on microservice architecture designation. So, from the product perspective, for the "Product" column in the above diagram, each element, in fact, can be defined and managed as a separate product, as each element has its own evolving life cycle according to the continuous updates from business requirements.
Let’s turn to the “Project” part on the right, when IT department receives a requirement from business, the responsible IT PM (Project Manager) will create a corresponding IT project to follow-up, and IT BA (Business Analyst) will further breakdown the business requirement into product requirements, then the product development teams, including developers and testers, will work on the implementations. Take “Christmas promotion” for example, actually, it’s not a simple requirement, the implementation includes not only front-end applications, such as mobile APPs, WeChat and PC module, and also includes back-end middle ground and background services, for example, product service, order service and so on. It is also important to note that, for the IT team, the on-going project always runs parallelly, that means each production release generally contains requirements from many different projects.
In conclusion, we have two management dimensions, one is PBS (Product Breakdown Structure) from the product perspective, and the other is WBS (Work Breakdown Structure) from the project perspective. Our biggest pain point lies in the management of these two dimensions, each project role has its emphasis on management, summarized as below,
Every cloud has a silver lining
In fact, when our IT teams began to use Jira two years ago, a number of methods and technical solutions have been tried, but none of them have been able to solve the “Product-Project Management” issue. As a result, we decided to invited professional Jira consultant, to help us to find out the feasible solution. After some comparison, we finally chose Unlimax, a Jira platinum solution partner in China, to give us professional guidance. Unlimax’s well-experienced consultant Hong Wang, quickly worked out a solution and helped us break the deadlock, from then on, we are opened to a new world, and the key of this door is the characteristics of Epic.
One question we usually get tangled up is, the “Project” in Jira should manage project or product. Base on the openness for Jira “Project”, it’s more likely to manage product, because an important feature of the project is that, project has specific start time and end time. But if we use Jira Project to manage product, how about project? There is an important feature for Epic in Jira, that’s Epic can correlate with Story or other standard issue type across different Jira Projects. If we manage Epic separately in a Jira Project, and put Story in other Jira Projects, what is the result we can have? Consultant Hong Wang’s designation for Jira’s “Product-Project Management” model can be shown as the following diagram.
According to this management model, each product is managed in a separated Jira Project, these Jira Projects are corresponding to the “Product” dimension, and only has “Story-Subtask” 2-levels. Each product team can follow its own practice using Scrum Board, Kanban Board or other Agile tools, that’s to say, whatever methodologies and tools a product team is using will not affect any other teams. Additionally, the product team can make good use of the properties in Jira Project, for example, using “Fix Version” to manage the “Product Release Version”, using "Component" to specify the product modules, also we can set up “Permission” independently for each product. All of these can fulfill the management needs of the product team.
Epic level is managed in a separated Jira Project. This Jira Project is corresponding to the “Project” dimension, and each Epic stand for a specific project. In fact, what we call project, is usually a set of requirements, so this solution also matches the original definition of Epic. For the Epic’s work breakdown, it should be decomposed into product Story, which has been separated managed in different Jira Projects, then we can use “Epic Link” to identify the association between Epic and Story. Furthermore, “Fix Version” in the Epic Jira Project, represents the “Platform Release Version”. This solution meets the project cost calculation and project scheduling needs from the requirement owner and the project manager. The most important thing is, Epic to be defined as the smallest release unit, it can be the bridge to connect Jira with downstream DevOps Tooling, in this way, task management and engineering implementation are joined as a complete streamline.
Stand higher to look further
Now we have the solution for “Product-Project Management” in Jira, the biggest problem is resolved. However, the “Epic-Story-Subtask” 3-levels management model still has a limitation, summarized as below,
By using Structure, a plugin in Jira, we can clearly see the works breakdown from the “Business Requirement” level to Epic, and to the detail implementation task level, shown as the following examples.
Structure – OBS & WBS
Delicacy management with quantization
Once we have the management model, we can move forward to set up key factors and metrics for delicacy management. There are many exercisable indicators for IT engineering, and based on our experience and practice, we just summarized two suggestions as below.
So far, although we have set up a number of indicators for the IT management, actually we just have 3 key factors that require manual input, listed as below.
eazyBI - Utilization report
eazyBI - Productivity report & Project cost report
Additionally, during the daily works in the scaled teams, it’s quite often that we encounter a collaborative problem. For example,
BigPicture - Work allocation
easyBI - Personal tasks with Gantt chart
A Hybrid Model
Looking back to our mission and objective, actually what we need is a hybrid model, which is a combination of Scaled Agile and Delicacy Management.
Conclusion: Make Jira more than just a tool
Jira is a flexible management tool. In my opinion, the biggest difference between Jira and the other management tools is that, Jira itself just provides the basic management elements, we can combine the various basic elements which provided by Jira, integrate the customized management ideas into the tools, build up the appropriate collaborative model, to fulfill the management needs from different working roles. Thus, it can be learned that, during the practice of management, the tool itself is only a technical means, what is more important is the consensus of the people, we must not only respect to the working needs and habits from various roles of the team, but also keep a certain degree of professionalism and position, so that to form a joint force, and finally achieve the shared goals.