3 ms·

In fact on at least 2 occasions in my career adding scrum practices to a product team essentially destroyed them. Why was Scrum added to these teams if they we

In fact on at least 2 occasions in my career adding scrum practices to a product team essentially destroyed them. Why was Scrum added to these teams if they were already working? It's a tool to deal with problems. It's not something to use if another process is already working. I’ve seen instances of all of the items the article claims being problems in practice. I have found essentially the exact opposite of all the problems that are claimed to exist, and I've equally seen no research to confirm that they somehow destroy teams. my anecdotal experience & the lack of data forgive me for being skeptical of a practice that seems largely around to keep process consultants in business My experience directly contradicts that. Every Scrum-ish team I've worked with has had a pretty steady pace of development and produced good software. Some other processes have worked too; the worst I've seen are fake-agile-actually-waterfall processes. I’m certainly not receptive to a defense that someone who criticizes it just works at the wrong place or hasn’t seen “real” scrum. There's no such thing as 'real Scrum' so I won't use that defence. A good process is one that works for the team and company. Scrum is not a universal solution; for extremely high-performing teams it's probably overkill; for bureaucratic teams it will crush everything. It's just another good tool to use where appropriate.

kasey_junk 9y ago
Usually scrum seems to be added for the sake of ‘predictability’ But nothing about the process fundamentally change the problems with software estimation. So in cases where teams are delivering rapidly at high quality but unpredictably, scrum acts as a place to hang paperwork & as a process to hide bad project managers. All while lying to management with charts.
- cbsmith 9y ago
  > But nothing about the process fundamentally change the problems with software estimation. I'd argue quite the contrary. > scrum acts as a place to hang paperwork & as a process to hide bad project managers. All while lying to management with charts. So weird. The "paperwork" tends to make bad project managers all too transparent.
  - kasey_junk 9y ago
    You'd be arguing against research in that case. Software estimation is a widely studied subject and no estimation technique we've found has brought projects into the 'predictable' mode. There are a few different estimation techniques that are better than others but scrum actively avoids those techniques (probably for the best as they are expensive and don't show huge gains over other forms of estimation). Instead scrum attempts to track a made up velocity number by using any number of known to be inaccurate estimation techniques. It then gets hyper focused on breaking down tasks into small enough tasks that the velocity number stays constant, all while forgetting about the real desire, the quality software the business desires, delivered to paying customers. At that task, scrum has proven to be no more predictable than any other technique. An enlightening exercise for any project manager is to go to a sales team and explain what you are delivering in a given sprint. Almost always, they won't care at all about that, and will instead ask for when some 'major epic' thing will be done, at which point you won't be able to tell them with any more certainty than if you'd just guessed. Thats the best case. The worst case is that all that work you put into showing transparency around velocity ends up being used against the teams working on the hardest and most innovative projects in your organization. Their velocity will be all over the map while the maintenance teams will look good. You'll have convinced the leadership of the organization that velocity is a real number to track (cause you spend so much resources tracking it) and the incentive structures will reflect it. You just made it worse for good engineers to join the teams solving your hard problems.
    - chris11 9y ago
      > There are a few different estimation techniques that are better than others but scrum actively avoids those techniques (probably for the best as they are expensive and don't show huge gains over other forms of estimation). What methods would you suggest for software estimation then?
      - kasey_junk 9y ago
        I wouldn’t do it. Prioritize your backlog, work on the most important things, reprioritize at your planning meetings. Invest in going fast, reliability & figuring out priorities. There are lots of agile methodologies that abandoned the estimation step for the reasons I mention (fdd,rad,dsdm).

kasey_junk 9y ago

Usually scrum seems to be added for the sake of ‘predictability’ But nothing about the process fundamentally change the problems with software estimation. So in cases where teams are delivering rapidly at high quality but unpredictably, scrum acts as a place to hang paperwork & as a process to hide bad project managers. All while lying to management with charts.

cbsmith 9y ago
> But nothing about the process fundamentally change the problems with software estimation. I'd argue quite the contrary. > scrum acts as a place to hang paperwork & as a process to hide bad project managers. All while lying to management with charts. So weird. The "paperwork" tends to make bad project managers all too transparent.
- kasey_junk 9y ago
  You'd be arguing against research in that case. Software estimation is a widely studied subject and no estimation technique we've found has brought projects into the 'predictable' mode. There are a few different estimation techniques that are better than others but scrum actively avoids those techniques (probably for the best as they are expensive and don't show huge gains over other forms of estimation). Instead scrum attempts to track a made up velocity number by using any number of known to be inaccurate estimation techniques. It then gets hyper focused on breaking down tasks into small enough tasks that the velocity number stays constant, all while forgetting about the real desire, the quality software the business desires, delivered to paying customers. At that task, scrum has proven to be no more predictable than any other technique. An enlightening exercise for any project manager is to go to a sales team and explain what you are delivering in a given sprint. Almost always, they won't care at all about that, and will instead ask for when some 'major epic' thing will be done, at which point you won't be able to tell them with any more certainty than if you'd just guessed. Thats the best case. The worst case is that all that work you put into showing transparency around velocity ends up being used against the teams working on the hardest and most innovative projects in your organization. Their velocity will be all over the map while the maintenance teams will look good. You'll have convinced the leadership of the organization that velocity is a real number to track (cause you spend so much resources tracking it) and the incentive structures will reflect it. You just made it worse for good engineers to join the teams solving your hard problems.
  - chris11 9y ago
    > There are a few different estimation techniques that are better than others but scrum actively avoids those techniques (probably for the best as they are expensive and don't show huge gains over other forms of estimation). What methods would you suggest for software estimation then?
    - kasey_junk 9y ago
      I wouldn’t do it. Prioritize your backlog, work on the most important things, reprioritize at your planning meetings. Invest in going fast, reliability & figuring out priorities. There are lots of agile methodologies that abandoned the estimation step for the reasons I mention (fdd,rad,dsdm).