4 ms·

Title close to click-bait or false advertising, since this article just argues Scrum is broken. Suggests next article will get into fixing. > If the thesis th

Title close to click-bait or false advertising, since this article just argues Scrum is broken. Suggests next article will get into fixing. > If the thesis that “90% of everything is waste” then Planning Poker is also a waste, and we should devise a planning process to avoid this. > In the next article we’ll look at how we might do that.

wpietri 7y ago
In case anybody wants an answer to that, here's mine: Cost estimates only are valuable if a) the amount of time involved is relatively large, b) you expect to learn nothing during that time, and c) the expected-value estimates are precise enough that you can calculate a narrow ROI range. Instead, the way I prefer to work is with continuous delivery and small units of work. If you are releasing daily or more often in a context where you can learn a lot via experiments and user tests, then estimates cease to be valuable. Another way to look at this is in terms of push systems versus pull systems. Scrum was made for push systems, where executives push large idea lumps through a plan/design/build/release process. In that world, estimates are valuable, if only because executives like to appear in control and need signals to tell them when to yell at people. But in a pull system, you have small, cross-functional teams observing user behavior, developing problem and solution hypotheses. There, delivery is used mainly to test hypotheses, which are then revised based on new data. In this context, batch estimates are generally wasteful because new data and new hypotheses change the basis for estimation too often. There's rarely sense in estimating a month of work when every day you're learning things that change what you'll do and how you do it.
bobm_kite9 7y ago
Author here. Sorry you think that. I see the article title has been changed, although I wrote this about 3 weeks ago so I'm not sure why it's been labelled as (2019). This article focuses on the Timebox issue. I'll be posting the follow up in a couple of weeks, will post on HN... although there's plenty of other content on this site that covers where I'll be going with that solution. Apologies if it didn't cover everything you wanted - but I find that long articles tend to lose the readers too easily, and I'm trying to keep to a single main point-per-article in my writing as a matter of discipline. I'll look forward to your thoughts on the next one.
- FZ1 7y ago
  Just letting you know the link to the 10X article gives a 404. I tried to read it, but "page does not exist". ---- Edit for clarification: First link in first paragraph after "10X" section header. About "visited the terrain before".
  - bobm_kite9 7y ago
    Thanks for letting me know - some Jekyll weirdness going on there, will look into it when there's less traffic.
- loopz 7y ago
  The ending is your actual point, which is excellent. With scrum being so oversold in companies, it's a hard sell though. So an article starting out with this premise would perhaps gain better traction: "But actually, we’re now three degrees away from the original problem of trying to build the right thing. The team is focused on figuring out how much they can get done in a Sprint, not whether they are building the right thing. Scrum purists might argue that this is the purpose of the Sprint Goal, which should be agreed in advance.. but actually this is usually just a bunch of items from the backlog, shoe-horned into a sprint-sized chunk of time."
  - bobm_kite9 7y ago
    Author here. Yes, the overall feeling I'm getting from the responses is a disappointment that I didn't get to this. Initially that had been my intent, but as I wrote it I realised I was trying to crowbar too much into a single article. However, I am pleased that people seem to agree with this article's diagnosis of the problem. The next article will build upon this one (and others in the series). Hopefully it will be equally well considered on HN, I am interested to see how it goes down.

wpietri 7y ago

In case anybody wants an answer to that, here's mine: Cost estimates only are valuable if a) the amount of time involved is relatively large, b) you expect to learn nothing during that time, and c) the expected-value estimates are precise enough that you can calculate a narrow ROI range. Instead, the way I prefer to work is with continuous delivery and small units of work. If you are releasing daily or more often in a context where you can learn a lot via experiments and user tests, then estimates cease to be valuable. Another way to look at this is in terms of push systems versus pull systems. Scrum was made for push systems, where executives push large idea lumps through a plan/design/build/release process. In that world, estimates are valuable, if only because executives like to appear in control and need signals to tell them when to yell at people. But in a pull system, you have small, cross-functional teams observing user behavior, developing problem and solution hypotheses. There, delivery is used mainly to test hypotheses, which are then revised based on new data. In this context, batch estimates are generally wasteful because new data and new hypotheses change the basis for estimation too often. There's rarely sense in estimating a month of work when every day you're learning things that change what you'll do and how you do it.

bobm_kite9 7y ago

Author here. Sorry you think that. I see the article title has been changed, although I wrote this about 3 weeks ago so I'm not sure why it's been labelled as (2019). This article focuses on the Timebox issue. I'll be posting the follow up in a couple of weeks, will post on HN... although there's plenty of other content on this site that covers where I'll be going with that solution. Apologies if it didn't cover everything you wanted - but I find that long articles tend to lose the readers too easily, and I'm trying to keep to a single main point-per-article in my writing as a matter of discipline. I'll look forward to your thoughts on the next one.

FZ1 7y ago
Just letting you know the link to the 10X article gives a 404. I tried to read it, but "page does not exist". ---- Edit for clarification: First link in first paragraph after "10X" section header. About "visited the terrain before".
- bobm_kite9 7y ago
  Thanks for letting me know - some Jekyll weirdness going on there, will look into it when there's less traffic.
loopz 7y ago
The ending is your actual point, which is excellent. With scrum being so oversold in companies, it's a hard sell though. So an article starting out with this premise would perhaps gain better traction: "But actually, we’re now three degrees away from the original problem of trying to build the right thing. The team is focused on figuring out how much they can get done in a Sprint, not whether they are building the right thing. Scrum purists might argue that this is the purpose of the Sprint Goal, which should be agreed in advance.. but actually this is usually just a bunch of items from the backlog, shoe-horned into a sprint-sized chunk of time."
- bobm_kite9 7y ago
  Author here. Yes, the overall feeling I'm getting from the responses is a disappointment that I didn't get to this. Initially that had been my intent, but as I wrote it I realised I was trying to crowbar too much into a single article. However, I am pleased that people seem to agree with this article's diagnosis of the problem. The next article will build upon this one (and others in the series). Hopefully it will be equally well considered on HN, I am interested to see how it goes down.