It’s time to embrace slow productivity (2022)

Usually the individuals doing the work do understand that, but it is really hard to properly divide work and describe requirements. Why people try do divide it in even smaller tasks which increases this kind of complicated creative-writing work is beyond me.

> We realised that waterfalls that start with months of requirements capture followed by months of BDUF aren’t a great idea.

What we should have realized by now is that we never did waterfall right because it's inventor Winston Royce required it to be done TWICE for each project. Two iterations.

What this world needs is Atlassian hiring a number of work psychologists and theorists and have them streamline JIRA based on their learnings. Not in a UX "I want to create a story"-story sort of way. But in a "How do I deal with 50 tickets that are vastly different in quality?" sort of way.

They should answer questions like: "How can we make it so that the user always immediately knows whether to put this text in JIRA or confluence"?

Then Microsoft needs to hire the same people and improve text creation in outlook.

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.

I can basically be a dead drone for ~60% of the week so that I'm recovering in the other 40%?

"The 4 day work week" means "working 32 hours per week (as opposed to 40) with no cut in pay"[0], not "cramming the 5 day work week into 4 days".

0: https://www.latimes.com/california/story/2022-04-08/proposed...

For the rest of us “slow is smooth” means you should work on something that is analogous to the most important functionality first, to build your ability to do that work. Then as you gain skill, tackle harder and harder problems.

Sometimes the rule of three lets you go back and fix so,e of that early poor ordering, but that doesn’t always trigger at all and sometimes triggers when you still don’t know what you’re doing. And then everything you do later is hampered by getting things wrong up front.