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]

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 -

As mentioned by @Robert Wen 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]

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 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