Successfully Embracing JIRA in the whole Project Lifecycle

This two-part series shows how JIRA can be used for other things than just bug tracking and presents mgm’s experiences with embracing JIRA in nearly all parts of traditional and agile project lifecycles, resulting in a number of customized, optimized JIRA workflows and processes. In this first part, I will give you an overview of challenges we faced over the years and how we adapted JIRA to meet them. You will get a taste of the vast variety of uses we have found for JIRA and understand why we decided to use only one tool instead of many.

mgm has been using JIRA for project management since 2005 for all its projects, ranging from small projects (< 5 members), medium (< 30 members) ones up to really large projects with up to 500 members and more. Part of my job is setting up JIRA and designing customer-tailored, optimized JIRA workflows. We’re setting up JIRA externally for customers, usually as part of software development projects, and also internally, e.g. for marketing projects, front-office and administrative tasks.

During the past 6 years, our initially defined processes – especially the ones concerning project management and requirement management – passed through several iterations of refinement. We learned a lot and embraced our lessons learned into improved process definitions. And we introduced more and more agile methods into projects fitting to this methodology. The latest step in this direction was to extend JIRA with Atlassians agile plug-in GreenHopper which enables a gradual introduction of agile tools.

Agile task tracking using the GreenHopper extension.

We make sure that every project gets its own tailored project set-up (set of issue types, workflows, custom fields, GreenHopper configuration) optimized for their individual project needs. And although we have several standard configurations sets for new software projects inherited from our best practises, we use them only for the initial project set-up. Once the basic functionality is implemented we try to reflect the distinct project requirements (character of project, product and customer) by creating an individual project configuration instead of trying to condense them into a one-size-fits-all template.

About our largest JIRA Installation with 700+ People

One of mgm’s biggest pool for JIRA project experiences is the set-up and ongoing maintenance of a JIRA instance that supports a huge multi-project environment with more than 700 active members. The set-up for 28 managed software products is split into 60 JIRA projects with approximately 80 workflows definitions and almost 300 custom fields.

The projects form a network of vertical layers (product software development) and horizontal layers (cross-section functions like quality assurance, expertise, strategic product management, support, operation etc). There is also a strong interdependency between the software projects with respect to results and releases that we had to take into account. One of the largest of these software projects generates an average of 2.500 JIRA tickets for every main release (i.e. every 4 months). So we have a lot of different aspects to consider.

Software Project Process Maturity at mgm

As agile project management patterns become more and more prevalent within software projects, we adapted our projects’ lifecycle with the following steps: The typical project starts with more or less agile iterations in which requirements are compiled and analyzed, followed by the design and modelling phase. After several development cycles with accompanying quality assurance activities and a final software approval process, the software moves into operation. Product maintenance and enhancement projects typically follow release plans and put all necessary cycle steps into more or less short time boxes.

Today, mgm has reached a process maturity that allows us to control all aspects of the project lifecycle through JIRA processes:

  • Requirement management
  • Change management
  • Bug tracking
  • Task management
  • Release management
  • Development cycles and sprint planning
  • Software approval process
  • Quality assurance and test management
Software Project lifecycle and its reflection within JIRA.

Of these aspects, only the requirement engineering part including business modeling (for example using UML tools etc.) and the design of business and technical concepts is typically done outside of JIRA, but even they can be controlled by JIRA tickets with adequate dedicated workflows.

But why do we spend so much effort to squeeze as many lifecycle steps into JIRA processes as possible? The answer is that we have learned our lessons from experiences: we realized there are many advantages in using only one tool instead of a bunch of different ones, thus reducing system discontinuity.

In summary, one tool for the whole project lifecycle has these advantages:

  • Creates more expertise and familiarity.
  • Avoids disruptions of process and media during transitions to the next lifecycle step.
  • Enables fast feedback between
    • Development & Project management,
    • Customer & Project management,
    • Development & Quality Assurance.
  • Facilitates a release oriented approach for development and planning.
  • Allows cross-processing reports and progress control.
  • Helps when introducing agile tools and methods at the appropriate level of need.

Direct Customer Involvement through JIRA

In addition to the benefits to the project as mentioned above, there is one other advantage of using JIRA as the main tool for all phases of the project: it creates a point of access for direct participation of the customer. But why involve the customer at all?

Quite often project managers and suppliers keep away insight into the detailed project work and progress from the customer and just provide him with status reports on a regular basis instead. But our experiences showed that in software maintenance and enhancement projects – especially in large projects – there is less overhead and more benefits for everybody involved if customers aren’t locked out of the JIRA processes.

For example, if the project lifecycle is well defined and well known and all participants know their parts and responsibilities within JIRA, the process runs very smooth. And as all communications can be conducted within this one tool (JIRA) there will be no more bypassed communications, activities and results that have to be painstakingl translated into the necessary JIRA processes and information snippets (and no information should be kept out of JIRA anyway!). Thus, one more cause of problems is be eliminated!

Avoid Creeping Requirements through Process Transparency enabled by JIRA

Furthermore, the customer gets a completely different attachment to ‘his’ project if he is able to see all ongoing activities and if he can generate an actual project state by himself. We have realized that the customer feels much more satisfied and more responsible for his assigned lifecycle parts once he experiences the whole power of process transparency. He also becomes more sensitive for interference factors and usually starts to avoid ‘creeping requirements’ once he realizes the consequences of adding just another “simple” request (but sometimes the exception proves the rules).

Having only one tool to manage and view all processes has the advantage that the customer can concentrate on acquiring only one set of necessary skills. In addition we support the customers in getting all the necessary information by preparing views for his tasks, responsibilities and status reports by creating all needed JIRA filters and dashboards for him. These will then be shared with everyone who needs them on the customer side (or within the project team) – so one set of preparations can be used by any amount of users to get the same results. Another great help are filter subscriptions especially to track and manage time critical process steps. These tend to make the customer’s start in JIRA very smooth and comfortable.

Nevertheless, the customer has to be willing to take an active part in JIRA. If the customer isn’t very technically skilled and has problems with or an aversion to use software tools at all, we can only recommend to stop your efforts to make him an active part in the JIRA process. Compulsion to use JIRA will have the exact opposite effect and creates feelings of unease and dissatisfaction. In such a case stop your efforts to convince him to use JIRA and just claim higher fees for your larger project management efforts.

To be continued…

In the next part of this blog series we will continue with the topic of direct involvement of customers as introduced above and give you some practical examples of when, where and how to introduce and include your customer into JIRA. We will show you some proven real-world workflows that include customer interaction and cover appropriate modes of customer participation.