4 ms·

I am lucky to work with a reasonable company that prioritizes people over methodology. We follow Scrumban - something between Scrum and Kanban. We have sprints,

I am lucky to work with a reasonable company that prioritizes people over methodology. We follow Scrumban - something between Scrum and Kanban. We have sprints, tickets, story points, daily standups, but it is humane. Before sprint starts, tickets are estimated and assigned to developers. Each developer gets more-less the same amount of story points. Since the codebase is very big, if possible, a developer would get tickets related to his past tickets. A developer would own a certain feature of the system. We can trade tickets with each other. Usually, tickets are overestimated a little, but we are encouraged to adjust the story points of our tickets to match reality. In case of an urgent issue, anyone can add tickets to the ongoing sprint, but it is done sparingly. It's okay if it takes two times longer to finish a ticket sometimes. It is also okay to say on standup that you didn't make any progress on your tickets assuming you've been busy doing something else related to the project. If the ticket is big and the end of the sprint is close, the pull request would be merged at the beginning of the next sprint. Finally, the release can be delayed for a couple of days if necessary. Every third sprint is a tech sprint. The goal is to improve the system. Anyone can write a ticket and work on what he wants pretty much. In conclusion, it's about trust and being professional. The methodology is just a baseline that sets the tone. It should be followed for as long as it makes sense. There should be a clear goal. In our case, it is to have a stable system and a healthy workplace.

mattwad 6y ago
> Every third sprint is a tech sprint. Can you elaborate on this? I love the sound. I get pushback even suggesting a tech sprint once every 6 weeks. What kinds of projects fall under here, and do you still work on product? What's the product team work during this sprint? Thanks!
- zerof1l 6y ago
  It is very similar to a normal sprint, but instead of adding new features, our goal is to improve existing features, the system, or the process. It can be technical things like upgrading to a new version of PHP, of a framework, or a library. It can be anything related to technical debt. It can be some proof-of-concept. In one of such sprints, I've introduced cypress and made a couple of tests to demo it. The tickets for this sprint come from anyone. Usually, when working on a ticket you sometimes get a brilliant idea. Write a new ticket with that idea and add it to the tech sprint proposal. Before the tech sprint, the whole team participates in sprint planning. We go over tickets, review them, and decide whether they should be done. Usually, we assign tickets to ourselves. We also estimate how many story points they will be. Ideally, it should take less than 1 week to finish. A maximum of the whole sprint of 2 weeks is allowed. Otherwise, it is divided or multiple people work on it.
- 908B64B197 6y ago
  > I get pushback even suggesting a tech sprint once every 6 weeks. Either get a dedicated team for this or a better manager.
- herval 6y ago
  IMO the problem with this approach is it draws a line between “tech debt” and “progress”. So in the end, the team will overcompensate to do less and less “tech debt sprints” or start expanding it into an occasional “tech debt half”, and so on. What I think works better is having a tech debt related goal _as part of product work_: instead of estimating you’ll work on feature X, also add time and be explicit about tackling issues around X. This also prevents wasting time on debt that’s not really relevant (is a piece of code that never fails and never change really worth rewriting?). This makes it easier to tackle it over time, easier to sell to product & management. “Tech debt” itself is a bad term IMO - it isn’t an aspect of software that’s easily identified (unlike, say, compilation warnings), and you can’t count it as money-debt, so I always found the concept of “paying it down” sorta counterproductive. But that’s a different topic altogether.
itsmemattchung 6y ago
> The goal is to improve the system. This. I do believe that the act of breaking down tasks helps clarify assumptions and helps paint a more accurate picture of what needs to be accomplished for a particular task. Can breaking down the task into small bite-size chunks be a little demoralizing? Maybe. But I don't necessarily view it that way, assuming that the person owning the task is part of the initial conversation. In short, the breaking up of tasks should be a conversation, not some top down mandate.

mattwad 6y ago

> Every third sprint is a tech sprint. Can you elaborate on this? I love the sound. I get pushback even suggesting a tech sprint once every 6 weeks. What kinds of projects fall under here, and do you still work on product? What's the product team work during this sprint? Thanks!

zerof1l 6y ago
It is very similar to a normal sprint, but instead of adding new features, our goal is to improve existing features, the system, or the process. It can be technical things like upgrading to a new version of PHP, of a framework, or a library. It can be anything related to technical debt. It can be some proof-of-concept. In one of such sprints, I've introduced cypress and made a couple of tests to demo it. The tickets for this sprint come from anyone. Usually, when working on a ticket you sometimes get a brilliant idea. Write a new ticket with that idea and add it to the tech sprint proposal. Before the tech sprint, the whole team participates in sprint planning. We go over tickets, review them, and decide whether they should be done. Usually, we assign tickets to ourselves. We also estimate how many story points they will be. Ideally, it should take less than 1 week to finish. A maximum of the whole sprint of 2 weeks is allowed. Otherwise, it is divided or multiple people work on it.
908B64B197 6y ago
> I get pushback even suggesting a tech sprint once every 6 weeks. Either get a dedicated team for this or a better manager.
herval 6y ago
IMO the problem with this approach is it draws a line between “tech debt” and “progress”. So in the end, the team will overcompensate to do less and less “tech debt sprints” or start expanding it into an occasional “tech debt half”, and so on. What I think works better is having a tech debt related goal _as part of product work_: instead of estimating you’ll work on feature X, also add time and be explicit about tackling issues around X. This also prevents wasting time on debt that’s not really relevant (is a piece of code that never fails and never change really worth rewriting?). This makes it easier to tackle it over time, easier to sell to product & management. “Tech debt” itself is a bad term IMO - it isn’t an aspect of software that’s easily identified (unlike, say, compilation warnings), and you can’t count it as money-debt, so I always found the concept of “paying it down” sorta counterproductive. But that’s a different topic altogether.

itsmemattchung 6y ago

> The goal is to improve the system. This. I do believe that the act of breaking down tasks helps clarify assumptions and helps paint a more accurate picture of what needs to be accomplished for a particular task. Can breaking down the task into small bite-size chunks be a little demoralizing? Maybe. But I don't necessarily view it that way, assuming that the person owning the task is part of the initial conversation. In short, the breaking up of tasks should be a conversation, not some top down mandate.