Testing | Black Box

[Brad Harris]

What's the best auto triggered work flows for a group of developers that are reluctant to use Jira as designed? 

---

Maybe someone has found a good way to encourage a group who's only using Jira half heartedly... 

---

What will trigger cooperation more in automated flows? 

[Jack Brickey]

Hi @Brad Harris ,

I am not sure that I am understanding your post. It seems that you have a team that is reluctant to embrace Jira and you are looking for a workflow that will address the reluctance? You also mention "automated", can you explain? I am unsure how a workflow can achieve this. Maybe if I understand what is truly driving the reluctance I could offer some guidance.

[Jack Brickey]

@Brad Harris , any response for those here trying to assist?

[Brad Harris]

You may be correct. 

I did set up some automated trigger for my Jira as admin,  but I need to work in a sprint cycle for about tow weeks to know if they help me maintain. 

Thanks 

[Ani Popova]

That's an interesting issue you are having.

I think your best chance is to approach the issue from 3 directions: 

1. Try to convince the team that using Jira will bring them benefits. Some of those may be: saving time, better organization, will help identifying and dealing with bottlenecks in the process, will help dealing with incomplete requirements, and so on, according to your specific situation

2. Create a simple and clear workflow that matches your real process. Do not allow all transitions, use roles, add validations to make it self-explanatory what's required for a transition, add automations wherever possible to save people brainpower, add notifications where needed to save people the trouble to go and check the board every time, notifications can also serve as reminders, etc. 

3. Enforce Jira being your source of truth: do not accept work if it is not in a Jira issue, do not accept code written if it is not in the proper state in Jira; do not accept work if it is not properly defined, etc. 

Don't ask the team to do too much all of a sudden. Let them get used to the basics first and then progressively introduce small changes for the better. For example, don't ask them from the very beginning to log their time, give them the chance to get familiar with Jira and then try to introduce time tracking later.

These are just examples, I don't know what your real situation is, but trying to introduce Jira to a resistant team is not only solved with Jira, you need to use psychology too. 

I hope that's helpful! Good luck!

[Brad Harris]

Great response.  

I'm definitely going to use this advice. 

[Amir Katz (Outseer)]

If you provide the team with a Kanban board where each person can see her tasks and the status of each task (each task is represented by a Jira issue), that will give them a single dashboard to see what they're doing (and need to do) and what other team members are doing.

[Brad Harris]

Right on...

[Anne Saunders]

We use a dashboard with widgets that run on queries using the "currentUser" smart value, so no matter who is logged in, they see THEIR blocked issues, THEIR assignments, THEIR watched issues, etc. - no need for individual boards or fighting with the Your Work page (which has gotten better but still doesn't do it for us.)

[MichaelS]

In case that you are using Bitbucket or a similar system, you could use smart commits in combination with Jira automation to trigger workflow transitions and other actions like

• set Jira status to „Selected for Development“ as the feature branch is created
• set Jira status to „in Progress“ on the first commit
• add certain commit messages as comments to Jira issues
• Close the Jira issue automatically when the pull request is merged.

With this setup the developer could stay in their environment without switching to Jira just to transition issues.

[Brad Harris]

This is awesome advice

-thanks 

TODO