I've long worked at companies that have tried this small-task, assembly-line approach, and though in some circumstances it does get the job done, I've never really felt it to be particularly satisfactory, nor does it reflect the reality of how software actually gets built.
Recently I've been pushing a much more "holistic" approach, where we empower developers to own a particular area of the product, or a particular feature, and to be responsible for delivering it. How exactly they achieve that is largely left up to them, but the reframing of the task from "build this thing" to "make sure this thing gets delivered" has been so far successful. Developers are free to review requirements, pose questions, identify risks and break down the work as they see fit. If the task is large, then maybe that just gets raised and we can make decisions based off that, but by and large, trusting people to make the appropriate calls has worked out well, and the sense of investment and satisfaction does seem to have skyrocketed (though it's not like I have any hard numbers proving that!).
The only real hard production-level requirement is to either get it done in x number of weeks, or, if they don't believe that's possible, to give some idea of what *is* possible in that time, as early as possible.
Overall, good communication is the key. As long as people keep talking, moving things forward and raising any alarms as they're identified, things have gone well. It's been a very welcome break from top-down lists of tasks, in my view!
It's funny how all the individual parts of the assembly line approach sounds logical with solid arguments for it. I've struggled arguing against it in the past because I was arguing against it piecemeal.
The primary issue is that the whole process most software orgs use is fundamentally broken for all the reasons listed. Giving teams agency to make decisions always results in better software delivered quicker.
Agreed - arguing against it as a whole is very difficult when it's baked in to the culture and tons of metrics etc are based off the back that approach - but it's always just "felt" wrong to me in a way that's difficult to articulate. I think fundamentally the biggest factor for me is that I find software development to be largely a creative process, and it can't always easily be condensed into atomic tasks for people to implement. Giving developers the freedom to flex their thinking and arrive at a solution naturally just feels like a much better fit.
I've long worked at companies that have tried this small-task, assembly-line approach, and though in some circumstances it does get the job done, I've never really felt it to be particularly satisfactory, nor does it reflect the reality of how software actually gets built.
Recently I've been pushing a much more "holistic" approach, where we empower developers to own a particular area of the product, or a particular feature, and to be responsible for delivering it. How exactly they achieve that is largely left up to them, but the reframing of the task from "build this thing" to "make sure this thing gets delivered" has been so far successful. Developers are free to review requirements, pose questions, identify risks and break down the work as they see fit. If the task is large, then maybe that just gets raised and we can make decisions based off that, but by and large, trusting people to make the appropriate calls has worked out well, and the sense of investment and satisfaction does seem to have skyrocketed (though it's not like I have any hard numbers proving that!).
The only real hard production-level requirement is to either get it done in x number of weeks, or, if they don't believe that's possible, to give some idea of what *is* possible in that time, as early as possible.
Overall, good communication is the key. As long as people keep talking, moving things forward and raising any alarms as they're identified, things have gone well. It's been a very welcome break from top-down lists of tasks, in my view!
It's funny how all the individual parts of the assembly line approach sounds logical with solid arguments for it. I've struggled arguing against it in the past because I was arguing against it piecemeal.
The primary issue is that the whole process most software orgs use is fundamentally broken for all the reasons listed. Giving teams agency to make decisions always results in better software delivered quicker.
Agreed - arguing against it as a whole is very difficult when it's baked in to the culture and tons of metrics etc are based off the back that approach - but it's always just "felt" wrong to me in a way that's difficult to articulate. I think fundamentally the biggest factor for me is that I find software development to be largely a creative process, and it can't always easily be condensed into atomic tasks for people to implement. Giving developers the freedom to flex their thinking and arrive at a solution naturally just feels like a much better fit.