Do all statues in a workflow with 'transition all' support the agile project management?

[#1]

I am an administrator of a Jira DC system that contains 200+ projects.

Many of these are Software projects.

I continually fall out with project teams as they want the ability to move tickets around as they please.

I use the example of getting ready for work in the morning:

Today I may do this

1. Shower

2. Get out of bed

3. Brush my teath

4. Leave the house

Tomorrow I may just:

1. Leave the house because I do not want to get out of bed...

Am I missing something?

[Nic Brough -Adaptavist-]

No, you're not missing anything.

You can configure Jira workflows to follow any process flow you want, whether that be a strictly controlled linear process, or a complete free-for-all.

In Software development, especially when being Agile, the free-for-all end of the scale is more appropriate, and you probably are on the wrong end of the argument.

Imagine a process where someone says "hey, can we make the software do this?" and a team looks at i, says yes or no (no including "yes, but it'll cost too much"), if it's a yes, they develop it, test it, and ship it.  You would probably have a workflow something like 

New -> being analysed -> to develop -> in progress -> in test -> done

Your Agile teams are asking you to not limit them to that linear process, because in real life, there are going to be times when it's going to be accurate to move backwards or skip steps.

Do you really need to analyse "please make the text black on yellow instead of blue on yellow because I am blue-yellow colourblind"?  No.  Do you really need to make people click through every step from new to in-test when they pick up the issue, open up the code, find and amend a line of css, visit the web page to check the colour changed?  It's 2 minutes work, probably less time than it's going to take to drag the card through every column on the board just to get it to done.  Things are going to fail testing and need to go back.  Things are going to get cancelled (done by virtue of not needing to do them any more).

You can pick any transition in that workflow and I can give you a good real-life reason the team should be allowed to do it.

In a slightly less Agile scenario, you could argue that people should not be able to skip the testing step  (except when cancelling or rejecting stories).  And Agile or not, I would not argue if you said "no one could move it back to 'new' because 'new' means we have not looked at it at all, and we don't want to say that about issues that we have looked at and then decided need more analysis later in the process"

If you're building a car, or getting up in the morning, your process probably is highly linear and only has a couple of skipped steps you should allow.  If you're doing software development in any slightly Agile way (as opposed to the failure that is waterfall), you should be letting the team process it in any way they want.

The default "can go from any status to any other" is simple, and very open, it relies on your team to have a process where it is valid to go to any status, or not use the transitions that they really shouldn't.   It's valid for most Agile ways of working.  It's less valid if you have a larger process for issues.  Imagine "new -> needs development -> <a huge subset of a development process> -> ready to deploy -> deployed" - your development process is Agile, but the other phases are not.  In that case, I would do all-to-all inside the development steps, but not in the others

TLDR: you need to look at your process that your workflow is trying to represent and decide how linear it should be, and if your teams are working that way.  

[Robert Wen_ReleaseTEAM_]

One of the keys to success of Agile development is having "self-managed, cross-functional teams".  That means that the team decides what they need to do and how to get there.

The team can decide what criteria meets their Definition of Ready so they can start work, and they also decide what criteria meets their Definition of Done so they know work is finished on a particular item.

Having Simplified workflows (that's what Jira calls it) keeps the spirit of self-management.  It allows the team to decide (according to their DoR and DoD) that an item is complete.

[Joseph Chung Yin]

@Graham Twine _Slm_ -

As mentioned by @Robert Wen_ReleaseTEAM_ and @Nic Brough -Adaptavist- , there are time where simplify software WF is what the users needed (where every status can go into every other status) to give them the flexibility.  

However, as the Jira system admin, you need to ensure the following setup are in place to avoid the user teams on creating their own statuses via SCRUM/KANBAN board configuration setup + ensure that resolution field population is properly handled.

1) In the initial status where when issue is created - removed the "ALL" default transition.  Create a new transition to the initial status (reuse it) from all other statuses in the WF.  This will change the WF not to be a "Simplified WF type" and thus user teams will no longer see the "Add Status" in the boards' configuration.

2) In all statuses (non terminal one like DONE/CLOSED etc..), you need to ensure that there are a post-function call to clear the resolution field value.

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

[Graham Twine _Slm_]

All valid points. I have been in software development for over 30 years. I think there is still a little waterfall in me. :)

I do see plenty abuse in some of the teams and this conversation has at the least made me open my mind to accepting that some flexibility is valid.

@Nic Brough -Adaptavist- , @Robert Wen_ReleaseTEAM_ and @Joseph Chung Yin 

Thank you for your input it is appreciated

I will get off my soap box and go sit in the corner now :D

My colleagues are going to love this. I will point hem to it

[Daniel Ebers]

Hi @Graham Twine _Slm_

after having seen some different Jira instances and at least that amount of teams with own philosophy I only can second to what Nic said...

You can configure Jira workflows to follow any process flow you want, whether that be a strictly controlled linear process, or a complete free-for-all.

... and finding it might work the one way or another - it just depends on the team and could by a maximum restricted if a role that has a strong voice (be it top management or something) orders to stick with just one workflow (or a smaller subset of pre-defined workflows).
Offering a workflow that works best for a team seems to be the key - however, like said, there could be the strong wish to keep an aligned ecosystem of only a few workflows.

Stepping a moment away from the design choices one must just make sure there is not configuration sprawl in Jira - if 5 teams get their own workflow (whatever that looks like, simply assuming it works for them) should not lead to 5 identical workflows.
Of course, sharing a workflow is good - it will be tricky if one stakeholder wants to have a change in the workflow.
This is something were the old governance topic kicks in - making things not easier, to be honest.

So - in case a company is not striving for only a few streamline workflows across the instance (which can make understanding how things are designed a lot easier) every team should get the workflow they need. An eye must be kept on the overall configuration, though.

It proved to be useful to let only small deviances be handled through Automation, instead of creating an additional workflow - however, this might depend overall on the scale (the users of an instance with 2000 project might need to consider that more carefully than a small development team having just a few Jira projects around).

This is just what we observed during the last years - maybe other enterprises made other experiences.

Regards,
Daniel