Comment by dahwolf | Hacker News Reader

Comment by dahwolf | Hacker News Reader

Funny thing is that the example given of a "bad workflow" is in fact a fairly basic software development flow:

1. Ready to start (requirements and technical solution direction clear)

2. Working on it

3. Merge (to see if it also works live)

4. QA (typically dedicated role)

5. Regression testing (did we break anything?)

6. Release to Prod.

7. Sanity test on prod.

You could argue that you don't need both "Ready for QA" and "In QA" but for the QA team this distinction can be of value.

This doesn't even include a UX/UI sign-off, security audit, privacy review, and in my case several health-tech related audits.

For a typical developer, you're only asked to move your stories/tasks from 2-4, unless you get feedback from 5-7. That's not too much to ask, it's just basic sanity.

In my experience, that's not wasteful, it's a basic flow of work. What is wasteful instead is endless meetings that disrupt, of which only 10% of the content is relevant to you. What is wasteful is 5 million stakeholders asking about the status of things whilst that is the whole damn reason we have the system. What is wasteful is poorly written stories/tasks that require enormous detective work to understand. What is wasteful is constantly shifting priorities, moving work in and out of a sprint whilst it's already ongoing.

I think the biggest problem with tracking all of that process in a workflow engine like Jira is that a lot of it is redundant.

Merge status is tracked by your pull request/merge review tools.

The things available in QA testing should be known to your CD tools, your Release pipelines, and your QA environments.

QA sign off should at the level of "a release", not the level of a dev task/user story. (Cherry-picking, reverts, and other types of "unmerging" create unanticipated bugs.) It's also most home directly in your Release pipelines.

Same with Production sign off, sanity testing, and rollbacks to previous releases. Those are Release pipeline concerns and tracking it in Jira is at best redundant bureaucracy at that point. It shows either a lack of faith in the reporting tools of your Release pipelines or a management's devotion to Jira over the tools that actually get things done.

And of course managers and other stakeholders have their own Excel sheets, emails, etc. They don't use Jira, Jira is for developers.

Jira does integrate pretty deeply with source control (and not just Bitbucket) to handle release pipelines. I'm sure it's a pain to set up but it's magical when it works and tickets automatically have the right status as they get merged or deployed.

Sure, but you can also have those integrations update the Releases/Versions boards/reports (which is what they were built for) without making them part of (and complicating) the ticket workflows themselves. Even if you have that stuff automated between your primary systems and Jira, you also still don't need redundancy between Jira's workflows and its view of release status tracking.

You can use much simpler, dev-focused issue workflows and still get the benefit of some of manager's eye views that they want. It's very rare in Jira to actually do that because over-configuring redundancy in Jira is easier than the simple life.

(Also, for some personal gripes on this subject, the Jira integration with AzDO is painfully shallow and mostly broken and badly maintained. I realize that everyone should be using GitHub today, but until Microsoft actually admits that AzDO is dead in public, out loud, without hemming or hawing about it and "it still has a roadmap" [eyeroll] there's too much corporate momentum leaving people like me stuck in AzDO.)

Reply on news.ycombinator.com