4 ms·

I much prefer Kanban to Scrum. It gets straight to the point which is "what is the next most important thing to do", and let's management/stakeholders worry abo

I much prefer Kanban to Scrum. It gets straight to the point which is "what is the next most important thing to do", and let's management/stakeholders worry about what's next while engineers focus on the current top of their heap. Where Scrum wiggles its way into relevance is schedule. Most businesses need to be able to commit to some deadline with customers or coordinating teams, and scrum lets managers convince themselves that they can project 3-6 months of work into sprints. The reality of course is that the requirements and deadlines are constantly moving and never match what was predicted, but you need _some_ prediction to coordinate large projects. So scrum just ends up being a hack to generate time pressure on the component tasks. What's the right solution? So far in my life it comes down to Kanban and focus for engineers, plus an experienced leader that can guess reasonably well, pad for uncertainty, and renegotiate requirements to make that guess come true.

Ensorceled 2y ago
> Where Scrum wiggles its way into relevance is schedule. I use both ... Kanban for operations/IT/Support, Scrum for product development. > So scrum just ends up being a hack to generate time pressure on the component tasks. Yes, but also it let's you figure you are off track early in the project. Too many people let themselves be fooled into thinking that "we went off the rails for a few weeks but we're back on track now" without some kind of process to force you to acknowledge the problem.
givemeethekeys 2y ago
Scrum starts at the management level. Let's say a project is expected to take 4 weeks to complete. Then, it is no longer a Scrum project. It is a waterfall project that is pretending to be a Scrum project. With Scrum, everyone commits to working on something that will be done within the release cycle (usually 1 week), then re-evaluating based on feedback. This means asking for smaller things more often. Trouble is that most people don't know how to ask for and build by starting lean and staying lean. They get ahead of themselves (and the team) by assuming more than they should.
- Spivak 2y ago
  I don't know why you're being downvoted, this is correct. How you make schedules and roadmaps in a scrum world is you track some conversion between difficulty as estimated by each developer to the observed time it takes that developer to complete. Then you write up some cards that you think encapsulate the work you want, have the devs groom them by splitting, recombining, and rating their difficulty. Then you total up the time of the cards, add some buffer, and report that as your estimated completion date. Then you run the board in priority order like any other backlog tracking how additions, removals, or changes in priority affect the completion date. At all times the work gets done when it gets done, and the devs never have to think about more than the current sprint and the next deliverable. Anything not in the current sprint is subject to change.
  - skydhash 2y ago
    Because all of this quickly moph to useless ceremony. Managing a project and doing it are orthogonal. But there’s a relationship between the two that, if managed well, leads to a successfull completion. And that relationship is communication. At each step of the doing, managing should have feedback so that it’s know how expectations are going. Then decisions are taken that influences further doing. There is no need for all the splitting and grooming. A project can have a deadline (soft or hard) or not. It can depends on other projects and other projects can depend on it. A project can be planned, cancelled or paused. And their duration can vary. Then you assign the project to a team (can be adhoc). The team then decides how to get it done.
    - Spivak 2y ago
      I mean this is absolutely true but the goal of this flow is to take very little dev time to enable the project managers to asynchronously (meaning not bothering the devs because the report can be derived entirely from the board state) give project status updates and updated milestone estimates to the higher ups, and get out ahead of potential issues and blockers (like dependencies on external teams like design). No company is going to give a project to a team of devs with a deadline and then let them fuck about with no observability into the team's work until the deadline. This is the "team" deciding how to get work done, the person conducting the ceremony should be the direct people/work manager for the team.

Ensorceled 2y ago

> Where Scrum wiggles its way into relevance is schedule. I use both ... Kanban for operations/IT/Support, Scrum for product development. > So scrum just ends up being a hack to generate time pressure on the component tasks. Yes, but also it let's you figure you are off track early in the project. Too many people let themselves be fooled into thinking that "we went off the rails for a few weeks but we're back on track now" without some kind of process to force you to acknowledge the problem.

givemeethekeys 2y ago

Scrum starts at the management level. Let's say a project is expected to take 4 weeks to complete. Then, it is no longer a Scrum project. It is a waterfall project that is pretending to be a Scrum project. With Scrum, everyone commits to working on something that will be done within the release cycle (usually 1 week), then re-evaluating based on feedback. This means asking for smaller things more often. Trouble is that most people don't know how to ask for and build by starting lean and staying lean. They get ahead of themselves (and the team) by assuming more than they should.

Spivak 2y ago
I don't know why you're being downvoted, this is correct. How you make schedules and roadmaps in a scrum world is you track some conversion between difficulty as estimated by each developer to the observed time it takes that developer to complete. Then you write up some cards that you think encapsulate the work you want, have the devs groom them by splitting, recombining, and rating their difficulty. Then you total up the time of the cards, add some buffer, and report that as your estimated completion date. Then you run the board in priority order like any other backlog tracking how additions, removals, or changes in priority affect the completion date. At all times the work gets done when it gets done, and the devs never have to think about more than the current sprint and the next deliverable. Anything not in the current sprint is subject to change.
- skydhash 2y ago
  Because all of this quickly moph to useless ceremony. Managing a project and doing it are orthogonal. But there’s a relationship between the two that, if managed well, leads to a successfull completion. And that relationship is communication. At each step of the doing, managing should have feedback so that it’s know how expectations are going. Then decisions are taken that influences further doing. There is no need for all the splitting and grooming. A project can have a deadline (soft or hard) or not. It can depends on other projects and other projects can depend on it. A project can be planned, cancelled or paused. And their duration can vary. Then you assign the project to a team (can be adhoc). The team then decides how to get it done.
  - Spivak 2y ago
    I mean this is absolutely true but the goal of this flow is to take very little dev time to enable the project managers to asynchronously (meaning not bothering the devs because the report can be derived entirely from the board state) give project status updates and updated milestone estimates to the higher ups, and get out ahead of potential issues and blockers (like dependencies on external teams like design). No company is going to give a project to a team of devs with a deadline and then let them fuck about with no observability into the team's work until the deadline. This is the "team" deciding how to get work done, the person conducting the ceremony should be the direct people/work manager for the team.