4 ms·

Because that two weeks you spent writing excellent code is mostly useless unless you have a way to get feedback on it. As a customer, you've given me no value.

by ozmbie 10y ago

Because that two weeks you spent writing excellent code is mostly useless unless you have a way to get feedback on it. As a customer, you've given me no value. What if you finally hook up UI to the sub-component and the customer/stakeholder decides they don't like any of it? You could have known about it earlier.

TeMPOraL 10y ago
That's why I sometimes say at my workplace that we should make our projects in Flash. Faster to make an interactive UI this way and get the approval of the management/customer, no time wasted on useless things like having the program actually work in an efficient, useful and secure way.
- marpstar 10y ago
  ...Flash?
  - TeMPOraL 10y ago
    Yeah, that thingie in which you draw stuff, sprinkle them with a script or two, and with a few click you get something that can be run or embedded in a webpage. The thing HTML 5 supposedly replaced.
- protomyth 10y ago
  I knew some folks in the 90's that prototyped in Shockwave. They did UI and animated uses cases. I was impressed by how quick people got their blob-type people animated use cases that were basically little cartoons. Seemed like way too much work, but I guess it worked for them.
  - TeMPOraL 10y ago
    I've learned the hard way just how effective such prototyping tools can be if you only care about... prototypes. Or the visual stuff. Seeing a designer whipping up a running example in 15 minutes in Construct2 that was equivalent to what me and two of my friends spent last 8 hours coding has taught me to respect those tools, at least in particular use cases. And my point is, if we're focusing only on short-term client-recognizable value, we may as well just make shiny prototypes. Who cares about the pesky internals anyway.
    - protomyth 10y ago
      To be fair to them, they were hella good C++ programmers and used Shockwave to prototype and lock down the business requirements. You can do an amazing amount of specification like that. It was basically CRC cards put to animation as people and things interacting. They provided quite a bit of short and long term value by being better at giving clients an understanding of what they were actually getting. They cared about the internals and making sure their clients understood the logic the internals would use. If I was skilled in some animation tool like they were I would do the same.
dozzie 10y ago
> As a customer, you've given me no value. Erm. But it's you who is the customer in this scenario, not him? Or am I missing something?
- thackerhacker 10y ago
  He's saying that eventually when your feature surfaces as a UI the customer may not like it. To which I have 2 responses: 1. not all features need a UI to be useful 2. this also demonstrates the infantilising nature of scrum where no developers can be trusted to think deeply, talk to stakeholders and otherwise do the right thing in a fully-rounded way but must just follow the exact instructions expressed
  - dozzie 10y ago
    But he said: > As a customer, you've given me no value. Meaning: > You, being a customer, have given me no value. This is what I don't understand.
    - jholman 10y ago
      He said > As a customer, you've given me no value. Meaning: > [From my hypothetical perspective] as a customer, you've given me no value. Or more concisely: > [Speaking] as a customer...
      - dozzie 10y ago
        I'm not sure this is how the grammar works...
  - ozmbie 10y ago
    I mentioned UI because of the parent comment (about hooking UI up to a sub-component). The core idea I was trying to get across is that until a feature is working and in front of a customer (or stakeholder), it's essentially in limbo because you don't know if you've built what they wanted. Maybe there was a miscommunication, maybe they find the feature confusing, maybe they've changed their mind. The goal is to get feedback as soon as reasonably possible. eg: A stakeholder (or customer) requests feature X, and everyone agrees it's a good idea and we should to work on it right away. The dev team could spend 2-4 weeks writing excellent behind-the-scenes code that's not hooked up to anything, or you could spend 2-4 weeks on holiday. Either way, you've given stakeholder the same thing: No new feature. If you're confident that you know exactly what it is you want to build then you don't need Agile, scrum or sprints. Scrum isn't supposed to be waterfall with arbitrary reviews every 2 weeks.
redler 10y ago
The problem with this is that it imposes a membrane on the process that is only permeable to work that contains a shippable piece of user-facing software. It presupposes that all work can be divided into such pieces. And since that's not true, it leads to contorted stories to squeeze necessary work through that membrane.
- abritinthebay 10y ago
  > It presupposes that all work can be divided into such pieces. No, it states the reasonable conclusion that all valuable features can be broken down into such (because otherwise if it adds no value to the product). There are also Scrum tasks around Research, Tech Debt, etc that are perfectly fine to create and work on but they have an affect on your overall time to build new features and that's ok. Because it needs to be done, so they'll get prioritized accordingly.
  - redler 10y ago
    You italicized "valuable features" and I understand why, but I think the trouble spot is actually the word "all"; your parenthetical about adding no value merely begs the question. I'd argue that, indeed, some valuable features can be organically broken down into two-week user-facing deliverables, but certainly not all and probably not even most. There's nothing magical about being able to partition a deliverable into a sprint's time frame that, by such distinction alone, makes it valuable versus valueless. Systems like scrum try to wrangle into a manageable bolus a process that -- if we're to make good softare -- necessarily includes creativity, inspiration, and the traveling of paths yet unseen. It's like writing a novel and having two-week deliverables like "complete the arc of the Alice character", versus "write approximately 100 pages". It's not valueless to write 100 pages, despite not finishing the Alice section, and perhaps specifically because we discover that Alice's emerging story turns out to intersect perfectly with what we want to do with the Bob arc later on. So there's writing and engineering and lines of code versus plotting and architecture and inspiration. We need all of it, right? Does everything that's not a "valuable feature" have to be shunted into the cul de sac of a research spike, doomed to be frowned upon by the management for whom the system otherwise provides the sheen of predictable velocity? Does the critical work of "dreaming" of what to do at both macro and micro levels become a casualty of the banal necessity of marching equal-sized boluses through the development tract? I'm making a florid point, but to me this feels like the essential tension.

by ozmbie 10y ago

TeMPOraL 10y ago

That's why I sometimes say at my workplace that we should make our projects in Flash. Faster to make an interactive UI this way and get the approval of the management/customer, no time wasted on useless things like having the program actually work in an efficient, useful and secure way.

marpstar 10y ago
...Flash?
- TeMPOraL 10y ago
  Yeah, that thingie in which you draw stuff, sprinkle them with a script or two, and with a few click you get something that can be run or embedded in a webpage. The thing HTML 5 supposedly replaced.
protomyth 10y ago
I knew some folks in the 90's that prototyped in Shockwave. They did UI and animated uses cases. I was impressed by how quick people got their blob-type people animated use cases that were basically little cartoons. Seemed like way too much work, but I guess it worked for them.
- TeMPOraL 10y ago
  I've learned the hard way just how effective such prototyping tools can be if you only care about... prototypes. Or the visual stuff. Seeing a designer whipping up a running example in 15 minutes in Construct2 that was equivalent to what me and two of my friends spent last 8 hours coding has taught me to respect those tools, at least in particular use cases. And my point is, if we're focusing only on short-term client-recognizable value, we may as well just make shiny prototypes. Who cares about the pesky internals anyway.
  - protomyth 10y ago
    To be fair to them, they were hella good C++ programmers and used Shockwave to prototype and lock down the business requirements. You can do an amazing amount of specification like that. It was basically CRC cards put to animation as people and things interacting. They provided quite a bit of short and long term value by being better at giving clients an understanding of what they were actually getting. They cared about the internals and making sure their clients understood the logic the internals would use. If I was skilled in some animation tool like they were I would do the same.

dozzie 10y ago

> As a customer, you've given me no value. Erm. But it's you who is the customer in this scenario, not him? Or am I missing something?

thackerhacker 10y ago
He's saying that eventually when your feature surfaces as a UI the customer may not like it. To which I have 2 responses: 1. not all features need a UI to be useful 2. this also demonstrates the infantilising nature of scrum where no developers can be trusted to think deeply, talk to stakeholders and otherwise do the right thing in a fully-rounded way but must just follow the exact instructions expressed
- dozzie 10y ago
  But he said: > As a customer, you've given me no value. Meaning: > You, being a customer, have given me no value. This is what I don't understand.
  - jholman 10y ago
    He said > As a customer, you've given me no value. Meaning: > [From my hypothetical perspective] as a customer, you've given me no value. Or more concisely: > [Speaking] as a customer...
    - dozzie 10y ago
      I'm not sure this is how the grammar works...
- ozmbie 10y ago
  I mentioned UI because of the parent comment (about hooking UI up to a sub-component). The core idea I was trying to get across is that until a feature is working and in front of a customer (or stakeholder), it's essentially in limbo because you don't know if you've built what they wanted. Maybe there was a miscommunication, maybe they find the feature confusing, maybe they've changed their mind. The goal is to get feedback as soon as reasonably possible. eg: A stakeholder (or customer) requests feature X, and everyone agrees it's a good idea and we should to work on it right away. The dev team could spend 2-4 weeks writing excellent behind-the-scenes code that's not hooked up to anything, or you could spend 2-4 weeks on holiday. Either way, you've given stakeholder the same thing: No new feature. If you're confident that you know exactly what it is you want to build then you don't need Agile, scrum or sprints. Scrum isn't supposed to be waterfall with arbitrary reviews every 2 weeks.

redler 10y ago

The problem with this is that it imposes a membrane on the process that is only permeable to work that contains a shippable piece of user-facing software. It presupposes that all work can be divided into such pieces. And since that's not true, it leads to contorted stories to squeeze necessary work through that membrane.

abritinthebay 10y ago
> It presupposes that all work can be divided into such pieces. No, it states the reasonable conclusion that all valuable features can be broken down into such (because otherwise if it adds no value to the product). There are also Scrum tasks around Research, Tech Debt, etc that are perfectly fine to create and work on but they have an affect on your overall time to build new features and that's ok. Because it needs to be done, so they'll get prioritized accordingly.
- redler 10y ago
  You italicized "valuable features" and I understand why, but I think the trouble spot is actually the word "all"; your parenthetical about adding no value merely begs the question. I'd argue that, indeed, some valuable features can be organically broken down into two-week user-facing deliverables, but certainly not all and probably not even most. There's nothing magical about being able to partition a deliverable into a sprint's time frame that, by such distinction alone, makes it valuable versus valueless. Systems like scrum try to wrangle into a manageable bolus a process that -- if we're to make good softare -- necessarily includes creativity, inspiration, and the traveling of paths yet unseen. It's like writing a novel and having two-week deliverables like "complete the arc of the Alice character", versus "write approximately 100 pages". It's not valueless to write 100 pages, despite not finishing the Alice section, and perhaps specifically because we discover that Alice's emerging story turns out to intersect perfectly with what we want to do with the Bob arc later on. So there's writing and engineering and lines of code versus plotting and architecture and inspiration. We need all of it, right? Does everything that's not a "valuable feature" have to be shunted into the cul de sac of a research spike, doomed to be frowned upon by the management for whom the system otherwise provides the sheen of predictable velocity? Does the critical work of "dreaming" of what to do at both macro and micro levels become a casualty of the banal necessity of marching equal-sized boluses through the development tract? I'm making a florid point, but to me this feels like the essential tension.