3 ms·

> 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 y

by 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.

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.