5 ms·

The Insufficiency of Scrum

21 points by BillSchofield 17y ago

raganwald 17y ago
When Ken trained me on Scrum, he was very clear about the fact that Scrum in and of itself was not sufficient for project success. Scrum punts a large number of important decisions to the "Project Owner," and therefore it is a very poor fit with projects that don't have an active,hands on project owner or proxy for the project owner. if you have a incoherent project owner whose priorities drift from sprint to sprint, you will end up with a beautifully executed, disciplined execution of an incoherent product.
- Retric 17y ago
  Scrum forces the client to decide which features are most important. It bribes them with the idea they can have some things next week to avoid a death march 6 months from now. This helps to create useful products without wasting time building useless things. As long as the most important 80% works chances are the project will be considered useful even if it does not do everything. Which is important but it requires a skilled team to execute well over time.
  - raganwald 17y ago
    > Scrum forces the client to decide which features are most important Aaaaah, I think it's fair to say that Scrum forces the client to declare which features are most urgent and that in the ideal project the client aligns urgency and importance. However, just like real life, it is difficult to align these two orthogonal concepts. Sometimes things become urgent because they are tantalizingly easy to do. Sometimes things become urgent because someone important thinks they are important. Sometimes things become urgent because the client is personally invested in them. I agree that "as long as the most important 80% works chances are the project will be considered useful even if it does not do everything," but I am cautious about assuming that just because you ask the client to name the most important features ona sprint-by-sprint basis that you will agree in hindsight that the most important 80% of a product got done.
- gchucky 17y ago
  > if you have a incoherent project owner whose priorities drift from sprint to sprint, you will end up with a beautifully executed, disciplined execution of an incoherent product. Could not agree more with that. And I think that's one of the pitfalls of Scrum: that it works well if you have a relatively well defined project that's not really going to change. If you have to change around your whole system every sprint, nothing is ever going to get done.
  - mrbgty 17y ago
    Interesting. I thought one of the main advantages of Scrum was to be able to adapt to changing requirements. From wikipedia: "A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner.As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements."
presidentender 17y ago
I have to ask: how often do these formal buzzword project management techniques find their way into the real world? I've not been doing this long, but it seems to me that the folks who set deliverables either don't use these methodologies, or use an unnamed amalgamation. Am I wrong?
- philfreo 17y ago
  I think you'd be surprised at how many funded startups are using scrum, as well as some large tech companies, at least in the valley.
- mikeryan 17y ago
  Agile methodologies have made their way into many startups and established companies. When I was working at Comcast large portions of the software engineering groups was starting to sync on a product cycle. That being said - I've not seen much consistency across implementations. It generally breaks down to some sort of product backlog which is worked on in small chunks on some cycle (months, weeks, two-weeks whatever...). This is a pretty basic change to the normal waterfall cycle and easy to implement, and works well for many teams. The rest of the Agile/Scrum/pick your particular method is left to the project/product/SE manager and you really have to find what works for your team, and I'm not sure makes that big of a difference in the end.
- raganwald 17y ago
  ING Direct (USA) uses Scrum and has for years. They are very happy with the results.
- mechanical_fish 17y ago
  It depends entirely on where you are. Some projects are a completely chaotic mess, of course. Some have a methodology, perhaps cobbled from bits and pieces of conventional wisdom, but they don't give it a name. Some explicitly declare a methodology and pay attention to its rules, more or less. Some, alas, become religious devotees of a methodology, train a police force to enforce the rules, and go into full blown cargo cult mode. But all real-world instantiations of methodologies are, in some sense, "amalgamations". For one thing, none of them are complete. As both the article and Raganwald point out, Scrum is far from a complete description of what you need to do to organize a successful project, just as using Lisp and Emacs aren't sufficient conditions for producing great software.
thunk 17y ago
Yeah, it needs a little more OT in the middle.
- thunk 17y ago
  Note for posterity: I meant in the middle.
patrickwelsh 17y ago
What feels least sufficient to me are systems for learning Scrum, or XP, or any blend of practices/patterns/principles well enough to do more good than damage. We therefore generalize from poor data. We draw conclusions from poor execution during the learning curve. Another big issue for me, in SW Dev, is the opacity of "code asset" deterioration as we start to iterate features through it quickly. Scrum can exacerbate that. Once we start cranking the Sprint crank, poorly disciplined programmers can hack the code to bits even faster than before, without stakeholders noticing. Hence agile wags once called Scrum "XP without the P".

21 points by BillSchofield 17y ago

When Ken trained me on Scrum, he was very clear about the fact that Scrum in and of itself was not sufficient for project success. Scrum punts a large number of important decisions to the "Project Owner," and therefore it is a very poor fit with projects that don't have an active,hands on project owner or proxy for the project owner. if you have a incoherent project owner whose priorities drift from sprint to sprint, you will end up with a beautifully executed, disciplined execution of an incoherent product.

Retric 17y ago
Scrum forces the client to decide which features are most important. It bribes them with the idea they can have some things next week to avoid a death march 6 months from now. This helps to create useful products without wasting time building useless things. As long as the most important 80% works chances are the project will be considered useful even if it does not do everything. Which is important but it requires a skilled team to execute well over time.
- raganwald 17y ago
  > Scrum forces the client to decide which features are most important Aaaaah, I think it's fair to say that Scrum forces the client to declare which features are most urgent and that in the ideal project the client aligns urgency and importance. However, just like real life, it is difficult to align these two orthogonal concepts. Sometimes things become urgent because they are tantalizingly easy to do. Sometimes things become urgent because someone important thinks they are important. Sometimes things become urgent because the client is personally invested in them. I agree that "as long as the most important 80% works chances are the project will be considered useful even if it does not do everything," but I am cautious about assuming that just because you ask the client to name the most important features ona sprint-by-sprint basis that you will agree in hindsight that the most important 80% of a product got done.
gchucky 17y ago
> if you have a incoherent project owner whose priorities drift from sprint to sprint, you will end up with a beautifully executed, disciplined execution of an incoherent product. Could not agree more with that. And I think that's one of the pitfalls of Scrum: that it works well if you have a relatively well defined project that's not really going to change. If you have to change around your whole system every sprint, nothing is ever going to get done.
- mrbgty 17y ago
  Interesting. I thought one of the main advantages of Scrum was to be able to adapt to changing requirements. From wikipedia: "A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner.As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements."

presidentender 17y ago

I have to ask: how often do these formal buzzword project management techniques find their way into the real world? I've not been doing this long, but it seems to me that the folks who set deliverables either don't use these methodologies, or use an unnamed amalgamation. Am I wrong?

philfreo 17y ago
I think you'd be surprised at how many funded startups are using scrum, as well as some large tech companies, at least in the valley.
mikeryan 17y ago
Agile methodologies have made their way into many startups and established companies. When I was working at Comcast large portions of the software engineering groups was starting to sync on a product cycle. That being said - I've not seen much consistency across implementations. It generally breaks down to some sort of product backlog which is worked on in small chunks on some cycle (months, weeks, two-weeks whatever...). This is a pretty basic change to the normal waterfall cycle and easy to implement, and works well for many teams. The rest of the Agile/Scrum/pick your particular method is left to the project/product/SE manager and you really have to find what works for your team, and I'm not sure makes that big of a difference in the end.
raganwald 17y ago
ING Direct (USA) uses Scrum and has for years. They are very happy with the results.
mechanical_fish 17y ago
It depends entirely on where you are. Some projects are a completely chaotic mess, of course. Some have a methodology, perhaps cobbled from bits and pieces of conventional wisdom, but they don't give it a name. Some explicitly declare a methodology and pay attention to its rules, more or less. Some, alas, become religious devotees of a methodology, train a police force to enforce the rules, and go into full blown cargo cult mode. But all real-world instantiations of methodologies are, in some sense, "amalgamations". For one thing, none of them are complete. As both the article and Raganwald point out, Scrum is far from a complete description of what you need to do to organize a successful project, just as using Lisp and Emacs aren't sufficient conditions for producing great software.

thunk 17y ago

Yeah, it needs a little more OT in the middle.

thunk 17y ago
Note for posterity: I meant in the middle.

patrickwelsh 17y ago

What feels least sufficient to me are systems for learning Scrum, or XP, or any blend of practices/patterns/principles well enough to do more good than damage. We therefore generalize from poor data. We draw conclusions from poor execution during the learning curve. Another big issue for me, in SW Dev, is the opacity of "code asset" deterioration as we start to iterate features through it quickly. Scrum can exacerbate that. Once we start cranking the Sprint crank, poorly disciplined programmers can hack the code to bits even faster than before, without stakeholders noticing. Hence agile wags once called Scrum "XP without the P".