I arrived in Seattle yesterday, staying in Ballard. Wow, it's bad here. Worse than it used to be pre-pandemic.
39 karma · joined December 31, 2018
I can't help but feel that people say Kanban because Scrum is so uncool. You can see that from the roasting Scrum's getting here. With these visceral reactions, I can see why people are cautious about saying they do Scrum.
As for Kanban, most teams are no more doing Kanban than they are Scrum. That is, they're probably just following Jira's process. I've asked candidates in interviews what they mean by Kanban (e.g. if mentioned on their CV) and the common answer is, "the process we use in Jira".
> Nonsense
You may think Scrum is dogma, but my statements are factually true by reasonable definitions of the terms.
>Why would you continue to follow a process you don't find value in? If you didn't like a process, why would you feel like bringing that process up in a process-oriented equally-useless meeting? This is the dogmatism. "Well even though the meeting wasn't valuable you still should've tried". To what end?
Strawman.
I'm afraid you'll have to take my word for it that the team where just bad at it. They got better with coaching and even managed to see some value.
The values behind the process are more important. This team just weren't talking to each other about their own performance.
> throughput/attrition
Of staff or customers? Attrition is very low of both. Not sure it's that relevant though. 3 engineers have left in the last 2 years and one of those three is returning. Is that a good thing?
As for throughput, even the slowest of teams ship on a daily basis. Not sure what other context you could mean.
It's like baking a cake without adding sugar; it's not really a cake anymore.
Sometimes teams don't understand practices and will discard them.
As an example - retrospectives. I've worked on teams where we inspected and adapted our process on demand. We didn't wait till the end of a sprint.
I've managed individuals on teams where they're discarded retrospectives. They've complained to me about certain processes (not scrum ones) and when I've asked, "why didn't you raise this in the retrospective?". "We stopped them, we didn't see any value".
No doubt they weren't getting value out of them, but that doesn't mean they were doing things well and they lost opportunity to improve as a group.
For context, currently, I manage a team of 60ish without Scrum. I see Scrum as a bit dated now.
Dive straight into debunking #noestimates but don't get to the fact that no one ever really knows what they want.
I know what I'm doing tomorrow if I can afford to wait for a delivery. What will I be doing on a random day next week? next month? Less so!
I hate it when I promote a team lead, and they change what they've been doing. I promoted because they were already doing the job.
> How to explain a technical concept behind closed doors to a senior person too embarrassed to openly admit that they don’t understand it
Aren't these a bit condescending? Sure they're directed up, but it sounds "be nice when you're looking down on them".
But worse, what if, as an engineer, you've just got a blindspot? What if the manager (or any person for that matter) has a brilliant idea that _you_ don't understand and therefore think it's stupid?
My experiences with senior engineers is that they often need to learn to keep their biases in check.
The reason for fatigue is not because of downvotes, but because it is no longer "fun". It's done. There is nothing left to add unless you want to jump on new technologies.
Coding: on a whiteboard or with someone watching over you has no correlation with performance on the job.
Data structures: questions usually end up so contrite that they have no bearing to real-world situations. That or based on luck of seeing an remembering the right one. Data structures usually go hand in hand with algorithms.
Algorithms: questions become more like trivia or reinventing something that has likely got research papers on it. Oh, you want me to invent an algorithm I've never heard of on a whiteboard with your clues?
System design and data modelling: the kind of thing you can do in an interview lacks real-world data. No empiricism. It's all about the trade-offs.
Tailoring to the candidate introduces inconsistency and unfairness/luck.
What if these "seniors" and "architects" are frauds?! How else could they hold down a job for 20 years and not be able to answer my questions? They must be really bad!
Lucky my interview process is really great and I always hire the good ones. I track every rejection and I have proof that they never amount to anything!