Using custom issue types and multiple nested workflows to bring business management processes into a project without disrupting the core workflow.
Last month I had the pleasure of teaching a private JIRA Boot Camp at a national corporation on the East Coast. They had been using JIRA for a while, and had achieved a level of success in within their development team. They knew JIRA had the ability to play a larger role, but they were struggling to really integrate it into the business. They asked if I could come out and go through my normal curriculum but with an eye on their particular situation.
Working with the Director of IT, we decided to really push hard to complete the curriculum in two days and spend the third heavily focused on their internal challenges and their production environment. By the end of the day it was really clear this had been a wise choice. They were picking up the main curriculum very well, and they could see how to move development based items through the workflow. They were struggling with how to manage the business-related processes that precipitated and followed the software development process. Like most people, they understood JIRA could be so much more than an issue tracker, they just needed a little guidance to make it happen.
As we went through the workflow exercises in the curriculum, the problem crystallized. In their organization, initiatives would be proposed by various leaders of groups throughout the company. Those initiatives would go through an assessment, research, and approval process before any development occurred. They needed to track these initiatives so they knew what was coming, but kept mixing them into the development workflow. After we covered custom issue types, I approached the solution with them. They needed to nest a development workflow inside a workflow to track initiatives. This could be done with custom issue types and advanced workflow configuration.
First we white boarded the initiative workflow both before and after development occurred. The results are shown below.
The process for the initiatives was fairly complex both before and after development. The entire development process was represented by a “development” status for the initiative. Important truth, the business process “around” development work is often far more complex than the development process itself.
After this we nailed down a straightforward workflow for the development process, represented in the next image. The essential process became crystal clear to them once we removed the distraction of the messy process surrounding it. I needed to coach them very little once the distractions were removed.
The answer to the overall problem was to allow the original initiative to be created, researched and run through an approval process. This initiative then needed to be tied to the development work while it was being completed. Once this phase was completed, there was a well-defined business process that needed to be completed for the whole initiative.
The next challenge was how to implement this in JIRA. The first step was to define the two separate workflows and lay out the statuses and transitions of each. Even though there were some possibilities of sharing statuses between the workflows, we were very careful not to do so. I have learned to isolate workflows that have different purposes. I have written about this previously, here. Mixing the purpose of a workflow includes using a status from a different workflow that may share a name. If the meaning is different in any way then a status should not be shared.
We then created the custom issue types that would be used by each workflow. There were multiple custom issue types needed for each workflow. We created multiple custom issue types for each workflow, then negotiated the transition between the issue types and workflows in a way that fit the organization.
An initiative would ride through its process until it was approved. It was then transitioned to the development status. The initiative was then assigned a label and the development items were created and tagged with that label. The initiative was not allowed to transition out of development until all the items with that label were resolved. The development items then make their way through the process to completion, thus allowing the initiative to move forward to the review, field testing, and deployment stages in the first workflow.
Another bonus of this approach was reporting. An agile board could be created for each initiative, allowing the stakeholder to monitor progress of his project. Another agile board could be created to track all the initiatives, another for initiatives by department, another for development tasks by developer.
The net result was that a very complex, opaque process made manageable and transparent by utilizing custom issue types, separate workflows and advanced workflow configuration to nest the two workflows together. Yet another example of how powerful JIRA is, and how strategic use of its flexibility can improve organizational efficiency.
