I think we'll try out that #NoEstimates racket we've heard so much about in the Agile echo chamber. I understand that we slice the shit out of User Stories until they are so small, they are effectively normalized. What a great idea - shift the burden of effort to Product Owners to create tiny "INVEST" grade Stories. Hell, their job is a cake walk anyways; how hard can it be to drive convergence of vision with the many cooks in the kitchen driving business strategy? Why should we have to give any attention to /their/ User Stories until they are so small, we can bang it out in an hour? If anyone calls them out as a new bottleneck, or claim it is bordering on Big-Requirements-Up-Front (BRUF), they obviously haven't heard that User Stories are by definition "Being Agile". Who cares about seeing the forest for the trees, or identifying cohesion, or the runway needed to stand up our fancy new machine learning AI or pub-sub messaging infrastructure or any intentional architecture / reasoning about high-stakes decisions in advance - it's emergence everywhere baby! Oh yeah, and that thing for "respect for people"; this should cement that value for at least us Developers - not sure whether #investors will feel the love though; oh well. What an ingenious idea (I am sure some methodologist's from Finland, Australia and the US have made a killing with this one, or at the very least their books are in the works). Instead of "estimating" relative size, which is effectively "data binning" from Digital Signal Processing (DSP), and possibly effort hours as they fan out to cross-functional team skill-sets, "decompose" until estimation is moot. Hell, all our people have exactly the same knowledge and skill-sets; they are basically clones, although we won't get into how pricey they are though :o) Really, who cares how long that splitting process will take for a $450 Million dollar investment. We have more than enough funding to sustain our $2M per week burn rate. Everything is one conversational development session between exactly one customer/product owner and one generalist jack-of-all-trades developer; and in the words of Goldilocks, once the User Story is just right.
Which leads me to think we should also try out that shiny new #NoStories movement. You know, the one that states that because User Stories are so small, it is wasteful to write them down in the first place; instead, let's write tests. They are far more actionable as they can be executed; way better than a simple textual convention of "As a ... I want a ... so that ... given ... when ... then". I think I heard that the inventors professed that approach as a set of training wheels. I always felt those were cute and a little bit sketchy, probably just another round of beating up on Ivar Jacobson's Use Case semantics anyways.
Unfortunately, now "the Business" wants to try out #NoDevelopers because there are #NoStories to persist domain knowledge. The thinking behind this newest trade unionist guild is that because developers are not so knowledgeable about the domain in question, and we do not want to pay them to learn about complex domains on our nickel, we don't need such a title. Just business Team Members. Product Owners with all the domain knowledge can code all their own software directly from their own brain, extracting tacit knowledge in real time, thus not requiring the need for cognitive offloading into explicit knowledge using either User Story or Test Case documentation mechanisms.
Oh crap, now our executives want us to try out the concepts from the #NoPay #NoIT meme. Because we practice #NoEstimates for #NoStories with #NoDevelopers, we also do not estimate when developers will get paid. This is because we make our development sessions so small that it would be wasteful to attempt to forecast when our business will actually get value from the software created in the field. Obviously, the enterprise Fiduciaries cannot make investments when they do not know when they will actually get a return on these investments. Heck, we do not even know if we actually need IT developers because our Product Owners develop this crap themselves, know what good looks like because they are in sync with the disruptive market forces at work, and only get paid when they sell their product anyways.
This is how circular, argumentative, logical fallacies of trade unionist/socialist viruses start, perhaps from those who have some sort of axe to grind, are afflicted by confirmatory bias, or have a profit motive agenda. This is also how divisive, allergic reactions in modern software development practice transformations start. It is a common yet very destructive self indulgence which can lead us to a place where empathy for technical complexity is eroded and respect for true engineering goes by the wayside. Zealots in our industry, who likely have a huge conflict-of-interest, need to come back down to earth, get real, get over their dogma, and stop spreading this bullshit.