Become the Michael Jordan of Process Automation
During client engagements I have noticed that companies adapting their current processes to JIRA have been making a mess of things! Basically like learning to dribble a ball.
Most company processes involve disparate groups performing different roles, in different places and basically trying to work harmoniously with ancient tools.
This involves: Many, many, many Excel spreadsheets and SharePoint lists, foolscap paper, Post-It notes, napkins etc. Basically, there is no process to speak of.
Now, the interesting part is when companies utilizing the above process get themselves an instance of JIRA and start adapting their existing processes (or lack of) to JIRA workflows.
The first approach many take is to make a massive workflow verbatim to their biggest and ugliest spreadsheet and have huge screens with thousands of fields. I have seen workflows that include hundreds of steps where the same user is performing multiple concurrent transitions. This is a great way to ensure that a workflow will not be utilized or understood by end users. It is also a great way to ensure that you, as the JIRA developer, are ostracized and scorned to an unfathomable degree.
SO?!! How can we fix this you ask?...
Well first we must ensure that no user ever transitions a workflow through multiple concurrent stages. But, you probably already knew that....
Next, and this is the important part; We control user access to the process through USEFUL dashboards only showing the process information that is relevant to them. And, in many cases only showing them items that they are meant to work on. Almost an inbox of things to be actioned (instructional coming soon!).
Wait!!! You say?!! All that will do is add a workflow transition button in the JIRA issues.
Most company processes involve disparate groups performing different roles, in different places and basically trying to work harmoniously with ancient tools.
This involves: Many, many, many Excel spreadsheets and SharePoint lists, foolscap paper, Post-It notes, napkins etc. Basically, there is no process to speak of.
Now, the interesting part is when companies utilizing the above process get themselves an instance of JIRA and start adapting their existing processes (or lack of) to JIRA workflows.
The first approach many take is to make a massive workflow verbatim to their biggest and ugliest spreadsheet and have huge screens with thousands of fields. I have seen workflows that include hundreds of steps where the same user is performing multiple concurrent transitions. This is a great way to ensure that a workflow will not be utilized or understood by end users. It is also a great way to ensure that you, as the JIRA developer, are ostracized and scorned to an unfathomable degree.
SO?!! How can we fix this you ask?...
Well first we must ensure that no user ever transitions a workflow through multiple concurrent stages. But, you probably already knew that....
Next, and this is the important part; We control user access to the process through USEFUL dashboards only showing the process information that is relevant to them. And, in many cases only showing them items that they are meant to work on. Almost an inbox of things to be actioned (instructional coming soon!).
This is important because we are going to also create individual views for each of the user roles as well. Those individual views will be configured by creating conditions where the views can only be seen by the users we made them for. Targeted Views!
This can be achieved in a couple of different ways. You can do this with the Blitz Actions JIRA plugin which is a very elegant solution and has a ton of other functionality (Post coming soon!), or we can do it Ghetto Style (Free!). The funny part is how simple this solution is!
Let's say we have a role in our process for a Fund Manager. Let's do the following for that role:
- Create a dashboard showing them the information they are interested in (i.e.. dates, cost's etc. that are relevant to them) and ideally issues that they are expected to update.
- Create a screen with only the items that the Fund Manager is expected to update during this phase of the stage. This will generally only be a few fields and will take no time to edit.
- Create a workflow transition from the stage you want the Fund Manager to update, and loop it back on itself. Name it appropriately - Something like "Edit Capital".
- Add the Fund Manager Edit screen to the above transition and we are done!
That's true, however our user will now have the ability to work effectively from their dashboard. They can obviously open the issue and see everything in it but in most cases all they want to do is work with a few fields. To do so, our fund manager simply clicks on the ellipsis to the right of the issues and chooses his 'Edit Capital' selection, and BAM!! Our perfectly targeted screen appears and the Fund Manager enters a few items and TADA! THAT'S IT!
If we repeat this methodology for every role in the process we can harvest hundred/thousands/millions of fields of data without overloading our end users. Not to mention, all of that data is now in one central location!!!
Once this has been achieved you will be solving problems before they happen!
Comments
Post a Comment