[t3e]

Thank you for this thoughtful comment, I’m happy somebody challenged us on this controversial point of our philosophy.

I disagree that a tool being process neutral implies anything about how the process ends up being designed, e.g. “process by committee within each customers organisation”, other than it won’t be decided by the tool. Process neutrality removes a set of constraints that in our experience add a lot of friction when teams want to work differently (and makes designing a great UX harder because of combinatorics).

There are indisputably tons of teams that seek and benefit from process guidance, including the ones I’ve run, but we think that should come from mentors, books, blogs, etc. – not the tool.

I agree that a lot of issues in Jira stem from wretched implementations, but I lay the blame for those implementations squarely at the feet of Jira. If most of the programs written in a language were impenetrable and borderline non-functional, would you blame the users, or the language?

Our biggest beef with prescriptivism in tools is that it impedes exploration and evolution of process changes that we feel are important to teams adapting well to growth and changing circumstances. It’s a much harder proposition to build a flexible tool, but we feel it’s necessary for this reason.