An epic treatise on scheduling, bug tracking, and triage
1–10 of 67 posts
Re: An epic treatise on scheduling, bug tracking, and triage
#2TL;DR: Agile is silly but has some lessons to teach. Most people do it wrong though. Make decisions early and stick to them. Talk about effort not time. Make stories about users. Treat bugs differently to stories (they are on average all the same size, are written from a different perspective, etc.). Abandon stand-ups, steal things from SCRUM and Kanban, and don't talk about deadlines, ever.
Re: An epic treatise on scheduling, bug tracking, and triage
#3TL;DR: Agile is silly but has some lessons to teach. Most people do it wrong though. Make decisions early and stick to them. Talk about effort not time. Make stories about users. Treat bugs differently to stories (they are on average all the same size, are written from a different perspective, etc.). Abandon stand-ups, steal things from SCRUM and Kanban, and don't talk about deadlines, ever.
I don't think a tl;dr like this is appropriate for this one, because it leaves out the best bits. I mean, this is a very long writeup, and you're condensing it to 7 sentences. For example, the interesting part is not that deadlines don't work, but why they don't work. And I feel like the "why" is missing from a lot of advice on methodology: Everybody talks about how, but why are we supposed to do these things in the first place? And maybe we can learn something while trying to find answers to these questions.
I've only read half of it, but I liked it a lot. What about you? Did you like it? Why?
Re: An epic treatise on scheduling, bug tracking, and triage
#4TL;DR: Agile is silly but has some lessons to teach. Most people do it wrong though. Make decisions early and stick to them. Talk about effort not time. Make stories about users. Treat bugs differently to stories (they are on average all the same size, are written from a different perspective, etc.). Abandon stand-ups, steal things from SCRUM and Kanban, and don't talk about deadlines, ever.
I don't think a tl;dr like this is appropriate for this one, because it leaves out the best bits. I mean, this is a very long writeup, and you're condensing it to 7 sentences. For example, the interesting part is not that deadlines don't work, but why they don't work. And I feel like the "why" is missing from a lot of advice on methodology: Everybody talks about how, but why are we supposed to do these things in the…
I think a tl;dr is suppose to leave bits out…
Re: An epic treatise on scheduling, bug tracking, and triage
#5Earlier quoted context omitted.
I don't think a tl;dr like this is appropriate for this one, because it leaves out the best bits. I mean, this is a very long writeup, and you're condensing it to 7 sentences. For example, the interesting part is not that deadlines don't work, but why they don't work. And I feel like the "why" is missing from a lot of advice on methodology: Everybody talks about how, but why are we supposed to do these things in the…
I think a tl;dr is suppose to leave bits out…
Yes, but it is also supposed to communicate the point. Which is not always possible in a tl;dr because if it was the author probably would have just written a single paragraph in the first place and saved a whole lot of time for everyone.
Re: An epic treatise on scheduling, bug tracking, and triage
#6I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer any questions people have here.
Re: An epic treatise on scheduling, bug tracking, and triage
#7Earlier quoted context omitted.
I think a tl;dr is suppose to leave bits out…
Yes, but it is also supposed to communicate the point. Which is not always possible in a tl;dr because if it was the author probably would have just written a single paragraph in the first place and saved a whole lot of time for everyone.
I have not read the article (yet; it's bookmarked for later), so I'm speaking generally, here.
> it was [possible] the author probably would have just written a single paragraph in the first place and saved a whole lot of time for everyone.
This does not fit with my experience, even disregarding things like YouTube videos which drag on in order to justify longer ads.
Writing concisely is hard, and often much more time consuming than a lengthy brain dump. It's also tempting to elaborate on every point, however tangential. I have to constantly fight this in my own writing; my desire is to be complete, but really I'm drifting off-topic, diluting my point with irrelevance, making it harder to follow.
Based on the comments above, it seems like the tl;dr missed important nuance, but that isn't always so.
Re: An epic treatise on scheduling, bug tracking, and triage
#8TL;DR: Agile is silly but has some lessons to teach. Most people do it wrong though. Make decisions early and stick to them. Talk about effort not time. Make stories about users. Treat bugs differently to stories (they are on average all the same size, are written from a different perspective, etc.). Abandon stand-ups, steal things from SCRUM and Kanban, and don't talk about deadlines, ever.
So .. what is the business substitute for deadlines? Unless you're genuinely a startup with unlimited funding and total freedom, eventually people are going to ask the question "so what are you going to deliver and when?"
Re: An epic treatise on scheduling, bug tracking, and triage
#9TL;DR: Agile is silly but has some lessons to teach. Most people do it wrong though. Make decisions early and stick to them. Talk about effort not time. Make stories about users. Treat bugs differently to stories (they are on average all the same size, are written from a different perspective, etc.). Abandon stand-ups, steal things from SCRUM and Kanban, and don't talk about deadlines, ever.
So .. what is the business substitute for deadlines? Unless you're genuinely a startup with unlimited funding and total freedom, eventually people are going to ask the question "so what are you going to deliver and when?"
That's basically what the entire article is about. The (very) short version is it really is possible to predict when things will be done, but if you tell the engineers or negotiate with the engineers (ie. turn it into a deadline), that counterintuitively tends to make the predictions worse instead of better.
Re: An epic treatise on scheduling, bug tracking, and triage
#10I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer any questions people have here.
Super interesting points here. You mentioned that the real-world Kanban board forces you to empty slots to make room... I've never seen that in any of the software Kanban-style systems have you?
I've played around (in spreadsheets and basic apps) with trying to create systems that scaled available slots to team size as a way to force correct granularity.