“Save” Jira- A Practical Model of Enterprise Scaled Agile with Delicacy Management

[#1]

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,

• Product owner focuses on the product changes during each production release.
• Product team wants to run the agile methodology that they are accustomed to.
• Project manager concerns about the project timelines, costs, and risks.
• Business analyst pays more attention to the progress and the cost of the requirements.
• Developer and tester want to have a clear picture of the tasks assigned to them.
• The whole IT team is eager to combine task management and engineering implementations so that to improve engineering efficiency and finally achieve DevOps. As we know, Jira is developed from defect management, it can be said that the core of Jira is “Issue +Workflow”, it’s not considered from a product management perspective at the very beginning. Furthermore, for the “Project” item in Jira, literally, it’s more likely to be designed for the project management, does it mean by using Jira, we cannot manage product and project at the same time?

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,

1. As Epic is the smallest release unit, for a specific business requirement, it may involve a number of Epics. Let’s think about the business requirement of “Christmas promotion”, this promotion actually has serval phases, such as phrase one which may begin from mid-November, then phrase two starts from 1st of December, and so on. For each phrase, IT team will work on the corresponding Epic for the production release. In this case, how should these Epics being connected together, to indicate that they are contributing to the same high-level business goal?
2. Epic is more about the IT requirement, it’s created from the business requirement. For the business, they are more concerned about the IT implementation progress of the business requirement, and what can be achieved at each rollout stage.
3. A business requirement usually involves multiple comprehensive platforms across multiple platform teams. For example, for the “Christmas promotion”, in addition to the updates on e-commerce platform for end users, it requires not only supports from product system and logistics system in the ERP platform but also financial changes in the SAP platform.
4. For IT project implementation, we have two types of outsourcing projects, one is using human resources from ODC, and the other is using fixed-price contract with SOW which defines the scope of works. By managing the work breakdown in Jira, we can calculate the cost of ODC by summarized the work hours that spent on each task, but for the fixed price contract, normally we just care about the progress at each milestone and the final result. If the implementation for a business requirement is mixed up with these two outsourcing modes, how should we mark the relationship and dependency between these projects, and how to calculate the final cost of this business requirement?
5. Not only the IT department but also the company will make a yearly budget plan base on the collected requirements. These requirements are strategy-oriented and coarse-grained, obviously, Epic is not suitable for the budget estimation in this yearly plan, because it’s closer to an implementation plan. The solution should be clear based on the above points. As the saying goes, "The higher you stand, the farther you can see". In order to solve all the listed problems, what we need to do is to add one more level, the “Business Requirement” level, it’s a level that business and senior management more care for. This “Business Requirement” level is directly linked to the company's strategic objectives, and it’s also the unit for calculating the required ROI. Additionally, the “Business Requirement-Project” breakdown structure is just the OBS (Objective Breakdown Structure) from business and senior management perspective. We can even extend the management scope by using this structure, to manage not only “IT Project” but also “Business Project”. At this point, for the IT department, the entire IT collaborative management model is completed, the final “Business Requirement-IT Project-Story-Subtask” 4-levels management model is shown as the below diagram.

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.

1. The factors of the defined indicators should be easy to collect, do not create a mess of inputting fields which is not practically used and give the burdens to the IT teams.
2. The indicators should be easy to understand, easy to calculate with a simple formula, common to teams and executable.

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.

1. Task’s estimated work hours
2. Task’s actual work hours
3. Task’s due date Base on the key factors, we can use eazyBI (a Jira plugin) to create a lot of useful reports. Let’s take the “Utilization report”, “Productivity report” and the “Project cost report” for example.

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,

1. How to make the team more agile while it’s overall in controlled?
2. How to identify the critical path and critical tasks?
3. How to rationalize the work allocation for the team members?
4. How to make the tasks of each member transparent to the team? We can make good use of BigPicture and eazyBI, to help us to solve the problem. In order to have visual management, we can add one more key factor, Task’s start date, and then we can have the tasks in a Gantt chart.

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.

[MI 501]

Strategy goal - "Product-Project management" use Portfolio management => business goal, budget, demand mgmt... manage not only product but also services

IT objectives - EPIC use Program management => group your demand/change according to your need

Project management => spawn out from your program to run in its own right, here you can use any model that best suit the expectation, SCRUM, KANBAN, ASAP/ACTIVATE etc... this level is PRODUCT DRIVEN that remove all assumption and automatically enable rapid interaction between user and developer.

Jira software can be configured to integrate the Portfolio, Program and Project management, and of course, doing what it does best for SCRUM and KANBAN.