6 ms·

It's a long time since I've had to deal with "strict" Scrummers. But I do remember being utterly baffled as to the insistence on user features being ready by t

It's a long time since I've had to deal with "strict" Scrummers. But I do remember being utterly baffled as to the insistence on user features being ready by the end of a sprint, even for quite complex, technical components. Why can't we make some sub-component this sprint then the UI bit the next? I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash.

lmm 10y ago
> Why can't we make some sub-component this sprint then the UI bit the next? Because that's how you get bad UI. The user-facing design needs to drive the API interface, not the other way around.
- tener 10y ago
  Not true. If you have design ready before the implementation starts (as you should unless it is very simple) then you are free to implementation things separately. Just have the interface well specified.
  - matthewmacleod 10y ago
    Speaking from a UI developer perspective, this never works :) But YMMV, I suppose…
    - tener 10y ago
      We always do a brainstorming before implementing any serious feature / change. Once we have the initial design business gets involved (if we can get their attention...). The results usually works without needing any drastic changes, which is still better than no planning at all. It does require involvement from a number of parties though.
  - beerwulf 10y ago
    Sounds like you've never worked in a shop where they think "agile" == "no need to plan ahead"
    - tener 10y ago
      This is sad, but my point still holds. Perhaps being honest with oneself about real tasks that need to be done will help. Planning the architecture/feature, doing proof of concept etc. are all valid tasks even if they don't bring immediate business values. If you claim that you can only do business features without doing any exploratory work then you are effectively claiming to have an oracle giving you perfect solutions out of the blue. In which case you should stop whatever you are trying to do and start selling the services of your oracle.
  - lmm 10y ago
    Design is better when it's informed by implementation, IME. The only complete specification is working code; if you accept something lower-fidelity then it's very easy to miss ambiguities.
    - tener 10y ago
      Even code have bugs so it's not perfect. Your design can incorporate high level algorithm to be implemented, ins/outs, or whatever else high level constraints are most applicable to your domain.
  - st3v3r 10y ago
    But if you design things ahead of time, then you're not "agile"!
    - tener 10y ago
      See my other comment regarding oracle: https://news.ycombinator.com/item?id=12249897 https://news.ycombinator.com/item?id=12249897
- fsloth 10y ago
  "The user-facing design needs to drive the API interface, not the other way around." I don't see how this need would nullify the ability to modularize code.
  - lmm 10y ago
    Modularize by functionality, not by layer. Start with a simple end-to-end path and grow outwards, rather than trying to go top-down or bottom-up, and don't split into distinct layers until you're actually deriving value from doing so. Writing code when you don't have the use case yet is always a bad idea.
    - Udik 10y ago
      Yep. And then at the third sprint into this path you realize that the way the backend has been built during the first two sprints makes it impossible to deliver some essential or just very desirable feature that nobody took in consideration because it was outside the scope of the first two sprints. Seen it happen multiple times.
      - lmm 10y ago
        That's the opposite of my experience. It's always the extra layer that was added for some planned feature that we never actually implemented in the end that gets in the way.
    - goalieca 10y ago
      I disagree. This is how you end up with messy code that needs constant refactoring. Making time to come up with a composable design shouldn't be that difficult. It usually isn't.
      - abritinthebay 10y ago
        All code should be constantly refactored. This way your code gets refactored as the design changes (which... it will) rather than having to shoehorn an architecture that worked great originally into a set or requirements that have moved on.
- gmarx 10y ago
  I disagree. It varies from situation to situation but I would argue in my domain at least (healthcare) this is how you get bad data models
- xorblurb 10y ago
  In your church, maybe. In a country where logic reigns, it depends.
  - bighi 10y ago
    Imaginary countries don't count. ;)
- taneq 10y ago
  Depends what you're building. Which leads us to the worst (meta-)aspect of Agile/Scrum these days, which is that it's the industry's current favourite hammer and so it gets used to bash every single problem. Now, hammers are quite versatile, but you have to know when to bash, when to use the claw, when to lever or just nudge things instead of swinging. The moment you start getting dogmatic about your process is the moment your decisions start being driven by something other than your actual needs at hand. And that's the moment when you start to produce a bad product.
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.
abritinthebay 10y ago
> I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash. Are you surprised? The developer isn't the user of the UI, product wise, so no wonder it didn't get very far. The trick in this case is to break the story down. So the original story isn't do-able in one sprint? Ok, so what is actually the MVP of that Story? What's the first block that builds the overall feature? Take a 5 point Story and make it three 2 point Stories or something. That's what the refinement step is for in Scrum. Unless you're doing abnormally short sprints there should be some part of that Story that can be abstracted into a smaller Story that fits into a sprint.

lmm 10y ago

> Why can't we make some sub-component this sprint then the UI bit the next? Because that's how you get bad UI. The user-facing design needs to drive the API interface, not the other way around.

tener 10y ago
Not true. If you have design ready before the implementation starts (as you should unless it is very simple) then you are free to implementation things separately. Just have the interface well specified.
- matthewmacleod 10y ago
  Speaking from a UI developer perspective, this never works :) But YMMV, I suppose…
  - tener 10y ago
    We always do a brainstorming before implementing any serious feature / change. Once we have the initial design business gets involved (if we can get their attention...). The results usually works without needing any drastic changes, which is still better than no planning at all. It does require involvement from a number of parties though.
- beerwulf 10y ago
  Sounds like you've never worked in a shop where they think "agile" == "no need to plan ahead"
  - tener 10y ago
    This is sad, but my point still holds. Perhaps being honest with oneself about real tasks that need to be done will help. Planning the architecture/feature, doing proof of concept etc. are all valid tasks even if they don't bring immediate business values. If you claim that you can only do business features without doing any exploratory work then you are effectively claiming to have an oracle giving you perfect solutions out of the blue. In which case you should stop whatever you are trying to do and start selling the services of your oracle.
- lmm 10y ago
  Design is better when it's informed by implementation, IME. The only complete specification is working code; if you accept something lower-fidelity then it's very easy to miss ambiguities.
  - tener 10y ago
    Even code have bugs so it's not perfect. Your design can incorporate high level algorithm to be implemented, ins/outs, or whatever else high level constraints are most applicable to your domain.
- st3v3r 10y ago
  But if you design things ahead of time, then you're not "agile"!
  - tener 10y ago
    See my other comment regarding oracle: https://news.ycombinator.com/item?id=12249897 https://news.ycombinator.com/item?id=12249897
fsloth 10y ago
"The user-facing design needs to drive the API interface, not the other way around." I don't see how this need would nullify the ability to modularize code.
- lmm 10y ago
  Modularize by functionality, not by layer. Start with a simple end-to-end path and grow outwards, rather than trying to go top-down or bottom-up, and don't split into distinct layers until you're actually deriving value from doing so. Writing code when you don't have the use case yet is always a bad idea.
  - Udik 10y ago
    Yep. And then at the third sprint into this path you realize that the way the backend has been built during the first two sprints makes it impossible to deliver some essential or just very desirable feature that nobody took in consideration because it was outside the scope of the first two sprints. Seen it happen multiple times.
    - lmm 10y ago
      That's the opposite of my experience. It's always the extra layer that was added for some planned feature that we never actually implemented in the end that gets in the way.
  - goalieca 10y ago
    I disagree. This is how you end up with messy code that needs constant refactoring. Making time to come up with a composable design shouldn't be that difficult. It usually isn't.
    - abritinthebay 10y ago
      All code should be constantly refactored. This way your code gets refactored as the design changes (which... it will) rather than having to shoehorn an architecture that worked great originally into a set or requirements that have moved on.
gmarx 10y ago
I disagree. It varies from situation to situation but I would argue in my domain at least (healthcare) this is how you get bad data models
xorblurb 10y ago
In your church, maybe. In a country where logic reigns, it depends.
- bighi 10y ago
  Imaginary countries don't count. ;)
taneq 10y ago
Depends what you're building. Which leads us to the worst (meta-)aspect of Agile/Scrum these days, which is that it's the industry's current favourite hammer and so it gets used to bash every single problem. Now, hammers are quite versatile, but you have to know when to bash, when to use the claw, when to lever or just nudge things instead of swinging. The moment you start getting dogmatic about your process is the moment your decisions start being driven by something other than your actual needs at hand. And that's the moment when you start to produce a bad product.

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.

abritinthebay 10y ago

> I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash. Are you surprised? The developer isn't the user of the UI, product wise, so no wonder it didn't get very far. The trick in this case is to break the story down. So the original story isn't do-able in one sprint? Ok, so what is actually the MVP of that Story? What's the first block that builds the overall feature? Take a 5 point Story and make it three 2 point Stories or something. That's what the refinement step is for in Scrum. Unless you're doing abnormally short sprints there should be some part of that Story that can be abstracted into a smaller Story that fits into a sprint.