3 ms·

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 a

by 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.
  - skydhash 2y ago
    The role of the project manager is to provide the observability. I strongly believe there’s no metrics collected at the team level that maters in terms of the business objectives other than progression. Something may be classified at hard, but once it’s got done once, replicating it is easy (assuming resources are available). Inside the team, it’s another world and that would simply depends on the teams. Maybe it’s a senior with a few juniors and the former is just handing down detailed tasks to the latter leaving the toughest issues for himself. Maybe it’s a collection of experts and it’s a chaotic collection of tiny tasks that everyone takes at random. The project manager just needs to interact with them, measure “progression”, ensuring communication across teams, and updating everyone about priorities. Handing down the process from high has a high chance of harming the teams.
  - CRConrad 2y ago
    > 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) Yeah, sure. The Kanban board.
Log_out_ 2y ago
Then you question the devs ability to predict a unknown piece of softwares complexity 3 months from now and put your own numbers down .
CRConrad 2y ago
That sounds 1) Like the ideal theoretical Scrum. (I've never actually seen that in practice.) 2) Like a lot of converting, estimating, splitting, recombining, and rating. (So, that's a full-time "Professional Scrum Master" position, then? What happened to "Agile teams manage themselves; 'scrum master' is at most a rotating part-time task"?)

by Spivak 2y ago

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.
- skydhash 2y ago
  The role of the project manager is to provide the observability. I strongly believe there’s no metrics collected at the team level that maters in terms of the business objectives other than progression. Something may be classified at hard, but once it’s got done once, replicating it is easy (assuming resources are available). Inside the team, it’s another world and that would simply depends on the teams. Maybe it’s a senior with a few juniors and the former is just handing down detailed tasks to the latter leaving the toughest issues for himself. Maybe it’s a collection of experts and it’s a chaotic collection of tiny tasks that everyone takes at random. The project manager just needs to interact with them, measure “progression”, ensuring communication across teams, and updating everyone about priorities. Handing down the process from high has a high chance of harming the teams.
- CRConrad 2y ago
  > 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) Yeah, sure. The Kanban board.

Log_out_ 2y ago

Then you question the devs ability to predict a unknown piece of softwares complexity 3 months from now and put your own numbers down .

CRConrad 2y ago

That sounds 1) Like the ideal theoretical Scrum. (I've never actually seen that in practice.) 2) Like a lot of converting, estimating, splitting, recombining, and rating. (So, that's a full-time "Professional Scrum Master" position, then? What happened to "Agile teams manage themselves; 'scrum master' is at most a rotating part-time task"?)