6 ms·
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
by patothon 4y ago
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
- deleted 4y ago[deleted]
- siva7 4y agoSo 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 4y agoHonestly, 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.
- TylerE 4y agoWonder if any incidental successes can be blamed on throwing out the backlog and figuring out what’s actually a priority
- patothon 4y agothis is one way
- jdlshore 4y agoSpeaking 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 4y agoI'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.
- IOT_Apprentice 4y agoHow 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 4y agoyou 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.
- patothon 4y agothey 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
- _009 4y agoBack 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 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 4y ago>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.