>breaking creative work down into bite-sized chunks In my decades of experience in multiple companies doing 'agile', that's something that we've always ostensi

>breaking creative work down into bite-sized chunks In my decades of experience in multiple companies doing 'agile', that's something that we've always ostensibly strived for, but in practice it almost never happens in reality. At least not as intended. Occasionally it happens, but only by pure chance. It seems the 'agile way' is to attempt to manage a project by taking a sizable but coherent and cohesive concept/feature/requirement/design/plan, shatter it into a thousand incohesive random fragments of varying sizes (all estimated to be bite-sized, but true size unknown until they're actually done). Then everybody grabs a few fragments and works on them, placing them somewhere more-or-less where they're hopefully supposed to be, hoping that in the end everything will come together somewhat similar to the picture on the box. Then everybody has to try to duct-tape and glue them all back together again on a herky-jerky schedule, like doing a puzzle with constant interruptions and distractions for the agile rituals. The results aren't necessarily worse than waterfall/BDUF, but not necessarily better either. There is in truth a lot more potential to course-correct along the way. But since everyone's spastically going different distances in different directions at different speeds on as-yet-unconnected fragments of varying sizes, and no one can see the big picture, that theoretical course correction en-route is not nearly as powerful as it sounds. I've seen some debates about shorter vs. longer sprints. The die-hard agile people tend to push for the shortest sprints possible or even shorter, leaving no time whatsoever to clarify requirements, work out integrations, or do any QA/testing. No time for thought at all, just spit out some code, any code, as fast as possible and then it's review/demo/retro time. The veterans push for longer sprints, with time to understand and coordinate, experiment and test. But that gets a lot of pushback for not being agile enough, so we usually end up somewhere in the middle. And a lot of things don't fit neatly into that timeframe. Which in my opinion is not the worst thing, but also nowhere near as efficient or as effective as it could be if things were not broken into bite-sized chunks with arbitrary deadlines, but instead developed as parts of a cohesive whole. Whether from the foundation up (risky) or by building vertical segments and linking them together. "Move fast and break things" indeed. That's the state of the art - breaking things as fast as possible. We could do better.