Good news everyone! My magnum opus on Scrum just dropped, clocking in at almost 9K words! Prepare a drink, strap yourselves in, and enter the Torment Nexus.

https://ludic.mataroa.blog/blog/tossed-salads-and-scrumbled-eggs/

Tossed Salads And Scrumbled Eggs — Ludicity

@ludicity "Instead I believe that Scrum and the assorted mutations that it has acquired simply reflect a broader lack of understanding of the systems that drive knowledge work, and the industry has simply adopted the methodology that slots most neatly into our most widely-held misconceptions."

Dicaprico-pointing.gif

Dysfunctional knowledge work (and lack of "awareness of the meta" about knowledge work) feel like a root cause in so many issues; the whole AI-at-work also.

@Sevoris Hah, I love the idea of there being a meta around knowledge work. That's such an accurate description of why I derive a lot of enjoyment from thinking both about systems in games and systems at work, but I never realized it was the same brain pathway firing.

@ludicity Sometimes it also feels like there‘s a meta about the meta. (That‘s an ilusion - knowledge work is simply recursive. You can knowledge work about knowledge work. It‘s like the distilled formalism of self-awareness.)

But belike, for work, doing knowledge work - why are you doing it? What motivates the questions that need answering? What needs demand knowledge work, and why do the things making these needs exist on the business?

@ludicity Call it the "Feymann check" of the business. Can you explain what you‘re doing at your company to a four-year old? Like, *really* explain it?

We probably don‘t understand why we need to do most of the things we do. And I suspect that feeds into many of the issues that businesses have; it certainly feeds into the current dysfunctions now that places of work think more and more about being data-driven and "communicating better" and stuff.

@ludicity a sardonic closing thought: the reason LLMs seem so appropriate to business is that humans have been chugging along, covering lack of deep understanding with formalisms and seems-right-enough approximations of founded-in-impotence-of-lacking-knowledge bullshit for years and years.
@Sevoris It is comments like this that tempt me to turn comments onto my posts, then I remember what non-Mastodon people are like

@Sevoris I asked someone yesterday if I should codify some norms that had developed in a community. They said I don't need to write the norms down because they're evident in the culture, and I've been sliding down a rabbit hole of "Culture is self-describing". This makes me think of that as well.

Maybe this also illustrates why some people "get it" and some people don't. When I say someone "gets it", I just mean they're in the knowledge work metagame.

@ludicity It‘s probably even stronger than that - people who "get" culture without having it written down, who can grasp the parts and understand them, have, well, understanding of culture.

I can‘t be expressive here because I lack the words and well-formed thoughts, but I feel like many/most/(really all(?)) people struggle with understanding the cultural reference frames they‘re implicitly embedded in. Maybe that‘s just part of the human condition. We do culture naturally

@ludicity @Sevoris

My saying on this is: Culture informs architecture. Architecture reinforces culture.

@ludicity "Software engineers do not like engaging with the business partially because they trend towards being nerds, but mostly because interfacing with true economic reality is confronting."

Facebook-Im-in-this-image-and-don‘t-like-it.png

@Sevoris The day I did the maths and realized I need to bill clients for about $1.2M in 2025 to barely adequately compensate my team of a measly six people, my third business eye opened, and there was a great wailing and gnashing of teeth

@ludicity @Sevoris

> I need to bill clients for about $1.2M in 2025 to barely adequately compensate my team of a measly six people

I have wanted to switch from regular employment to software consulting, but concerns like this are the terror that stop me.

@ludicity This was a great blog! Your ascendency to thought leadership is going well! Though…

"This frequently boils down to professional responsibility cosplayers hoping that by repeating the phrase "break down silos" every day, they will be able to network every employee at the company into one gigantic Borg cube, somehow achieving all the upsides of specialization and none of the downsides."

Please don‘t give Musk et al. ideas about cybernetic corporate symbiosis.

@ludicity OH WONDERFUL, I HAD PLANS FOR THE WEEK-END, AND NOW I HAVE ONE MORE HATRED-FUELED LONG-READ TO READ. But honestly you make me laugh so much, it will be a pleasure
@ludicity I love the segues into chapter titles.

@ludicity One problem is that Scrum is often treated as if it were a software development methodology, not a project management methodology: category error. So all the metrics (burn down charts etc) and rituals are a burden placed on developers, who do not benefit, to serve the needs of project managers, who (in your account) do not even exist. What could possibly go wrong?

BTW you probably read this, right?

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

Why “Agile” and especially Scrum are terrible

Note: My first novel, Farisa’s Crossing, will be released in spring 2022. Agility is a good thing, no doubt, and the Agile Manifesto isn’t unreasonable. Compared to a straw-man practice…

Michael O. Church
@hengymrohebwlad No, I hadn't! This is a strange coincidence, as I just made Michael's acquaintance yesterday and was unaware of this.
@ludicity Everyone gets hung up on story points. Estimating is famously hard, mostly because of unexpected events or hidden complexity. So using SPs as a complexity measure is literally pointless, because you still don't know what's hidden in there, and SPs are just a proxy for time anyway (managers want to know when you'll be finished, not how complex the task is). So just guess how long it'll take. It won't be any more accurate but it saves time on planning poker and all that bullshit.

@ludicity

Enjoyed that thank you!

Reading it reminded me of the book "How Big Things Get Done", by Bent Flyvbjerg and Dan Gardner, which I was reading the other week & think is v good.

I can't remember now who recommended that book, so maybe it was you in the first place :-) But if it wasn't & you haven't already read it, I recommend it!

@unchartedworlds It was not me but that sounds like good recommendation, thank you! I think a lot about the emails I get from the handful of readers that have worked with NASA, because that's certainly a project where "sticky notes on whiteboard" is a total non-start. But that's also a relatively rare case, and it's weird that every project seems to be run like the subject matter is that intense.

@ludicity

Well the "big" in the book title is relative - one of the examples is a kitchen renovation. In a way, its theme is how humans get tempted into plans that aren't gonna go like they imagined, and how to avoid the usual pitfalls.

Oh and a succinct little quote from the book which made me laugh - "Average practice is a disaster, best practice an outlier" :-)

@unchartedworlds @ludicity Seconded. It’s a really good well researched book, and an easy read.
@ludicity Agile 2.0 is a parody, right?
@tombs It isn't. I will say that most of the stuff on their website seems like it aims towards nuance and reality, but also why would you call it Agile 2.0? 💀
@ludicity Excellent. Covers my many bugbears with Scrum. One issue I have is “user stories” being the main unit of work passed to devs to complete in a sprint. They are often not granular enough or sufficiently well understood to turn into working software in 14 days. It also skips from “want thing” to “code thing” without “design thing”. It also assumes all devs are fungible and can understand the story. Thus the horror of Emergent Design, which is apparently a Good Thing.

@ludicity

This takes apart user stories and sprints in detail. If I was in any way decent at prose, it’s pretty much what I would have written, as it echos my experience. I’m so very tempted to call my next business “Cascade Software” or similar, just wind up Agile consultants.

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

Why “Agile” and especially Scrum are terrible

Note: My first novel, Farisa’s Crossing, will be released in spring 2022. Agility is a good thing, no doubt, and the Agile Manifesto isn’t unreasonable. Compared to a straw-man practice…

Michael O. Church
@bjn I mentioned to someone else that Michael reached out to me yesterday! Funny coincidence, as I didn't realize he had written on this.
@ludicity ha fixed price with no deadline is the meta
@imclaren It really does seem superior in every context where it's not literally impossible. I met some folks from Black Magic who explained that they have deadlines in the form of conferences where they compete with other camera producers, so stuff like that probably makes "no deadline" unworkable.

@ludicity @imclaren I'm really curious about your take on fixed prices, particularly how to agree on a definition of done (yay, another neologism!), and how to plan for those cases where estimates explode.

When I first started as an independent consultant, I sold a small fixed price project that ended up taking 10x the expected time. I guess you could call me a 10x developer, but my compensation ended up well below minimum wage. That was an expensive lesson.

@joelving it may sound simplistic but I think that clear deliverables and assumptions are key.

For example, x product, with y features, 1 follow up meeting with the client to respond to questions and comments, then 1 further iteration of the deliverable. And/or time box the fixed price engagement.

Anything more is a scope change. The goal is clear expectations and no surprises for the client.

@imclaren definitely, fencing in you known unknowns will save you a lot of grief. My primary concern is the unknown unknowns, which our business tend to have aplenty.

@joelving @imclaren We don't charge based on "expected time". What we're trying to do is completely stop thinking about time to completion. We try figure out how much value the project has to the business and charge 10-20% of that.

This means we don't sell things that don't have clear revenue/cost implications.

It also means that we're expecting to sometimes charge rates that are eye-wateringly high, and we're banking on people not caring because it's still a clear win for them.

@ludicity @joelving yes I also think that this may be the way as long as this number is always >= (your internal target FTE equivalent cost per hour to complete the project + your other costs) * a reasonable margin. So you don’t starve.

I think that the closer you are to this number (at the low end) the more rigorous you will need to be in calculating this number and/or building in assumptions.

@imclaren @joelving Totally. We have a lower bound based on time, but not an upper bound. But since we're expecting non-linearity in value, I think it would be concerning if we ever work close to the lower bound.

It has also had a really positive effect on client conversations, as we really push them towards formulating a version of the project that has really, really high expected value.

@ludicity @imclaren that makes so much sense. I know a pricing expert who will price his talks simply by asking "what's your budget?" and it works very well for him. This is kinda the same, asking "what's it worth to you?", and I really like it. Of course, the trick then is to find those really great business cases.

@joelving @imclaren Keeping in mind that I'm new at this, "what's your budget?" is better than guessing but is inherently adversarial with anyone that's remotely savvy.

My intuition is that there's a huge difference between "What can you afford?" and "What is it worth?", or even "Can we come up with something worth more?"

@ludicity @imclaren for sure, that's always a risk, and the strategy only really works if you can afford to walk away.

I imagine you have to spend some time establishing reliable metrics in order to quantify the value realized? Or are you relying on the customers assessment?

@ludicity @imclaren I realize you probably don't have a lot of data yet, so maybe it can't really be answered. I'll eagerly await the "status after 1 year" blog post. 😊

@joelving @imclaren For now it's the client's assessment.

And from a more psychological perspective, we keep it simple. I.e, 50% chance of failure loses 10K, 50% chance of failure gains 100K, that's still a bad pitch.

Taleb writes a lot about how losses are felt more acutely, so positive E(V) plays are still bad for sales, rather than lower E(V) sales with higher success rates.

Secondly, failing is bad for client relations! 😢 Most people don't feel like they can inhabit hypothetical outcomes.

@ludicity @imclaren for sure, building momentum with small successes is absolutely a sound strategy.

It's super interesting! I really hope it works out great for you!

@ludicity @joelving hmm what’s your budget could be seen as the equivalent of asking a potential new employee what they are currently paid.

It’s asking them to negotiate against themselves. It can work, but in my view people usually ultimately figure out when they have been played. That’s not how I would want to be treated as a customer.

@imclaren @ludicity hmm, I actually see it the opposite way, because the power relationship is inverted. I think it's more like the prospective employee asking for the salary range, which is just fine. The client can always go elsewhere.

But I can't speak to it's results in practice. I only have it from him and it seems to work for him. Of course, it might also be because his product - public speaking - is a very different product from software development.

@joelving @ludicity it’s a good point. And Nik is a data scientist so the sales process methodology may be similar.

@ludicity once again you have taken everything I wanted to say on the subject and written it up lucidly :)

I think the core problem in software project management is that development time estimates are incredibly difficult to get right, and non-technical managers refuse to accept this fact. It's that refusal that causes most of the problems.

Your take on the Basecamp stuff is interesting, I'll check it out more. Thanks :)

@GentlemanTech I still can't tell how much Basecamp stuff is pure kool-aid but the stuff that I've tried has worked
@ludicity I'll let you know my thoughts once I've read it :)
@ludicity that was .. sobering.
@ocramz How great is the Jeff Sutherland bit on AI though
@ludicity this better be good.
@happykhan I'm scared

@ludicity its ok.

it reads better if you cut the text before Section II .

This mindset has infected everything - even in research in academia where i am, so i dont think it's strictly scrum - the original idea was ok (id say simplistic but still ok).

The key issue for me is the push pull between management's anxiety and the reality of how much hard work it takes to actually DO ANYTHING.

@ludicity Management these days lack any technical skill so they cant help or even understand. scrum provides nice security blanket that things are moving -- even though they aren't.

In scrum, Is there any serious review of the accuracy of time estimates given ? (est vs actual)? I've never seen this discussed.

I've been in nonscrumed work environments and all this rings through. I've been in the "Secure Personally Identifiable Data" meeting but i dont rember seeing you.

@happykhan I gave it some thought and you're right that it's better without the preceding sections. Not sure if I'll actually delete them though for various boring reasons.

On accuracy reviews, I'm reminded of my minor thesis. The thing I tried had great results, and my supervisor allowed me to not bother with a p-value because the Number Was Big.

Most businesses are so inefficient that we don't need serious reviews, we can just use our eyes and say "Yes, this is very dumb".

@ludicity I had a good laugh/cry reading this. Reminds me of the team I joined towards the end of COVID. Nearly all team members were new like me and had no idea what was going on. The people who had been there longer were quiet personalities. The Scrum Master (Lord is definitely better) was a lovely guy who had weeks of stand-ups where barely anyone said a word. Finally one day he decided to break the impasse and called on me to say something. I freaked out, blubbered something and took the rest of the day to recover from anxiety.

Fast forward, our lovely Scrum Master moved into data analysis - I think our team helped his sensitive soul see the ugly reality of the cult. Our managers changed our work practices to Shape Up. People are happier, but estimating time in advance to complete projects is still a problem and we still have retros.

@ludicity
> I like the principles enough that our consultancy is current leaning heavily towards adopting Extreme Programming practices.

Yes! Joooiiinnn uuusssss

@jacques I do love that I have one reply that goes "YESSS, XP" and another that goes "You are about to enter a world of cutesy nonsense".

(But we take a lot of pointers from Jesse Alford and Nat Bennett so we're probably going the cutesy nonsense route no matter what anyone says.)

@ludicity I’ve seen the promised land. It was real. Best. Cult. Ever.
@jacques @ludicity We now have four former Pivots on our team, the latest being our PM who now facilitates standup. I could see at the end of our last how desperately he wanted to clap 😂