3 ms·

I also work in machine learning, and as I noted, have used agile methods very successfully in that field, including advanced research into the application of ev

I also work in machine learning, and as I noted, have used agile methods very successfully in that field, including advanced research into the application of evolutionary algorithms to neural networks in simulated environments. There is nothing wrong with taking two weeks to just think about a problem and tinker with it. Take six weeks. Take six months. But when it is time to start making concrete progress on some kind of a timetable, on somebody's dime, then scrum is a great way to do it. Agile is first and foremost a way to implement software; it is not a way to design it from scratch. The most agile says about design is that it is an incremental and dynamic process that continues during implementation. If your point is that agile doesn't help you much if you don't know yet what you're going to build, I totally agree, and so does sound agile practice. I may indeed just be lucky, but if so then I've been lucky for an extraordinarily long time and in an extraordinarily wide range of contexts. Agile is not right for everything, but for developing software, it's great. Oh. I see. You're just trolling. Not at all. I am utterly sincere. Being able to chunk complex projects into simpler components that can fit into smaller timeframes (yes, as small as two weeks or even two days) is an essential skill for a software developer. And if that consistently thwarts you, then software development will make you very unhappy, whether you use agile development or not.

mlthoughts2018 8y ago
> Being able to chunk complex projects into simpler components that can fit into smaller timeframes... is an essential skill for a software developer. Why do you feel this claim is related to Agile or Scrum in any way? When I see that claim, I agree, and I am reminded of many of the things I like about software. And I do not see how it relates to Agile / Scrum in any way. Back when I used to work on a team that used only Waterfall in a defense research company, we broke up complex problems into smaller components with different timelines and informal status check-ins with other components of the project. When I was a grad student and we had literally no formalized workflow for our lab projects culminating in open source library releases and journal paper submissions, we also broke up our problems and analyzed how to decompose them and think of them modularly. It's a skill of software design that seems to have utterly no relationship to what overarching workflow management process is used. Why do you think they must be logically inseparable?
- vannevar 8y ago
  Why do you feel this claim is related to Agile or Scrum in any way? Because one of your principle complaints about scrum is the regular cadence. You said that it created an artificial breakpoint that frequently could not be lined up with demonstrable code. I pointed out that if you are skilled at breaking complex projects into smaller pieces, it should almost never be a problem to find a piece that fits into a two-week window. And indeed, I've never encountered that problem. The much more common problem is breaking the project into the wrong chunks, with faulty abstractions. But agile doesn't affect that one way or the other. It's a skill of software design that seems to have utterly no relationship to what overarching workflow management process is used. I agree, which is why the cadence is a non-issue in scrum: the aforementioned skill allows a team to virtually always find a set of chunks to fill out an arbitrarily-sized sprint.

mlthoughts2018 8y ago

> Being able to chunk complex projects into simpler components that can fit into smaller timeframes... is an essential skill for a software developer. Why do you feel this claim is related to Agile or Scrum in any way? When I see that claim, I agree, and I am reminded of many of the things I like about software. And I do not see how it relates to Agile / Scrum in any way. Back when I used to work on a team that used only Waterfall in a defense research company, we broke up complex problems into smaller components with different timelines and informal status check-ins with other components of the project. When I was a grad student and we had literally no formalized workflow for our lab projects culminating in open source library releases and journal paper submissions, we also broke up our problems and analyzed how to decompose them and think of them modularly. It's a skill of software design that seems to have utterly no relationship to what overarching workflow management process is used. Why do you think they must be logically inseparable?

vannevar 8y ago
Why do you feel this claim is related to Agile or Scrum in any way? Because one of your principle complaints about scrum is the regular cadence. You said that it created an artificial breakpoint that frequently could not be lined up with demonstrable code. I pointed out that if you are skilled at breaking complex projects into smaller pieces, it should almost never be a problem to find a piece that fits into a two-week window. And indeed, I've never encountered that problem. The much more common problem is breaking the project into the wrong chunks, with faulty abstractions. But agile doesn't affect that one way or the other. It's a skill of software design that seems to have utterly no relationship to what overarching workflow management process is used. I agree, which is why the cadence is a non-issue in scrum: the aforementioned skill allows a team to virtually always find a set of chunks to fill out an arbitrarily-sized sprint.