9 ms·

> With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, No, there isn't. You adhere to your burn-down, n

by debacle 14y ago

> With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating. > Iteration planning meetings are seriously expensive. Then you're doing it wrong (god, I feel awful for saying that). If you're spending that much time in pre-sprint planning, people aren't bringing enough to the table and you're not defining your problems well enough before trying to solve them. > I hate the term “scrum-but”. Ironic that that sounds like exactly what the environment you were working in sounds like. > This might be a bit controversial, but the big difference between Scrum and things like Lean Software Development for me were the difference of focusing on process versus delivery. I think this is a "forest for the trees" issue. Scrum is about abstracting the process into a rigid and lightweight framework so you only have to think about it, at most, fifteen minutes a day (unless you have the misfortune of being the Scrum master/cat wrangler) > It can’t, and it’s not a problem with your organization if it doesn’t. It’s a problem with Scrum. That's a non-sequitur. It's a problem with neither. If my company can't implement a waterfall methodology because our clients require faster iteration, that doesn't mean there's a problem with either - it's just not a good fit. But if your company tries to implement Scrum and throws it out six weeks or six months later because it's "too hard" or "bad," my assumption is that real Scrum probably wasn't happening. Will Scrum work for everyone? Fuck no. Scrum is hard. It requires the kind of buy in that, if you've got it, you probably don't need Scrum anyway. Can Scrum work for everyone? Probably. Scrum is only hard when you've got conflicting goals. If you have a smart enough team, you can tweak your sprint lengths from as little as a few days to as long as six to eight weeks, and after you've been on Scrum for a few sprints your planning meetings should take an hour or two, tops.

sethg 14y ago
In my experience (six months at a job that does Scrum and, I think, does it very well), the thing that slows down iteration planning meetings is when the product manager hands down a one-sentence feature description, the engineers say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-minute discussion in order to expand that one sentence into something resembling a spec.
- debacle 14y ago
  If the project manager throws out a feature description like that, just say "Yes" and throw it to the bottom of the backlog - it'll be revisited when it's well defined.
  - Domenic_S 14y ago
    The product backlog? The engineers don't control the product backlog. This strategy falls flat when the PM committed to a stakeholder that they'd get a feature done without defining it well or resolving dependencies, so now we have to sit for 15 minutes hammering it out. Note that I'm not totally disagreeing, but textbook scrum and what-happens-when-people-spend-a-lot-of-money-to-develop-something scrum often diverge greatly. The ultimate business purpose of scrum is to manage expectations. What's going to be done, when's it going to be done, if something's stuck who is responsible, etc. If the PM starts making wild promises and setting crazy expectations -- which PMs are wont to do -- all the methodology in the world isn't going to save you.
  - anthonyb 14y ago
    No - because you're not the business owner and don't decide what order things go in the backlog. A better way is to just give a sufficiently large estimate: "That's 100 points* due to risk and uncertainty." If they want a more detailed estimate, then they have to give a more detailed story. * - whatever will give you 6 +/- 3 months
    - tetha 14y ago
      This is one of the best things an older programmer has taught me. If people want estimations on vague things, give them 8 month full team full time. Minimum. Doesn't matter what it is. Implement a new, small feature? 8 month. Move the office furniture around? 8 month. People talking to you learn quickly to give out more precise specifications.
      - anthonyb 14y ago
        I should point out that just throwing out a 100 point story over nothing is a bad plan career-wise - you definitely need to be able to back it up with reasons (we need to interface with systems x, y and z, this is comparable to other system w which took 8 months, we don't have any spec for doing a, b or c). In that sense the 100 point estimate is a real one - a "small" feature (eg. add a form to your web site) might be two or three weeks of work.
wccrawford 14y ago
>It requires the kind of buy in that, if you've got it, you probably don't need Scrum anyway. I agreed up until this. I worked for a company that was doing waterfall and miserable. Things were getting done, but it was a sloppy mess. Clearly we didn't have our stuff together. Our manager went and took scrum classes, and then we spent a few months trying it out. There was no day-one benefit, but over those months we managed to wrangle things around until everyone was on the same page. After that, things went a lot smoother. Management was actually planning things out (instead of just throwing projects around and hoping) and we had a clear view of what we would be working on at any given time. Shared resources, like the sysadmin and network admin and db admin, were able to be scheduled more effectively instead of project waiting on them, or them sitting around doing nothing. So no, I don't think that Scrum requires the kind of buy-in that indicates you don't need Scrum in the first place.
- pestaa 14y ago
  > After that, [...] Management was actually planning things out The company probably would have worked just fine using the waterfall method if the management had bothered to work at all, I guess. It improved not because of your manager took scrum classes, but because your manager took any classes.
tosh 14y ago
“A bad system, will defeat a good person, every time.” -- Deming I can no longer count how often I heard "you're doing it wrong" when people explain why scrum didn't work for them or when they feel there needs to be something that works 'better'. Getting Scrum right is hard. Managing huge backlogs is hard. Doing time-based sprint plannings is hard, especially if you are working on stuff that is either new or new to your team. If you are doing routine work you might as well use waterfall or "jfdi" as your approach. Burn-down charts, velocity and sprint planning doesn't help if you just don't know where the next problem will be or when your team variation changes constantly (people move to other teams, new people join, people get sick, …). I've found that changing/being able to change the 'system' (scrum) to something else that works better (agile/lean to its roots, kanban, different stand-up meeting format, evidence based time-tracking, value-flow …) is way more effective than changing the people to become 'better' at Scrum and doing it less 'wrong'. YMMV
- alphadogg 14y ago
  I'm curious about "different stand-up meeting format". What format(s) do you use?
Domenic_S 14y ago
> > With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, > No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. Of course there is. There is no burn-down, no 'time', without tasks. So while in a pedantic sense you're right that you commit to 'time', time is measured in stories.
- anthonyb 14y ago
  Time (of stories) is measured in points. You won't be talking about a 10 story sprint.
  - Domenic_S 14y ago
    Substitute one for the other. The people depending on your delivery don't understand (or care) that you're doing a x-point sprint, they care that their feature is delivered.
    - anthonyb 14y ago
      If they "don't understand (or care) that you're doing a x-point sprint", then you have big problems, since they have to choose 'x' points worth of stories to put into a sprint, and that's one of their two key responsibilities. Also, you cannot substitute points for stories - that's the whole point of the estimation process. (and also a large part of why software projects fail. "Doing 'A' is 10x harder than doing 'B'" seems to be hard to understand until you have points to spend).
      - adrianhoward 14y ago
        I find this thread fascinating as Scrum actually says nothing about stories, or points, or hours. It also says nothing about the estimation process that the team should use. It also says nothing about the process to be used to select the sprint goal and the PBIs to be completed in the sprint. All Scrum says is that: 1) there are things on the backlog (it doesn't specific what product backlog items are or should be - they could be user stories, they could be old-fashioned requirements docs, they could be use cases - Scrum doesn't care). 2) there is a Sprint Planning Meeting where the team and the product owner agree what the sprint goal is and the team forecasts the Product Backlog items it will deliver to meet that sprint goal. The rest is up to the team. Teams decide to track hours or points or story counting. Teams decide whether an estimation process is useful. Also, you cannot substitute points for stories - that's the whole point of the estimation process. (and also a large part of why software projects fail. "Doing 'A' is 10x harder than doing 'B'" seems to be hard to understand until you have points to spend Many teams can and do just count stories. Folk like Ron Jeffries who invented the point counting / velocity concept now prefer and recommend story counting. There's a whole group of folk who eschew estimating entirely (See stuff like naked planning for example http://aaron.sanders.name/agile-fashion/naked-planning-explained-kanban-in-the-small http://aaron.sanders.name/agile-fashion/naked-planning-expla...).
adrianhoward 14y ago
No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating. Erm. There is an explicit commitment by the Scrum team to complete the stories selected to produce the next increment in the sprint. To quote from http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scru... "The two parts of the Sprint Planning Meeting answer the following questions, respectively:  What will be delivered in the Increment resulting from the upcoming Sprint?  How will the work needed to deliver the Increment be achieved?" The commitment on delivering a certain chunk of work has been one of the more controversial elements of Scrum. Many people who say they're doing Scrum don't do this. But it is very definitely part of the Scrum process as defined.

by debacle 14y ago

sethg 14y ago

In my experience (six months at a job that does Scrum and, I think, does it very well), the thing that slows down iteration planning meetings is when the product manager hands down a one-sentence feature description, the engineers say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-minute discussion in order to expand that one sentence into something resembling a spec.

debacle 14y ago
If the project manager throws out a feature description like that, just say "Yes" and throw it to the bottom of the backlog - it'll be revisited when it's well defined.
- Domenic_S 14y ago
  The product backlog? The engineers don't control the product backlog. This strategy falls flat when the PM committed to a stakeholder that they'd get a feature done without defining it well or resolving dependencies, so now we have to sit for 15 minutes hammering it out. Note that I'm not totally disagreeing, but textbook scrum and what-happens-when-people-spend-a-lot-of-money-to-develop-something scrum often diverge greatly. The ultimate business purpose of scrum is to manage expectations. What's going to be done, when's it going to be done, if something's stuck who is responsible, etc. If the PM starts making wild promises and setting crazy expectations -- which PMs are wont to do -- all the methodology in the world isn't going to save you.
- anthonyb 14y ago
  No - because you're not the business owner and don't decide what order things go in the backlog. A better way is to just give a sufficiently large estimate: "That's 100 points* due to risk and uncertainty." If they want a more detailed estimate, then they have to give a more detailed story. * - whatever will give you 6 +/- 3 months
  - tetha 14y ago
    This is one of the best things an older programmer has taught me. If people want estimations on vague things, give them 8 month full team full time. Minimum. Doesn't matter what it is. Implement a new, small feature? 8 month. Move the office furniture around? 8 month. People talking to you learn quickly to give out more precise specifications.
    - anthonyb 14y ago
      I should point out that just throwing out a 100 point story over nothing is a bad plan career-wise - you definitely need to be able to back it up with reasons (we need to interface with systems x, y and z, this is comparable to other system w which took 8 months, we don't have any spec for doing a, b or c). In that sense the 100 point estimate is a real one - a "small" feature (eg. add a form to your web site) might be two or three weeks of work.

wccrawford 14y ago

>It requires the kind of buy in that, if you've got it, you probably don't need Scrum anyway. I agreed up until this. I worked for a company that was doing waterfall and miserable. Things were getting done, but it was a sloppy mess. Clearly we didn't have our stuff together. Our manager went and took scrum classes, and then we spent a few months trying it out. There was no day-one benefit, but over those months we managed to wrangle things around until everyone was on the same page. After that, things went a lot smoother. Management was actually planning things out (instead of just throwing projects around and hoping) and we had a clear view of what we would be working on at any given time. Shared resources, like the sysadmin and network admin and db admin, were able to be scheduled more effectively instead of project waiting on them, or them sitting around doing nothing. So no, I don't think that Scrum requires the kind of buy-in that indicates you don't need Scrum in the first place.

pestaa 14y ago
> After that, [...] Management was actually planning things out The company probably would have worked just fine using the waterfall method if the management had bothered to work at all, I guess. It improved not because of your manager took scrum classes, but because your manager took any classes.

tosh 14y ago

“A bad system, will defeat a good person, every time.” -- Deming I can no longer count how often I heard "you're doing it wrong" when people explain why scrum didn't work for them or when they feel there needs to be something that works 'better'. Getting Scrum right is hard. Managing huge backlogs is hard. Doing time-based sprint plannings is hard, especially if you are working on stuff that is either new or new to your team. If you are doing routine work you might as well use waterfall or "jfdi" as your approach. Burn-down charts, velocity and sprint planning doesn't help if you just don't know where the next problem will be or when your team variation changes constantly (people move to other teams, new people join, people get sick, …). I've found that changing/being able to change the 'system' (scrum) to something else that works better (agile/lean to its roots, kanban, different stand-up meeting format, evidence based time-tracking, value-flow …) is way more effective than changing the people to become 'better' at Scrum and doing it less 'wrong'. YMMV

alphadogg 14y ago
I'm curious about "different stand-up meeting format". What format(s) do you use?

Domenic_S 14y ago

> > With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, > No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. Of course there is. There is no burn-down, no 'time', without tasks. So while in a pedantic sense you're right that you commit to 'time', time is measured in stories.

anthonyb 14y ago
Time (of stories) is measured in points. You won't be talking about a 10 story sprint.
- Domenic_S 14y ago
  Substitute one for the other. The people depending on your delivery don't understand (or care) that you're doing a x-point sprint, they care that their feature is delivered.
  - anthonyb 14y ago
    If they "don't understand (or care) that you're doing a x-point sprint", then you have big problems, since they have to choose 'x' points worth of stories to put into a sprint, and that's one of their two key responsibilities. Also, you cannot substitute points for stories - that's the whole point of the estimation process. (and also a large part of why software projects fail. "Doing 'A' is 10x harder than doing 'B'" seems to be hard to understand until you have points to spend).
    - adrianhoward 14y ago
      I find this thread fascinating as Scrum actually says nothing about stories, or points, or hours. It also says nothing about the estimation process that the team should use. It also says nothing about the process to be used to select the sprint goal and the PBIs to be completed in the sprint. All Scrum says is that: 1) there are things on the backlog (it doesn't specific what product backlog items are or should be - they could be user stories, they could be old-fashioned requirements docs, they could be use cases - Scrum doesn't care). 2) there is a Sprint Planning Meeting where the team and the product owner agree what the sprint goal is and the team forecasts the Product Backlog items it will deliver to meet that sprint goal. The rest is up to the team. Teams decide to track hours or points or story counting. Teams decide whether an estimation process is useful. Also, you cannot substitute points for stories - that's the whole point of the estimation process. (and also a large part of why software projects fail. "Doing 'A' is 10x harder than doing 'B'" seems to be hard to understand until you have points to spend Many teams can and do just count stories. Folk like Ron Jeffries who invented the point counting / velocity concept now prefer and recommend story counting. There's a whole group of folk who eschew estimating entirely (See stuff like naked planning for example http://aaron.sanders.name/agile-fashion/naked-planning-explained-kanban-in-the-small http://aaron.sanders.name/agile-fashion/naked-planning-expla...).

adrianhoward 14y ago

No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating. Erm. There is an explicit commitment by the Scrum team to complete the stories selected to produce the next increment in the sprint. To quote from http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scru... "The two parts of the Sprint Planning Meeting answer the following questions, respectively:  What will be delivered in the Increment resulting from the upcoming Sprint?  How will the work needed to deliver the Increment be achieved?" The commitment on delivering a certain chunk of work has been one of the more controversial elements of Scrum. Many people who say they're doing Scrum don't do this. But it is very definitely part of the Scrum process as defined.