3 ms·

"Thou shalt not be negative" (HN) - well I'm sorry. Just some example text: > both Agile and Waterfall are focused on building. Design is about validating. or

"Thou shalt not be negative" (HN) - well I'm sorry. Just some example text: > both Agile and Waterfall are focused on building. Design is about validating. or > So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value. Satire? Enough words to fill a hot air balloon or two. "Smart" focus, "clear" outcomes, "outcomes" vs. "milestones"(?), "trusted" product teams (as opposed to... what?), "empowered" etc.? Far more interesting than the contents of many links that make it to the HN homepage is discovering the fact that they do so.

tootie 7y ago
Honestly that statement is the nail on the head for me. There's a huge distinction between an output and an outcome and a huge distinction between a project plan and a road map.
- nosianu 7y ago
  > between an output and an outcome and a huge distinction between a project plan and a road map. I mention neither of those. I'm not complaining about your reply, I think it shows how those texts are (to be?) used: Just like art. You project your own experiences into it, it's more about getting you to think. So naturally different people are going to react differently and read different things into the same text. That's perfectly alright - you get something out of it (only) if you put something in. If there is nothing to begin with, which may just be lack of experience (new programmer), you'll get less out of it. If you have two decades large project experience in various companies and teams you'll get a lot out of it. Let's attempt to make the best out of it then, out of any text, if we are presented with that opportunity and the headline got us to click on it :-)
  - itsdrewmiller 7y ago
    I think you misread the part you quoted, while GP read it correctly - it's comparing outputs and outcomes, not outcomes and milestones.
    - nosianu 7y ago
      No I did not. Let me quote again what I already quoted: > with roadmapped outcomes replacing planned milestones "outcomes" vs "milestones" See?
      - jeremyjh 7y ago
        > It’s a smart focus on clear outcomes, not output
- deleted 7y ago
  [deleted]
cljs-js-eval 7y ago
In the spirit of that second paragraph - focusing on outcomes, not specific implementations - here's a rewrite: Original: > So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value. Rewritten: > So… what’s the way out? It’s a focus on clear outcomes, not output. There should be dates for when specific outcomes should happen. Teams should be empowered to find the minimal amount of work needed to achieve the outcomes. It's a really wordy way to say what any good leadership class would tell you. Focus on what you want more than how you get it, and let your subordinates decide how to get it. Both good product teams and project teams are capable of working that way. This kinda sums up my problem with endless agile vs. waterfall vs. whatever discussions. The interesting parts aren't really new ideas and the extra buzzwords add nothing.
- Terretta 7y ago
  Interesting, I’d interpret “roadmapped outcomes replacing planned milestones” to mean there should not be predetermined dates and deliverables (planned milestones), but rather, a sequence of value-delivering outcomes (roadmapped outcomes).
  - cljs-js-eval 7y ago
    A relative order of outcomes could also work, yeah. You'll have a date in there somewhere, though, even if it's not driven off the amount of work. Could be "and if we can't achieve this outcome by X date we give up on this whole outcome".

tootie 7y ago

Honestly that statement is the nail on the head for me. There's a huge distinction between an output and an outcome and a huge distinction between a project plan and a road map.

nosianu 7y ago
> between an output and an outcome and a huge distinction between a project plan and a road map. I mention neither of those. I'm not complaining about your reply, I think it shows how those texts are (to be?) used: Just like art. You project your own experiences into it, it's more about getting you to think. So naturally different people are going to react differently and read different things into the same text. That's perfectly alright - you get something out of it (only) if you put something in. If there is nothing to begin with, which may just be lack of experience (new programmer), you'll get less out of it. If you have two decades large project experience in various companies and teams you'll get a lot out of it. Let's attempt to make the best out of it then, out of any text, if we are presented with that opportunity and the headline got us to click on it :-)
- itsdrewmiller 7y ago
  I think you misread the part you quoted, while GP read it correctly - it's comparing outputs and outcomes, not outcomes and milestones.
  - nosianu 7y ago
    No I did not. Let me quote again what I already quoted: > with roadmapped outcomes replacing planned milestones "outcomes" vs "milestones" See?
    - jeremyjh 7y ago
      > It’s a smart focus on clear outcomes, not output
deleted 7y ago
[deleted]

cljs-js-eval 7y ago

In the spirit of that second paragraph - focusing on outcomes, not specific implementations - here's a rewrite: Original: > So…what’s the way out? It’s a smart focus on clear outcomes, not output, with roadmapped outcomes replacing planned milestones, with trusted product teams, not project teams, empowered to vet assumptions and discover the minimal path to value. Rewritten: > So… what’s the way out? It’s a focus on clear outcomes, not output. There should be dates for when specific outcomes should happen. Teams should be empowered to find the minimal amount of work needed to achieve the outcomes. It's a really wordy way to say what any good leadership class would tell you. Focus on what you want more than how you get it, and let your subordinates decide how to get it. Both good product teams and project teams are capable of working that way. This kinda sums up my problem with endless agile vs. waterfall vs. whatever discussions. The interesting parts aren't really new ideas and the extra buzzwords add nothing.

Terretta 7y ago
Interesting, I’d interpret “roadmapped outcomes replacing planned milestones” to mean there should not be predetermined dates and deliverables (planned milestones), but rather, a sequence of value-delivering outcomes (roadmapped outcomes).
- cljs-js-eval 7y ago
  A relative order of outcomes could also work, yeah. You'll have a date in there somewhere, though, even if it's not driven off the amount of work. Could be "and if we can't achieve this outcome by X date we give up on this whole outcome".