My two-cents on switching to JIRA and defining our workflow – By Amir Rix
03 Apr 2019
My two-cents on switching to JIRA and defining our workflow
What is the best platform to manage our R&D projects? Which approach is better for us, Waterfall or Agile? We discussed these kinds of questions inside TandemG for several weeks near the end of last year. We are no strangers to such methodologies. The RedMine open-source platform served us well for several years. But something had to change.
What was bugging us?
We needed to invest considerable effort in supporting and customizing RedMine. TandemG was (and still is) growing, and that means different requirements. Here is a short list of requirements we had in mind when considering making the change:
- Agile – a platform that will allow us to manage our projects as Agile (but not lose the Waterfall option)
- Low IT/DevOps load – R&D tools sit somewhere between the responsibility of DevOps and IT. We, in R&D, wanted minimal reliance on the outside
- OOTB goodies – platform that requires minimal effort for us to start working. The more out-of-the-box goodies, the better
- Easy configuration – being able to configure system flows and behavior, without the hassle
- Support – have both professional support and a community to answer questions
- Marketplace – our focus is not the platform itself, but rather using it. So, we wanted to be able to extend its capabilities
- Modern UI – big surprise, but SW developers tend to have a taste for good-looking web tools
- We examined several options, but finally we decided to deep-dive into JIRA. We had previous experience with JIRA, and knew that for its price, JIRA would provide us with the above. So, we had it installed on-premise and began a thorough trial (a successful one, as you can imagine).
How we organized the process
TandemG is a multi-disciplinary company. Thus, it was important to have leaders from various fields. We built an internal task-force, responsible for integrating JIRA into our R&D. Erez, Menachem and Evgeny stepped up to the challenge.
We planned a short and focused process: weekly meetings where we brainstorm, decide, try out ourselves, engage users and vice versa.
Engaging users, brainstorming with them and collecting their feedback, proved to speed up the process. It also helped in the smooth integration of the decisions made.
JIRA workflow lets you define your own state-machine for handling various issue types. You can create a dedicated SM for each type (tasks, bugs, epic, …). Each SM includes its own statuses, transitions, related post/pre-functions, and more.
JIRA comes with its own default software workflow. This workflow is suitable for generic issue management. But a one-glove-fits-all approach can’t be realistic in this case, especially where R&D is involved.
IMHO, defining workflows is one of the most immediate tasks, if not “the most”, when starting to work with Jira – Atlassian has a very good blog post about what workflow is and how to build your own. I have found it and additional posts very handy.
Making Our Mark
Our approach was to keep the workflow clean and simple. We wanted to avoid over-engineering, the same approach as we have to R&D. So, we strived to keep the simplicity presented in the default workflow, with only the necessary changes. The end-user will not have the diagram in mind when working inside JIRA, so the flow must be self-explanatory.
Figure 1 – JIRA default generic workflow diagram
First, every transition must count, no redundancy. The result was that we decided to remove the “Reopened” status and replace it with an “In Review” status. We did not see advantages in the “Reopened” status.
You have your comments and log inside the issue for its history, if the need ever arises. But, we wanted to be able to review every issue, either by peer or manager, before marking it as “Resolved”.
You want to have a special focus on them – no redundant transitions.
Transitions allow post and pre-functions. This is very handy when you want to automate stuff in the system. Re-use the transitions where possible (e.g., going back to “Open” state). Each transition must have its own ID, and your automation will fail otherwise. I will leave to your imagination how we discovered that 😊
Same as when coding, you want to use meaningful names, both for transitions and for statuses. These names appear afterwards, throughout the issue life-cycle in JIRA. Also, reusing names from the default workflow, proved to cut errors and ease online Googling.
Last but not least, you want your source control and/or code review tools integrated with JIRA as well. For us, this OOTB capability was a MAJOR issue. We use self-hosted GitLab (free tier) for source control and Gerrit for code review. We integrated both rather easily with JIRA.
You should pay attention to how your workflow interacts with these tools. This is where the transition IDs and their re-use will come in handy.
The outcome was a workflow that fits most of the issue types we have, as you can see below:
Figure 2 – The workflow we defined for almost all issue types
We soon discovered that not all issue types suit this workflow. Well, only one doesn’t – the Epic. This type should have a much simpler flow, reviewing is not relevant here and neither is re-opening. So, we defined a new workflow for it, with a stupid-simple approach.
Figure 3 – Our stupid-simple Workflow for Epics
We have been using our workflow for several months now, in several projects. So far so good. Yet, we know that this is not a fire and forget case. Our workflow may evolve, we may decide to differentiate between issue types or between project types. But setting a common ground throughout R&D in the company was, and remains, important to us.
By the way, I guess that this experience is relevant for more cases of integrating new tools. Even for an allegedly comfortable crowd such as R&D. Sometime I’ll tell you about our Wiki knowledge base.