Can you please describe how you had a Jira/ticket system that you felt gave you autonomy? Very curious how it could be implemented in a research setting.
Dunno about research, but I've worked in a few SV startups that organized development with Jira and had high autonomy for engineers. Some of the features of those teams:
1. Most tickets are opened by engineers themselves, and don't contain detailed specifications, but just notes to provide context.
2. The purpose of the ticket is to provide something to link to, and a place to put information as it emerges. So commits and PRs usually link to a ticket, as do engineering and product management planning documents, reports etc. Some tickets are terse and quickly closed, others could develop a long history, with status changes, links to other tickets and documents, ownership by different engineers over time etc.
3. We organize development into sprints, but a Scrum master would be disgusted by our process. Sprints are just short-terms planning horizons; we ship as soon as the code is ready and close tickets when the code is in production. The purpose of a sprint is to batch up all the low-level planning and prioritization so most of the time we're focused on execution.
4. High-level planning is all in GDocs, spreadsheets and Photoshop/Figma. Product management doesn't create tickets unless they are reporting a bug, and even that was pretty rare. Engineering management gets a lot of information about what's going on by observing Jira; this reduces the need for meetings to communicate status. (Doesn't eliminate meetings, of course, but it does seem to make them more interesting.)
Basically, it boils down to, you have to keep status somewhere, and Jira does that pretty well.
not the GP, but I've had multiple times in my career when I and the team I was on were given pretty high-level problems to solve and left alone to solve them. The request to use JIRA was basically our managers and the product people wanting some vague reassurance that progress was being made, but nobody was concerned with the details of the tickets, etc. This included early-phase 'R&D' work on a medical device. Of course in that setting once the device was on a release cadence, if we were contributing to the 1.x line of the release we had a lot more overhead :). However even then you could always file yourself a more R&D flavor ticket, as long as it was going to the long-term branch and not to the release branch...
What it came down to, per the article, was that everyone in the co. respected that the engineering team was capable of delivering results and solving problems.
But i think per your question about JIRA, it gives you autonomy if:
- anyone on the team can add a ticket
- the team is trusted to make small changes in scope or spec to tickets in response to things they encounter as they work
- there is little to no ceremony around accepting tickets as done
- the team is trusted to check their own work first, and then collaborate with QA / stakeholders / etc. on releases
Thx for your thoughts. You mentioned R&D flavor tickets. Really curious about the mechanics of this. Does the responsible engineer update once a sprint, weekly? I've seen junior staff spend months on dead ends .. curious how to manage that via process.
Also, if the R&D project is a team project involving multiple people, what is a reasonable update/sprint cadence?
I had a similar experience years ago. It was not Jira but bugzilla, but you can use it in the same way (I told you it was years ago ;)).
Any engineer could open any ticket for another engineer or team. You could also set the priority to how urgent it was. The receiving engineer could adjust the priority according to their own work of course.
Basically all work that you do was in the tracker. You could even add things for yourself, so you had a central place for your or anyones todo list.
Best work environment I ever worked as a software developer. There was never something blocking that some manager had to resolve, because you would just open a ticket an assign it to the person or team you think is relevant. All discussion was done in the ticket.
the business goals were translated into "epic" tickets, after that it was entirely up to the engineers.
An example of this would be something like:
We need an API that allows secure access to service x. It must have authentication, respond with an answer inside x milliseconds, It must work with a developer admin interface (see ticket z)
Ticket z would be assigned to the web team, and we would work closely on an interface between the API backend and the dev interface.
After that, my team would layout and make a high level design. We'd break that design down into individual "sub epics" and let each dev create and work on tickets as they see fit.
1. Most tickets are opened by engineers themselves, and don't contain detailed specifications, but just notes to provide context.
2. The purpose of the ticket is to provide something to link to, and a place to put information as it emerges. So commits and PRs usually link to a ticket, as do engineering and product management planning documents, reports etc. Some tickets are terse and quickly closed, others could develop a long history, with status changes, links to other tickets and documents, ownership by different engineers over time etc.
3. We organize development into sprints, but a Scrum master would be disgusted by our process. Sprints are just short-terms planning horizons; we ship as soon as the code is ready and close tickets when the code is in production. The purpose of a sprint is to batch up all the low-level planning and prioritization so most of the time we're focused on execution.
4. High-level planning is all in GDocs, spreadsheets and Photoshop/Figma. Product management doesn't create tickets unless they are reporting a bug, and even that was pretty rare. Engineering management gets a lot of information about what's going on by observing Jira; this reduces the need for meetings to communicate status. (Doesn't eliminate meetings, of course, but it does seem to make them more interesting.)
Basically, it boils down to, you have to keep status somewhere, and Jira does that pretty well.