3 ms·

Another perspective: Kanban doesn't forbid regular retrospectives. You can still pause frequently, reflect, and update your process accordingly. The purpose

by jrib 4y ago

Another perspective: Kanban doesn't forbid regular retrospectives. You can still pause frequently, reflect, and update your process accordingly. The purpose of sprints is to try to estimate the completion of a release -- and as progress is made the drift from that original prediction. Sprints in theory let a manager estimate a team velocity. Together with estimates for the task in a release, that, in theory, gives one the ability to predict when a set of features (a release) will be complete. I have yet to see this actually work, but it could just be reflective of where I have worked.

vannevar 4y ago
>The purpose of sprints is to try to estimate the completion of a release -- and as progress is made the drift from that original prediction This is not the purpose of sprints. The sprint is a fixed increment of time intended to encourage incremental development of complete software systems. The idea is that while people don't have an intuitive idea about how much work will have to go into developing a complex application, they do have an intuitive feel for how much work they can accomplish in a couple of weeks. So instead of asking, how much time will it take us to implement a fixed set of features, the team will be asking how many features can we implement this sprint? >Sprints in theory let a manager estimate a team velocity. A manager is not a consumer or producer of team velocity. The team itself is the only legitimate consumer and producer of team velocity. Agile is about team self-management.
- seadan83 4y ago
  This idea of asking how much can be implemented in a given sprint is an important clarification. Though, this can be impractical and/or sub-optimal for many contexts. The one-size-fits-all approach of scrum, where so often it is a company or a new person joining and just declaring that "we'll do scrum" now is where things can get de-railed because it is not the universal way to do all development. So, to paraphrase the distinction, instead of death marching for a large set of features without any feedback, the team decides "we won't do more than 2 weeks of work at a time before we ship & deploy some feature." (I really wish I could find the link) A recent hacker news article looked at this situation and noted how this does not really allow for extensive R&D where there is no deliverable after the end of two weeks. An example was Google BigTable which had no deliverable at all for 8 months. Yet, the investment into BigTable lead to a very huge pay-off, and the point made was that there was no good way to break up the R&D required into two week deliverables, and the ROI of that work was far more than most any 2 week increment. Overall the issue for scrum is context, it has its places where it works well - but it is not the one-size fit all solution that so many places try to make it out to be. For example, two weeks does not always allow for a lot of rework, experimentation, architecture, and R&D. A team can choose to make a deliverable be "the results of R&D", is this still fungible thinking and is not actually delivering a release. Personally I would be a lot happier whenever a scrum master and/or product owner/manager that run a scrum team could clarify exactly when scrum is a bad fit (this feels like the expert-beginner problem). If a person knows when scrum is a bad fit, they can at least try to mitigate those problems and/or lean on other development methodologies. It is almost like silo'ing into one programming language and using only that language despite it not being the best tool in some situations (and also of detriment, various alternative techniques are not learned; eg, sometimes a bash script is the right tool to use, and not branching out and trying to solve some problems with a full blown programming language leads to a lot slower of a solution. To illustrate this, Amazon once had a team spend time to find all phone numbers on its website. This took a long time and the program was complex and never worked well, a very competent shell scripter got wind of this and solved it in 15 minutes with a bash one-liner. This became an interview question at Amazon at one point even, in part to check if a candidate will realize that their language of choice might be a bad fit for the problem at hand)
- jrib 4y ago
  > intended to encourage incremental development of complete software systems I've always seen that mainly accomplished by breaking large stories into smaller ones. What do sprints add to this?
  - vannevar 4y ago
    Breaking a story down into smaller stories is not the same as incrementally developing a complete system. This is the difference between reductionism (breaking a large pre-defined project into smaller pieces for execution) and holism (always delivering a complete system, but incrementally extending the functionality as the team learns more). Sprints provide the time increment for the latter. Note that a sprint increment may differ from project to project. But most teams find 2-3 weeks to be a good increment. Even in a reductionist approach, though, sprints provide a regular opportunity to review the appropriateness of the breakdown or the validity of the parent story.
    - jrib 4y ago
      You make a really good point on the importance of having a complete iteration at the end of the sprint. In my experience, the fixed time increments have always felt too constraining. I think a team can accomplish a similar goal of having regular incremental progress in the form of complete systems by relaxing the fixed-length sprints requirement. The alternative that I favor is Kanban with defined releases. A release, as a collection of features, is a complete system, but it doesn't necessarily have to be finished in the same time that the previous release was. A larger release may take six weeks instead of the smaller previous release that only took one. You make a lot of good points, thank you for sharing your thoughts.

by jrib 4y ago

vannevar 4y ago

>The purpose of sprints is to try to estimate the completion of a release -- and as progress is made the drift from that original prediction This is not the purpose of sprints. The sprint is a fixed increment of time intended to encourage incremental development of complete software systems. The idea is that while people don't have an intuitive idea about how much work will have to go into developing a complex application, they do have an intuitive feel for how much work they can accomplish in a couple of weeks. So instead of asking, how much time will it take us to implement a fixed set of features, the team will be asking how many features can we implement this sprint? >Sprints in theory let a manager estimate a team velocity. A manager is not a consumer or producer of team velocity. The team itself is the only legitimate consumer and producer of team velocity. Agile is about team self-management.

seadan83 4y ago
This idea of asking how much can be implemented in a given sprint is an important clarification. Though, this can be impractical and/or sub-optimal for many contexts. The one-size-fits-all approach of scrum, where so often it is a company or a new person joining and just declaring that "we'll do scrum" now is where things can get de-railed because it is not the universal way to do all development. So, to paraphrase the distinction, instead of death marching for a large set of features without any feedback, the team decides "we won't do more than 2 weeks of work at a time before we ship & deploy some feature." (I really wish I could find the link) A recent hacker news article looked at this situation and noted how this does not really allow for extensive R&D where there is no deliverable after the end of two weeks. An example was Google BigTable which had no deliverable at all for 8 months. Yet, the investment into BigTable lead to a very huge pay-off, and the point made was that there was no good way to break up the R&D required into two week deliverables, and the ROI of that work was far more than most any 2 week increment. Overall the issue for scrum is context, it has its places where it works well - but it is not the one-size fit all solution that so many places try to make it out to be. For example, two weeks does not always allow for a lot of rework, experimentation, architecture, and R&D. A team can choose to make a deliverable be "the results of R&D", is this still fungible thinking and is not actually delivering a release. Personally I would be a lot happier whenever a scrum master and/or product owner/manager that run a scrum team could clarify exactly when scrum is a bad fit (this feels like the expert-beginner problem). If a person knows when scrum is a bad fit, they can at least try to mitigate those problems and/or lean on other development methodologies. It is almost like silo'ing into one programming language and using only that language despite it not being the best tool in some situations (and also of detriment, various alternative techniques are not learned; eg, sometimes a bash script is the right tool to use, and not branching out and trying to solve some problems with a full blown programming language leads to a lot slower of a solution. To illustrate this, Amazon once had a team spend time to find all phone numbers on its website. This took a long time and the program was complex and never worked well, a very competent shell scripter got wind of this and solved it in 15 minutes with a bash one-liner. This became an interview question at Amazon at one point even, in part to check if a candidate will realize that their language of choice might be a bad fit for the problem at hand)
jrib 4y ago
> intended to encourage incremental development of complete software systems I've always seen that mainly accomplished by breaking large stories into smaller ones. What do sprints add to this?
- vannevar 4y ago
  Breaking a story down into smaller stories is not the same as incrementally developing a complete system. This is the difference between reductionism (breaking a large pre-defined project into smaller pieces for execution) and holism (always delivering a complete system, but incrementally extending the functionality as the team learns more). Sprints provide the time increment for the latter. Note that a sprint increment may differ from project to project. But most teams find 2-3 weeks to be a good increment. Even in a reductionist approach, though, sprints provide a regular opportunity to review the appropriateness of the breakdown or the validity of the parent story.
  - jrib 4y ago
    You make a really good point on the importance of having a complete iteration at the end of the sprint. In my experience, the fixed time increments have always felt too constraining. I think a team can accomplish a similar goal of having regular incremental progress in the form of complete systems by relaxing the fixed-length sprints requirement. The alternative that I favor is Kanban with defined releases. A release, as a collection of features, is a complete system, but it doesn't necessarily have to be finished in the same time that the previous release was. A larger release may take six weeks instead of the smaller previous release that only took one. You make a lot of good points, thank you for sharing your thoughts.