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/
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/
@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.
@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.
@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 "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
@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 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/
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!
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" :-)
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/
@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.
@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.
@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?"
@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 @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.
@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 :)
@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.)