6 ms·

There is a type of negotiation that can be done: Negotiation about scope. Work doesn’t get compressed. But stakeholders can identify non-essential business-faci

There is a type of negotiation that can be done: Negotiation about scope. Work doesn’t get compressed. But stakeholders can identify non-essential business-facing features and cut scope. Note well: Automated testing is almost certainly essential. If someone says you are “building an MVP”, then make sure it is an actual MVP. Make sure you have a clear market hypothesis to test and check that it couldn’t be built out of duct tape, Google Forms, Zapier, ITTT, manual processes, and excel-wrangling.

drunkpotato 8y ago
Hah! You just described the start of one of our products so accurately it’s scary! And then we built out the parts that were starting to fail as the product scaled. You can get surprisingly far this way!
mgkimsal 8y ago
Testing will happen. The choice you make is who does the testing and when it happens. Internal people testing earlier is generally preferable to external customers testing 'live', but either way, the testing will happen.
- afarrell 8y ago
  “We can’t make those UX improvements to our core open-source product because then we’s have to introduce untested code. The current code is tested because users have used it and reported the bugs and we’ve fixed them.” Is a real thing a project lead said to me at a previous employer.
  - philk10 8y ago
    "Or customers are better at finding the bugs than we are so just give it a quick look over and ship it" - genuine quote from CEO at a company I soon left
    - Bartweiss 8y ago
      Honestly, I'm surprised more companies don't formalize this. There are places that offer customers discounts or feature-request priority in return for being beta testers, which seems like a major improvement in both integrity and efficient feedback. I suppose it's both slower and more expensive than "just ship bad code at full price and wait", but I'd still expect more companies to choose it as the intermediate option between that and comprehensive in-house testing.
Spooky23 8y ago
End of the day, this is what agile is. By accepting scope items in small batches, you end up done.
commandlinefan 8y ago
> Negotiation about scope. I used to work for an online travel site - before every project kicked off, the business analysts would produce requirements documents that always started with a "flexibility matrix". The flexibility matrix had three rows labeled "schedule", "scope", and "resources" and three columns: "flexible", "moderately flexible" and "inflexible" and they were supposed to check one option for each row. So every single requirements document listed "resources" and "flexible", "scope" as "moderately flexible" and schedule, OF COURSE, "inflexible".
- jerf 8y ago
  You sound like you're complaining, but your complaint may be incomplete. If those bullet points were honored, that is indeed how pretty much every organization doing development will operate, whether it likes it or not. That is not intrinsically a problem. I take it these requirements documents were not honored by your non-developers? A document labeling scope as "moderately inflexible" does little if it's treated as written in stone.
  - Bartweiss 8y ago
    One basis for complaint that stands out to me is framing "flexible resources" as a full degree of freedom. The first question is of course whether that's true, since resources don't tend to flex up unless someone outside the project dictates it. But even if it's accurate, it tends to produce the situation The Mythical Man-Month was written to condemn. If the ship date can't move and the scope won't bend on core features, there's a very real risk of finding that extra resources can't fix the timeline problems. You're right that most organizations have to operate this way, and it's not inherently bad; I've just found that "flexible resources" is often used as a way to avoid admitting that the real third category is "risk of failure".
    - commandlinefan 8y ago
      Actually it started out as a 2x2 matrix (scope/schedule), and all of them were scope = flexible and schedule = inflexible (of course), and they started adding the "resources = flexible" row so that they could walk back their claims of scope being flexible, because of course it wasn't.
c0vfefe 8y ago
Good, fast, & cheap - Pick any 2, at most! https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle

drunkpotato 8y ago

Hah! You just described the start of one of our products so accurately it’s scary! And then we built out the parts that were starting to fail as the product scaled. You can get surprisingly far this way!

mgkimsal 8y ago

Testing will happen. The choice you make is who does the testing and when it happens. Internal people testing earlier is generally preferable to external customers testing 'live', but either way, the testing will happen.

afarrell 8y ago
“We can’t make those UX improvements to our core open-source product because then we’s have to introduce untested code. The current code is tested because users have used it and reported the bugs and we’ve fixed them.” Is a real thing a project lead said to me at a previous employer.
- philk10 8y ago
  "Or customers are better at finding the bugs than we are so just give it a quick look over and ship it" - genuine quote from CEO at a company I soon left
  - Bartweiss 8y ago
    Honestly, I'm surprised more companies don't formalize this. There are places that offer customers discounts or feature-request priority in return for being beta testers, which seems like a major improvement in both integrity and efficient feedback. I suppose it's both slower and more expensive than "just ship bad code at full price and wait", but I'd still expect more companies to choose it as the intermediate option between that and comprehensive in-house testing.

Spooky23 8y ago

End of the day, this is what agile is. By accepting scope items in small batches, you end up done.

commandlinefan 8y ago

> Negotiation about scope. I used to work for an online travel site - before every project kicked off, the business analysts would produce requirements documents that always started with a "flexibility matrix". The flexibility matrix had three rows labeled "schedule", "scope", and "resources" and three columns: "flexible", "moderately flexible" and "inflexible" and they were supposed to check one option for each row. So every single requirements document listed "resources" and "flexible", "scope" as "moderately flexible" and schedule, OF COURSE, "inflexible".

jerf 8y ago
You sound like you're complaining, but your complaint may be incomplete. If those bullet points were honored, that is indeed how pretty much every organization doing development will operate, whether it likes it or not. That is not intrinsically a problem. I take it these requirements documents were not honored by your non-developers? A document labeling scope as "moderately inflexible" does little if it's treated as written in stone.
- Bartweiss 8y ago
  One basis for complaint that stands out to me is framing "flexible resources" as a full degree of freedom. The first question is of course whether that's true, since resources don't tend to flex up unless someone outside the project dictates it. But even if it's accurate, it tends to produce the situation The Mythical Man-Month was written to condemn. If the ship date can't move and the scope won't bend on core features, there's a very real risk of finding that extra resources can't fix the timeline problems. You're right that most organizations have to operate this way, and it's not inherently bad; I've just found that "flexible resources" is often used as a way to avoid admitting that the real third category is "risk of failure".
  - commandlinefan 8y ago
    Actually it started out as a 2x2 matrix (scope/schedule), and all of them were scope = flexible and schedule = inflexible (of course), and they started adding the "resources = flexible" row so that they could walk back their claims of scope being flexible, because of course it wasn't.

c0vfefe 8y ago

Good, fast, & cheap - Pick any 2, at most! https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle