4 ms·

TL;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 st

TL;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.

ndh2 9y ago
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?
- falsedan 9y ago
  I think a tl;dr is suppose to leave bits out…
  - saltedmd5 9y ago
    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.
    - smichel17 9y ago
      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.
    - falsedan 9y ago
      I don't understand. A summary should summarise. An explanation should explain, an argument should convince, a historical overview should retell events. Obviously, a summary can't be an explanation + an argument + history. It has to be the most salient points presented alone. Think about an abstract for a paper: it should tell you enough that you can understand if you should read the paper now, and enough context so that you can remember to read it later if your situation changes. If you feel like the tl;dr doesn't pay full respects to the article, that's fine but I feel like not many readers will mind.
      - apenwarr 9y ago
        I quite liked the tl;dr, except that it left out how most of the article is "...and why". We've all heard the advice, but the article is trying to explain why the advice is true. I think an ideal summary would mention that.
        falsedan 9y ago
        OK, I understand. Though I think the article did a terrible job of explaining why: like, why do deadlines cause engineers to become affected by Student Syndrome? It just mentions it at a superficial level, which is perfectly fine for its purposes. edit: also thanks for writing that article, it's great.
      - nine_k 9y ago
        A summary is always a compromise, a judgment on which 95% of the text to leave off. Because of this, an ideal summary is hardly possible, and someone may always complain that a salient point was left out. This is not because the summary is "objectively bad", it's because the compression is lossy, and what's seen as salient differs between observers.
pjc50 9y ago
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?"
- apenwarr 9y ago
  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.
- agentultra 9y ago
  That is often the first question I get asked when trying to explain these concepts to business owners. My answer is that you can plan for work to be done on a deadline but you can't negotiate when it will be done with the people doing the work. It's going to take as long as it takes. It's poor management that sets unrealistic expectations and demands results. You can plan for work by using data. You get data by tracking effort estimated versus completed and triaging bugs. You prioritize goals instead of setting deadlines. You measure and refine. It sounds counter-intuitive to business people who think in terms of, I just sold customer X the product and they need it delivered by Y so that we can get the team paid by Z. This is where poor management decisions can sink your team. If Y is decided by the sales or management team with the customer and they didn't consult their engineering team... then they're working on another planet. The goal of processes like this are not to eliminate Y but to set reasonable expectations and objectives. As I like to remind my business owners: you can have something that works -- it may not be the whole kit -- or you can have nothing at all. Winning is about prioritizing objectives. One book I've read recently that taught me a lot about management is Extreme Ownership[0]. I think there's a lot of cross-over from this book into Agile methodologies that I think non-technical stakeholders can really understand. [0] https://www.goodreads.com/book/show/23848190-extreme-ownership https://www.goodreads.com/book/show/23848190-extreme-ownersh...
  - jasode 9y ago
peterwwillis 9y ago
Most people get way too wrapped up in jargon and staying inside the Agile box. The method is just an idea, a loose framework, a suggestion. Executives and management will always try to rigidly implement the method (because Peter Principle) and this should be circumvented whenever possible.
nine_k 9y ago
> Talk about effort not time I can't understand this. You can measure time, but you can't measure effort directly, unless you're maybe doing some physical work like pulling weights. Also, you can't usually increase a mental effort, except by spending more time (e.g. by working overtime). I can only see points or other non-time measures as proxies to time intervals (with uncertainty), but we can't know the function points -> time beforehand, we can only measure and map it from experience. If you could explain "effort" from some other angle, I'd be grateful.
- apenwarr 9y ago
  Yeah, this is why I don't prefer the common "effort vs time" distinction. Instead I like to think of "relative size of task," which is a very easy concept for most people to intuitively understand. It's fairly easy to guess that a task that is twice as "big" will take twice the "effort" and thus also twice the "time," all else being equal. And it turns out that's all we need in order to estimate the schedule. See the detailed commentary here: http://apenwarr.ca/log/?m=201712#slide19 http://apenwarr.ca/log/?m=201712#slide19

ndh2 9y ago

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?

falsedan 9y ago
I think a tl;dr is suppose to leave bits out…
- saltedmd5 9y ago
  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.
  - smichel17 9y ago
    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.
  - falsedan 9y ago
    I don't understand. A summary should summarise. An explanation should explain, an argument should convince, a historical overview should retell events. Obviously, a summary can't be an explanation + an argument + history. It has to be the most salient points presented alone. Think about an abstract for a paper: it should tell you enough that you can understand if you should read the paper now, and enough context so that you can remember to read it later if your situation changes. If you feel like the tl;dr doesn't pay full respects to the article, that's fine but I feel like not many readers will mind.
    - apenwarr 9y ago
      I quite liked the tl;dr, except that it left out how most of the article is "...and why". We've all heard the advice, but the article is trying to explain why the advice is true. I think an ideal summary would mention that.
      - falsedan 9y ago
        OK, I understand. Though I think the article did a terrible job of explaining why: like, why do deadlines cause engineers to become affected by Student Syndrome? It just mentions it at a superficial level, which is perfectly fine for its purposes. edit: also thanks for writing that article, it's great.
    - nine_k 9y ago
      A summary is always a compromise, a judgment on which 95% of the text to leave off. Because of this, an ideal summary is hardly possible, and someone may always complain that a salient point was left out. This is not because the summary is "objectively bad", it's because the compression is lossy, and what's seen as salient differs between observers.

pjc50 9y ago

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?"

apenwarr 9y ago
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.
agentultra 9y ago
That is often the first question I get asked when trying to explain these concepts to business owners. My answer is that you can plan for work to be done on a deadline but you can't negotiate when it will be done with the people doing the work. It's going to take as long as it takes. It's poor management that sets unrealistic expectations and demands results. You can plan for work by using data. You get data by tracking effort estimated versus completed and triaging bugs. You prioritize goals instead of setting deadlines. You measure and refine. It sounds counter-intuitive to business people who think in terms of, I just sold customer X the product and they need it delivered by Y so that we can get the team paid by Z. This is where poor management decisions can sink your team. If Y is decided by the sales or management team with the customer and they didn't consult their engineering team... then they're working on another planet. The goal of processes like this are not to eliminate Y but to set reasonable expectations and objectives. As I like to remind my business owners: you can have something that works -- it may not be the whole kit -- or you can have nothing at all. Winning is about prioritizing objectives. One book I've read recently that taught me a lot about management is Extreme Ownership[0]. I think there's a lot of cross-over from this book into Agile methodologies that I think non-technical stakeholders can really understand. [0] https://www.goodreads.com/book/show/23848190-extreme-ownership https://www.goodreads.com/book/show/23848190-extreme-ownersh...
- jasode 9y ago

peterwwillis 9y ago

Most people get way too wrapped up in jargon and staying inside the Agile box. The method is just an idea, a loose framework, a suggestion. Executives and management will always try to rigidly implement the method (because Peter Principle) and this should be circumvented whenever possible.

nine_k 9y ago

> Talk about effort not time I can't understand this. You can measure time, but you can't measure effort directly, unless you're maybe doing some physical work like pulling weights. Also, you can't usually increase a mental effort, except by spending more time (e.g. by working overtime). I can only see points or other non-time measures as proxies to time intervals (with uncertainty), but we can't know the function points -> time beforehand, we can only measure and map it from experience. If you could explain "effort" from some other angle, I'd be grateful.

apenwarr 9y ago
Yeah, this is why I don't prefer the common "effort vs time" distinction. Instead I like to think of "relative size of task," which is a very easy concept for most people to intuitively understand. It's fairly easy to guess that a task that is twice as "big" will take twice the "effort" and thus also twice the "time," all else being equal. And it turns out that's all we need in order to estimate the schedule. See the detailed commentary here: http://apenwarr.ca/log/?m=201712#slide19 http://apenwarr.ca/log/?m=201712#slide19