[patothon]

I don't understand why we're still talking about SCRUM.

People saying they're using SCRUM (by this I mean "literally saying 'SCRUM'") are a dying breed and if they're not then they're cargo culting and I'm not sure why this is more of a big news than management cargo culting waterfall or kanban.

I used to be one of these process experts selling methodologies to whoever was ready to pay, from SCRUM to lean startup.

After doing this full time for 2 years the only conclusion is that none of these processes hold long enough. Why?

1/ every product / team / output is different. some teams should be ticket driven, other exploratory driven, and each of these methodologies apply to one situation only 2/ high turnover in the industry. meaning that new people come and organically change the new flavor of the day, the dynamic of the teams and the throughput of the team 3/ all of the best teams I've worked in the industry (from seed stage to FAANG through late stage startups, and even F50 companies), just do WHATEVER that works for them and don't comply with the flavor of the day (except for the looks of it). They all use a shared core set of values (deserves it's own blog post), and you can find this core set of values in most agile methodologies, buried behind ritualistic behaviors

anyway. I could go on.

Just let it go, and if you're working in one of these last companies applying SCRUM unironically, you're probably not in a high performing team. Time to move

[_009]

Back in 2005, I remember working on startups running on Scrum principles. It worked well at the time, we where able to ship, grow the team, and move forward with a nice few-features-per-week cadence, working remotely, on a small team; less than 10. Tt always worked fine, but very centralized and slow, as all-things-dev were at the time.

I worked with ActiveColab in 2007, Skype 2007, Yammer 2009, Trello 2011, Pivotal Tracker 2013, Trello 2016, Confluence 2022, Slack 2013, Google Meet, and sometimes I think, scrum became _less-relevant_ over the years as more advanced product management tools became the norm and the product manager role matured by leveraging them.

These days, it's not rare to see lead developers manage kanban-like boards very effectively, releasing on time, with grace, without the need of a scrum master to coordinate efforts.

I do like asynchronous scrum daily standups using http://geekbot.com on slack, when on-site or/and distributed and doing sprints. I seen this work well on startups going from pre-seed to series B.

Personally, I am fascinated with team dynamics and how they've changed over the years. We are definitely living the best of times as a developer and I still see sparkles of well-applied scrum every now and then that works nicely.

[vannevar]

>These days, it's not rare to see lead developers manage kanban-like boards very effectively, releasing on time, with grace, without the need of a scrum master to coordinate efforts.

Sadly, it's also common to see such kanban teams endlessly winging it and slowly losing sight of what they were trying to accomplish, at the same time burning out their teams on an endless stream of tickets and testing without ever taking time to reflect and course correct on their goals.

[mhss]

It's almost as if the process was not the most (not even close) important thing to ship value consistently.

[vannevar]

True. But given a team of average ability, good process (ie, good habits and conventions) can definitely mean the difference between success and failure.

[mhss]

I'm sorry if I'm splitting hairs a bit here, but I'd argue 'good enough' process is all you need even with average teams. Keep them focused, limit their in flight work, unblock them, iterations with feedback, etc; I just feel some people spend inordinate amounts of time trying to optimize process when process hits diminishing returns pretty quickly.

[vannevar]

>I'd argue 'good enough' process is all you need even with average teams.

That's sort of a tautology, right? If it's 'good enough', that implies it's a good process. In my experience, Scrum is a good enough process, with very little wasted overhead. It keeps the team focused, limits their in-flight work, unblocks them and offers regular iterations with feedback.

I'd agree that over-optimization is sometimes a problem, but when something as simple as scrum fails, it's usually down to the basics, like poor meeting practices, or micromanagement, or something outside of the development process entirely, like badly underbidding the project. No amount of process will save a project that was doomed from the start due to poor budgeting of time or money.

[siva7]

So you sold methodologies to companies as a process expert and none of them ever hold up? Maybe you reached the wrong conclusion after all.

[scott_w]

Honestly, this isn’t surprising. Typically external process change struggles to take root because the person isn’t there long enough to really understand the team, the problems, the culture, etc.

I don’t think this is the consultant’s fault, either. Usually the company doesn’t want to pay the money or time to do this.

[jdlshore]

Speaking as a consultant who's work does hold up, part of the job of a consultant is to make sure clients are aware of what's needed to succeed, and to turn down work that won't succeed. No matter how tempting the fee may be.

(I realize that many of my colleagues don't do this. Fie, I say. Fie!)

[patothon]

I'm not sure why you think I've done a bad job implementing these methodologies.

I've actually done a GREAT job. These teams shipped.

But I realized that they didn't ship because of the actual methodologies but the core set of values we implemented as a team.

ergo, these methodologies are a sham.

[jdlshore]

My statement wasn't actually directed at you—I don't know you! Sorry it sounded like a criticism.

I was responding to @scott_w saying that process change not taking root isn't the consultant's fault, because companies don't want to pay for good process change. I disagree: I think it's the consultants job to be clear about what's needed to succeed, and not work for companies that don't want to pay for good work.

Regarding methodologies, I agree that successful teams internalize the principles behind their methods and leave the by-the-book methodologies behind. I think you're being overly cynical, though. Beginners need a concrete place to start. It's like saying cookbooks are a sham because expert chefs don't need them.

[scott_w]

I didn’t specifically apportion blame. I just said I don’t blame the consultant in the case where it doesn’t succeed due to lack of investment. Yes, you can say consultants should enforce that but many don’t. I can’t say I blame them when they need to pay the bills and there’s a paying customer.

[patothon]

fair point about needing the beginners for a place to start.

The turnover issue we're seeing in the industry definitely doesn't help with seniors leading the way. which ends up being a problem top to bottom

[IOT_Apprentice]

How would you have established the core set of values otherwise? Sometimes teams click, & sometimes an egomaniac inside a team can destroy the product—and end the team. I’ve seen it.

What agile/scrum was supposed to do was kill waterfall, and provide more transparency in how a project it product was actually proceeding with demonstrations of execution or lack thereof.

[Centigonal]

you should write that blog post about that core set of values. I think a lot of people have trouble recognizing success when it's not tied to a named concept, brand, or methodology.

[TylerE]

Wonder if any incidental successes can be blamed on throwing out the backlog and figuring out what’s actually a priority

[patothon]

this is one way

[patothon]

they do hold up for a while. but it's all ritualistic BS that is not needed. and to be clear, the teams WERE shipping. And were successful. But also quickly abandonned these methodologies in favor of some core values we implemented as a team. I don't think it's very graceful of you to assume my job was just a failure.

What I'm saying is that I was cargo culting too, because I personally believed in these methodologies.

But I realized after seeing many situations, that success is not linked to the usage of these methodologies