4 ms·

The author is right that, with scrum you end up focusing more on process and not delivery. There are nice things about scrum, but I think scrum followers are t

The author is right that, with scrum you end up focusing more on process and not delivery. There are nice things about scrum, but I think scrum followers are too doctrinaire. It has some well-defined practices and is associated with that agile "manifesto" that you are compelled to buy into if you adopt scrum. Being doctrinaire about anything is guaranteed to distance you from reality - you give project managers a weapon to coerce you into worrying about how to break down your work into a velocity and stories and tasks. Any time you enforce a process like that, you are disengaging yourself from the reality of having to ship something.

vannevar 14y ago
Scrum is focused almost exclusively on delivery. Every sprint, you should be delivering working features. It's not that hard: every sprint, you commit to a set of stories to finish before the next sprint. Every day you meet briefly to tell everyone how you're progressing and to air out any impediments. That's about it. To me, scrum is stripping process down to the bare minimum you need to be effective.
- barrkel 14y ago
  And it's fantastic when you're on a tight schedule! Instead of running fast all the time, you just sprint, then sprint, then sprint, etc! Works like magic. No one burns out at all.
  - MartinCron 14y ago
    I don't know if you meant that in a sarcastic way, but this does touch on a pet peeve of mine with Scrum, the word "sprint" is, by definition, not a sustainable pace.
    - anthonyb 14y ago
      So call it something else, like "an iteration".
    - Evbn 14y ago
      You rest, reflect, and recompose between sprints.
  - vannevar 14y ago
    Not quite. You sprint, then you take time to review and reflect on what you've done. Then you take time to plan what you're going to do next. Then you sprint again.
    - barrkel 14y ago
      IME the "review, reflect and plan" is a one-hour meeting on a Friday, every two or three weeks.
      - Evbn 14y ago
        Change it to two days. When do you squeeze in your retrospective? Your presentation of the deliverable to stakholders? Negotiating next sprint commitments? Researching before you do estimation?
  - baconner 14y ago
    Well... yeah! if you get some other core parts of scrum right then nobody should be burning out. Time boxing and point estimation are about figuring out what your team's sustainable pace is and using that to avoid burnout. Scrum isn't about developing faster its about working toward more sustainable and predictable development. If your management doesn't understand that and respect it no methodology will fix your problem. I admit as someone else mentioned that sprint was a poor choice of words. So say iteration instead. Problem solved.
- dasil003 14y ago
  I've never done formal scrum, but I've worked on a lot of teams, and I just don't see how there is a single bare minimum you need to be effective. In my experience, even with excellent teams, this depends on the project and the talents of the contributors.
  - vannevar 14y ago
    To me, the bare minimum for success in software development is clear direction, continuous communication, and continuous verification of the product. Scrum is a simple process to ensure that all three actually occur and aren't merely good intentions left up to individual discretion. I guess you could come up with alternatives, but it would be tough to make it much simpler and still cover all three.
    - leothekim 14y ago
      I've done formal scrum before, and I can see where you're coming from, but my experience scrum didn't ensure continuous communication. The company where I worked actually actively prevented cross-team communication. They did this because the scrum masters and director of engineering claimed it would generate work that couldn't be captured by stories, so velocity couldn't be accurately tracked and people's time could be spent on the "wrong" things. I took as project managers not trusting the engineers to do their jobs. Again, I don't think scrum is all bad, nor do I think it's hard to grok or follow. It's how people adhere to it, and in my experience, people really adhere to it in a way that's detrimental to productivity. For me, it's kind of like religion - I like some of the ideas, but I don't like the fan club.
      - vannevar 14y ago
        Not sure I understand the communication policy you guys were dealing with. If a team is meeting briefly every day and sharing their progress, it ensures that there's at least that much communication. But the daily standup should be a floor on communicating, not a ceiling.
- MartinCron 14y ago
  You can, however, strip it down even further and still be effective. Scrum encourages bundling stories into sets and delivering them all at once. I've been moving away from that, and continuously delivering discrete stories/features/changes/fixes/whatever as they are ready. Decoupling incrementalism from iterations has been a huge change for me.
  - aaronblohowiak 14y ago
    What does QA look like with continuous delivery?
    - MartinCron 14y ago
      Different continuous delivery teams do it differently. I don't like having a dedicated QA team/department. QA is an effort, not a role. The key part of continuous delivery is that the safest change to make to a stable system is the smallest change possible. So instead of batching up lots and lots of stuff and throwing it over the wall to QA, you make one change, have humans and robots test it, and deploy that change. The mindset shifts from "features per release" to "releases per feature" so with truly friction-less automated deployments, you can release very small changes individually. You don't have to test everything in order to change anything. As you may expect, multiple layers of test automation are necessary. Each change runs a gauntlet of different kinds of tests before release. A set of "safe to run in production" tests immediately after release. Rollbacks are trivial, but exceedingly rare. Obviously, this only works in some contexts. If you're pressing things onto gold master DVDs and shipping them in boxes, the QA effort will be more traditional.
    - bwindels 14y ago
      Your automatic (unit, functional, system) tests assure stuff doesn't break (too much), and manual QA happens after deploying. If something is broken, you can fix it very fast, since you are deploying continuously. Stuff might sometimes be broken on production, but you could argue this makes people think twice before pushing to master. Also, you can deploy to production with a delay (e.g. 1h) and deploy to a QA server first to give the QA people some time to check before stuff goes to production.
- programminggeek 14y ago
  Haha, that is only true for a certain type of person. For other people Scrum becomes about "the rules" and if you break one of the rules, you're doing it wrong, even if that might be the best decision at the time. Agile is a philosophy, Scrum is meant to be more of a framework to implement that philosophy, but many people treat it as a set of rules on how to do things, which tends to violate the philosophy of Agile process in the first place.
  - Evbn 14y ago
    In that regard, how is scrum different from anything ever? Anyone can be process obsessed in any system. And, dare I say it, giving a process to Asperger, socially tone-deaf, shoe-staring programmers may help them contribute more effectively to a larger organization.

vannevar 14y ago

Scrum is focused almost exclusively on delivery. Every sprint, you should be delivering working features. It's not that hard: every sprint, you commit to a set of stories to finish before the next sprint. Every day you meet briefly to tell everyone how you're progressing and to air out any impediments. That's about it. To me, scrum is stripping process down to the bare minimum you need to be effective.

barrkel 14y ago
And it's fantastic when you're on a tight schedule! Instead of running fast all the time, you just sprint, then sprint, then sprint, etc! Works like magic. No one burns out at all.
- MartinCron 14y ago
  I don't know if you meant that in a sarcastic way, but this does touch on a pet peeve of mine with Scrum, the word "sprint" is, by definition, not a sustainable pace.
  - anthonyb 14y ago
    So call it something else, like "an iteration".
  - Evbn 14y ago
    You rest, reflect, and recompose between sprints.
- vannevar 14y ago
  Not quite. You sprint, then you take time to review and reflect on what you've done. Then you take time to plan what you're going to do next. Then you sprint again.
  - barrkel 14y ago
    IME the "review, reflect and plan" is a one-hour meeting on a Friday, every two or three weeks.
    - Evbn 14y ago
      Change it to two days. When do you squeeze in your retrospective? Your presentation of the deliverable to stakholders? Negotiating next sprint commitments? Researching before you do estimation?
- baconner 14y ago
  Well... yeah! if you get some other core parts of scrum right then nobody should be burning out. Time boxing and point estimation are about figuring out what your team's sustainable pace is and using that to avoid burnout. Scrum isn't about developing faster its about working toward more sustainable and predictable development. If your management doesn't understand that and respect it no methodology will fix your problem. I admit as someone else mentioned that sprint was a poor choice of words. So say iteration instead. Problem solved.
dasil003 14y ago
I've never done formal scrum, but I've worked on a lot of teams, and I just don't see how there is a single bare minimum you need to be effective. In my experience, even with excellent teams, this depends on the project and the talents of the contributors.
- vannevar 14y ago
  To me, the bare minimum for success in software development is clear direction, continuous communication, and continuous verification of the product. Scrum is a simple process to ensure that all three actually occur and aren't merely good intentions left up to individual discretion. I guess you could come up with alternatives, but it would be tough to make it much simpler and still cover all three.
  - leothekim 14y ago
    I've done formal scrum before, and I can see where you're coming from, but my experience scrum didn't ensure continuous communication. The company where I worked actually actively prevented cross-team communication. They did this because the scrum masters and director of engineering claimed it would generate work that couldn't be captured by stories, so velocity couldn't be accurately tracked and people's time could be spent on the "wrong" things. I took as project managers not trusting the engineers to do their jobs. Again, I don't think scrum is all bad, nor do I think it's hard to grok or follow. It's how people adhere to it, and in my experience, people really adhere to it in a way that's detrimental to productivity. For me, it's kind of like religion - I like some of the ideas, but I don't like the fan club.
    - vannevar 14y ago
      Not sure I understand the communication policy you guys were dealing with. If a team is meeting briefly every day and sharing their progress, it ensures that there's at least that much communication. But the daily standup should be a floor on communicating, not a ceiling.
MartinCron 14y ago
You can, however, strip it down even further and still be effective. Scrum encourages bundling stories into sets and delivering them all at once. I've been moving away from that, and continuously delivering discrete stories/features/changes/fixes/whatever as they are ready. Decoupling incrementalism from iterations has been a huge change for me.
- aaronblohowiak 14y ago
  What does QA look like with continuous delivery?
  - MartinCron 14y ago
    Different continuous delivery teams do it differently. I don't like having a dedicated QA team/department. QA is an effort, not a role. The key part of continuous delivery is that the safest change to make to a stable system is the smallest change possible. So instead of batching up lots and lots of stuff and throwing it over the wall to QA, you make one change, have humans and robots test it, and deploy that change. The mindset shifts from "features per release" to "releases per feature" so with truly friction-less automated deployments, you can release very small changes individually. You don't have to test everything in order to change anything. As you may expect, multiple layers of test automation are necessary. Each change runs a gauntlet of different kinds of tests before release. A set of "safe to run in production" tests immediately after release. Rollbacks are trivial, but exceedingly rare. Obviously, this only works in some contexts. If you're pressing things onto gold master DVDs and shipping them in boxes, the QA effort will be more traditional.
  - bwindels 14y ago
    Your automatic (unit, functional, system) tests assure stuff doesn't break (too much), and manual QA happens after deploying. If something is broken, you can fix it very fast, since you are deploying continuously. Stuff might sometimes be broken on production, but you could argue this makes people think twice before pushing to master. Also, you can deploy to production with a delay (e.g. 1h) and deploy to a QA server first to give the QA people some time to check before stuff goes to production.
programminggeek 14y ago
Haha, that is only true for a certain type of person. For other people Scrum becomes about "the rules" and if you break one of the rules, you're doing it wrong, even if that might be the best decision at the time. Agile is a philosophy, Scrum is meant to be more of a framework to implement that philosophy, but many people treat it as a set of rules on how to do things, which tends to violate the philosophy of Agile process in the first place.
- Evbn 14y ago
  In that regard, how is scrum different from anything ever? Anyone can be process obsessed in any system. And, dare I say it, giving a process to Asperger, socially tone-deaf, shoe-staring programmers may help them contribute more effectively to a larger organization.