3 ms·

> My current team is doing kanban. We have post-it notes that we move around. I have no idea what they represent. Since the whole point of Kanban, Scrum and si

> My current team is doing kanban. We have post-it notes that we move around. I have no idea what they represent. Since the whole point of Kanban, Scrum and similar systems is to manage your work, I'd say that's the place to start figuring it out. If you don't understand what work's being done, you can't have any input, and can't improve things (one of the other points of Kanban). Also, Kanban is a pull system, not push, so it works very differently to most methodologies. You can see it in some of the modern web companies like 37Signals, with their "develop the HTML first" mantra, as well as XP and TDD. Kanban doesn't relate to testing at all as far as I know, but Scrum has their "definition of done", in that everything should be ready to ship when it's done. Normally that includes being code complete, having automated tests, customer signoff, etc.

specialist 14y ago
#1 - I understand kanban in the physical (mfg) world perfectly well. It might even have value in some knowledge/creative industries, where there's a solid, predetermined, well defined workflow. Publishing, for instance. What I'm saying is that the kanban strategy does not apply to software development. Full stop. Does not map. Not applicable. Completely unrelated. Irrelevant. Moot. Nonsensical. Like measuring feline happiness in banana units. If my employer could effectively chunk my work into itty bitty little stickies, they wouldn't need me. #2 - When have you seen a scrum iteration planned around the QA/test cycle? Never? The sprints are defined by PHBs, devs grudgingly play along, QA/test can just suck it. A real QA/test org would say a product is done when its done. I've not seen that happen on any scrum project. Rather, products are done when they've run out of time or juice (eg Yourdon's death march).
- anthonyb 14y ago
  #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 understand kanban in the physical (mfg) world perfectly well. It might even have value in some knowledge/creative industries, where there's a solid, predetermined, well defined workflow. Publishing, for instance. What I'm saying is that the kanban strategy does not apply to software development. Full stop. Does not map. Not applicable. Completely unrelated. Irrelevant. Moot. Nonsensical. Like measuring feline happiness in banana units. If my employer could effectively chunk my work into itty bitty little stickies, they wouldn't need me. #2 - When have you seen a scrum iteration planned around the QA/test cycle? Never? The sprints are defined by PHBs, devs grudgingly play along, QA/test can just suck it. A real QA/test org would say a product is done when its done. I've not seen that happen on any scrum project. Rather, products are done when they've run out of time or juice (eg Yourdon's death march).

anthonyb 14y ago
#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).