Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: