3 ms·

#1 - designer needs to put a box that does 'x' on your web app (login, show shiny stars, number of commits, whatever). He writes the HTML and calls on devs to h

#1 - designer needs to put a box that does 'x' on your web app (login, show shiny stars, number of commits, whatever). He writes the HTML and calls on devs to help him implement whatever he needs to make that box happen. Devs implement a template tag, then the function calls that are needed to support it, maybe extend the database models or interfaces they need to make that happen, etc. HTML -> code -> database. How is that not Kanban/pull? This pattern appears in a lot of places once you start looking for it, from SICP and their 'pretend the function already exists' onwards. #2 - Testing is part of the feature, not bolted on. If a feature isn't tested, by both QA and your customer, it's not done, is it? Not in traditional Scrum, anyway. If your definition of done includes "ship it, untested, to the customer at the last minute", by all means document that with a poster on your wall ;) And if the PHBs are defining both the length of the sprint and what goes into it, then it's not really scrum either. The whole point of the timeboxing is not to have a death march, but to avoid a death march, and a whole bunch of features glommed on, untested, at the last minute.

specialist 14y ago
#1 - Use cases can be chunked. The first iteration. There after it's all fit, wiggle, finish, adjustment. We have daily back and froths about "the other 90%" of effort. The PHBs want stickies for all the inevitable ancillary tasks that spawn from top level tasks. To me, it's just make work, the "process tax" that Yegge refers to. #2 - I'd agree with you about "by sprint end" for unit tests and any other harnesses that devs can write. But real QA/test work? I just don't see it. When I've been in charge, the three areas (reqs, dev, test) are interleaved. Makes for nice feedback loops. If dev and test had their own sprints, with test trailing by a week or so, I could almost see that working. #2b - I've never seen sprints finish nicely, where unfinished work (points) didn't carry over to the next sprint. Total fiction that anything gets "done". With proper project management, imho, the scope of work is predetermined and things get dropped to meet a hard deadline, or the deadline is pushed. And the final acceptance testing (e.g. go/no-go process), without fail, takes two weeks. That's tacked on to the tail of when everyone has jointly decided that everything's "done". I've yet to see that kind of quality, rigor, professionalism using scrum.
- ricardobeat 14y ago
  Apparently your problem is having PHBs and a dysfunctional org, not scrum. > the scope of work is predetermined That's bullshit/impossible for most software, and the exact opposite of being agile and catering to real needs, not imagined ones. That's the whole point of agile methodologies, embrace change.
- anthonyb 14y ago
  1. Definitely not. If the story needs fit, wiggle, adjustment, then it's either not really done, or you raise the changes as another story for the next sprint. 2. Done is done - it's a binary yes/no thing. Done but not tested is not done. Done but needs documentation is not done. This varies from place to place, but code-done is not done, and coding is usually only 30-odd % of the work. 2b. If that's the case, then you're overcommitted. Next sprint, drop back to what you managed to get done this sprint. The idea is to get things repeatable and features turning out in a maintainable steady fashion. In practice, it works - if there's some discipline from both the devs and the business. If stuff gets shoehorned in, or devs are pulled off to work on critical stuff, then it works about as well as you'd expect (ie. not very).
  - specialist 14y ago
    #1 - I've never seen UI work that simple. Ever. Maybe my problem is that I'm working on interesting projects. #2 - Tom Lasseter (Pixar) supposedly said "We release snapshots of our movies, they're never done."
  - specialist 14y ago
    #1 - I've never seen UI work that simple. Ever. Maybe my problem is that I'm working on interesting projects. #2 - Tom Lasseter (Pixar) supposedly said "We release snapshots of our movies, they're never done."

specialist 14y ago

#1 - Use cases can be chunked. The first iteration. There after it's all fit, wiggle, finish, adjustment. We have daily back and froths about "the other 90%" of effort. The PHBs want stickies for all the inevitable ancillary tasks that spawn from top level tasks. To me, it's just make work, the "process tax" that Yegge refers to. #2 - I'd agree with you about "by sprint end" for unit tests and any other harnesses that devs can write. But real QA/test work? I just don't see it. When I've been in charge, the three areas (reqs, dev, test) are interleaved. Makes for nice feedback loops. If dev and test had their own sprints, with test trailing by a week or so, I could almost see that working. #2b - I've never seen sprints finish nicely, where unfinished work (points) didn't carry over to the next sprint. Total fiction that anything gets "done". With proper project management, imho, the scope of work is predetermined and things get dropped to meet a hard deadline, or the deadline is pushed. And the final acceptance testing (e.g. go/no-go process), without fail, takes two weeks. That's tacked on to the tail of when everyone has jointly decided that everything's "done". I've yet to see that kind of quality, rigor, professionalism using scrum.

ricardobeat 14y ago
Apparently your problem is having PHBs and a dysfunctional org, not scrum. > the scope of work is predetermined That's bullshit/impossible for most software, and the exact opposite of being agile and catering to real needs, not imagined ones. That's the whole point of agile methodologies, embrace change.
anthonyb 14y ago
1. Definitely not. If the story needs fit, wiggle, adjustment, then it's either not really done, or you raise the changes as another story for the next sprint. 2. Done is done - it's a binary yes/no thing. Done but not tested is not done. Done but needs documentation is not done. This varies from place to place, but code-done is not done, and coding is usually only 30-odd % of the work. 2b. If that's the case, then you're overcommitted. Next sprint, drop back to what you managed to get done this sprint. The idea is to get things repeatable and features turning out in a maintainable steady fashion. In practice, it works - if there's some discipline from both the devs and the business. If stuff gets shoehorned in, or devs are pulled off to work on critical stuff, then it works about as well as you'd expect (ie. not very).
- specialist 14y ago
  #1 - I've never seen UI work that simple. Ever. Maybe my problem is that I'm working on interesting projects. #2 - Tom Lasseter (Pixar) supposedly said "We release snapshots of our movies, they're never done."
- specialist 14y ago
  #1 - I've never seen UI work that simple. Ever. Maybe my problem is that I'm working on interesting projects. #2 - Tom Lasseter (Pixar) supposedly said "We release snapshots of our movies, they're never done."