4 ms·

Author of the post here, thanks for your comment. As you said, the fact that you have to stick out your neck and fight for code quality is very annoying, and af

Author of the post here, thanks for your comment. As you said, the fact that you have to stick out your neck and fight for code quality is very annoying, and after some time, one just stops doing it, and starts flowing with the "add the one more line of crap to get things working and collect the points".

shepbook 10y ago
I feel much the same way as much of what you've said in this post. I'm curious what you think of things like the #NoEstimates camp that removes the ambiguity and "gut check" nature of things like points or even time estimates?
- afroisalreadyin 10y ago
  I read the first chapter of the no estimates book, and have to admit that I found it weak on arguments and poorly written. I think there is real value into doing software estimations if you take them seriously, even using story points, but there must be better ways of using those estimates. One really interesting way of doing this is the Monte Carlo estimate method I linked to in the blog post. Would love to try that sometime, and see how it works out.
  - galleman 10y ago
    The notion that the business can make decision in the presence of uncertainty is the basis of No Estimates. As a participant in another accelerator our funding sources would find that laughable at best and toss us out the cohort at worst.
discreteevent 10y ago
"Lean" is supposed to address quality and habitability more. 2 of the 7 tenets of lean focus on it: Build Quality In Optimize the Whole I've never practiced it and my only exposure has been reading some of the book "Lean Architecture". But it certainly seems like an improvement over Scrum which seems blind to some of the most critical things in developing complex innovative systems. In fact I'm convinced that Scrum was designed to work with basic information systems where a feature consists of essentially adding a new data entry form or report for a database (e.g. a lot of web stuff)
- Spooky23 10y ago
  Remember that "Lean" (SCRUM is really a subset of those practices) is at it's core a manufacturing process. Manufacturing isn't engineering. The author of the original post captured this very well: > ...one can claim that this is not the job of Scrum, which is a software management methodology, and not a software engineering methodology, that it's only concerned with organizing the teams' time and workload A manufacturing process can only drive quality if both the primitives and end system have gone through some sort of engineering process. Web developers love this stuff because they have components, frameworks and clients where the engineering details are taken care of in MANY scenarios. Using a contrived scenario involving LEGO -- you cannot expect kids and parents to design new LEGO parts. The components are designed and engineered to work together in a completely different context. Carrying this further, if you want kids to assemble a consistent, specific artifact (Say a Star Wars X-Wing fighter), someone at LEGO needs to design that and produce documentation. Designing on the fly with sprints ("ok, kids, today figure out how to make a wing") isn't going to be a productive exercise. Most SCRUM projects that I have personally seen fail are projects where "agile" is a codeword for "we didn't think this through, so we'll figure it out as we go". Then the "sprints" become a real joke as the team repeatedly runs into a wall.
- afroisalreadyin 10y ago
  That book appears to be very interesting, I'll definitely have a look. Thanks for the tip.

shepbook 10y ago

I feel much the same way as much of what you've said in this post. I'm curious what you think of things like the #NoEstimates camp that removes the ambiguity and "gut check" nature of things like points or even time estimates?

afroisalreadyin 10y ago
I read the first chapter of the no estimates book, and have to admit that I found it weak on arguments and poorly written. I think there is real value into doing software estimations if you take them seriously, even using story points, but there must be better ways of using those estimates. One really interesting way of doing this is the Monte Carlo estimate method I linked to in the blog post. Would love to try that sometime, and see how it works out.
- galleman 10y ago
  The notion that the business can make decision in the presence of uncertainty is the basis of No Estimates. As a participant in another accelerator our funding sources would find that laughable at best and toss us out the cohort at worst.

discreteevent 10y ago

"Lean" is supposed to address quality and habitability more. 2 of the 7 tenets of lean focus on it: Build Quality In Optimize the Whole I've never practiced it and my only exposure has been reading some of the book "Lean Architecture". But it certainly seems like an improvement over Scrum which seems blind to some of the most critical things in developing complex innovative systems. In fact I'm convinced that Scrum was designed to work with basic information systems where a feature consists of essentially adding a new data entry form or report for a database (e.g. a lot of web stuff)

Spooky23 10y ago
Remember that "Lean" (SCRUM is really a subset of those practices) is at it's core a manufacturing process. Manufacturing isn't engineering. The author of the original post captured this very well: > ...one can claim that this is not the job of Scrum, which is a software management methodology, and not a software engineering methodology, that it's only concerned with organizing the teams' time and workload A manufacturing process can only drive quality if both the primitives and end system have gone through some sort of engineering process. Web developers love this stuff because they have components, frameworks and clients where the engineering details are taken care of in MANY scenarios. Using a contrived scenario involving LEGO -- you cannot expect kids and parents to design new LEGO parts. The components are designed and engineered to work together in a completely different context. Carrying this further, if you want kids to assemble a consistent, specific artifact (Say a Star Wars X-Wing fighter), someone at LEGO needs to design that and produce documentation. Designing on the fly with sprints ("ok, kids, today figure out how to make a wing") isn't going to be a productive exercise. Most SCRUM projects that I have personally seen fail are projects where "agile" is a codeword for "we didn't think this through, so we'll figure it out as we go". Then the "sprints" become a real joke as the team repeatedly runs into a wall.
afroisalreadyin 10y ago
That book appears to be very interesting, I'll definitely have a look. Thanks for the tip.