Ask HN: Lessons learned from using JIRA/similar for an interdisciplinary team? | Hacker News Reader

Ask HN: Lessons learned from using JIRA/similar for an interdisciplinary team?

3 pointskatsukare-3 comments

My company is a startup transitioning to 100 people. Most are hardware engineers.

Project 1, I set it up and had under 10 engineers:

1. hosted bitbucket.

2. google docs.

3. kept requirements to a minimum in google sheets

I joined project 2 halfway through (setup by others). About 40 engineers:

1. Enterprise bitbucket, JIRA, Confluence and Bamboo

2. Gitlab CE for system level issues

3. IBM Rational DOORS for requirements. Traceability required.

4. Windows fileserver hosted by us because its "Not in the cloud". No more google docs.

Software guys are happy with JIRA, hardware guys happy with gitlab but there is not transparency in between. DOORS's gotta go. The fileserver, with word_final_v2.doc's causing issues. Often files are on personal volumes and shared by slack (in the cloud but nobody noticed).

I checked some options to replace DOORS and add some other tools for verification and change management. Along the way, JIRA emerged as the only option that was a single system. It seemed good to use the same tools as our software group and maybe Confluence can help our documentation. Reporting seems good.

Project 3/standard tools:

1. Enterprise bitbucket, JIRA, Confluence and Bamboo

2. Requirements/Test 4 JIRA. Maintained by only a few people (so I am confident it can be implemented well)

3. Begrudgingly keep using the windows fileserver for other files.

I wrote a script to migrate to JIRA. Red flag 1: there are many scripts to migrate from JIRA to gitlab, but none in the other direction. Red flag 2: any forum post about JIRA is full of complaints. The more I use it, the more the UI seems inconsistent. All of that said, JIRA still looks like the best option and the dashboards do what was a manual job in gitlab.

What I actually want to ask HN is, are there some lessons learned about trying use JIRA and Confluence (or similar tools) in interdisciplinary teams? Any tips to keep the 1-2 times per week users happy?

I wanted to add a comment specifically about documentation tools. We've always had a lot of collaboration. On an earlier project (let's call it project 0), at the same company, back when there was only a few people, we did all documentation in latex with CVS. It was glorious but as soon as a couple of non-technical people joined it was unmanageable and inevitably someone would have to troubleshoot others' environments, usually eventually giving up and manually merging on another's behalf.

Then we switched to google drive plus latex/CVS. It was not so glorious using both at the same time for the same files. We quickly switched to google docs only, which I came to love for realtime collaboration (a game changer for remote meetings) and its commenting system. It seems very hard to break linked content, like drawings or spreadsheet cells in a document. Keeping your architecture diagrams in a presentation file and linking them to all of your documents is also a game changer (they will automatically update).

Google drive also became much better when TeamDrive was added. I like that by design its permissions are not complicated and hierarchical. It's not possible to deny permissions to a subfolder in a TeamDrive. But old school IT people think this is a requirement.

Besides Confluence, I tried Amazon WorkDocs (useless), Office's new collaboration tools (broken) and Office 365 online (not bad but I predict people will just download and work offline meaning 2+ versions in 2+ places).

I'm going to keep using google docs while I can but have Confluence ready for whenever strict onsite requirements are enforced. Hopefully someday google docs has an enterprise or more security options. So far there are only options for HIPAA, and not other industry-specific options.

Jira is infinitely configurable. A lot of teams use that as an excuse to introduce heavyweight processes and lots of cognitive overhead. The result is that end users often find it some combination of confusing, frustrating, and exhausting.

Your challenge when configuring Jira and designing a process to use with it is to create the simplest workflow with the fewest restrictions and requirements and roadblocks that still works for everyone.

Treat it as a communication tool rather than an enforcement tool. For your infrequent users, make someone else responsible for the nitpicky bits of process (probably a project manager) such as setting ticket priorities and classification fields like “component”. The infrequent users should be responsible only for things like creating new tickets with adequate descriptions and for updating them when things change to indicate what changed.

Confluence is unnavigable in my opinion. The opposite of what a wiki should be. We ended up migrating our docs elsewhere.

Thanks for this, I’ll consider the roles of contributors including updating tickets, rather than trying to force it with required fields.

Reply on news.ycombinator.com