Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
I am so sorry to everybody here who never saw the real agile. All you ever saw was fake / wasabi scrum. The little side gig scrum with the tickets and the sprints and a scrum master without any power to change a company is a frustrating distraction for everybody.
As soon as the team makes their own decisions and the bosses in every level actually help them on this, they can become agile and the framework just a communication theme.
Everyone talking about agile development unironically must be scrummed in the face, I'm sorry but it's the rule
I don't know man. For the past 6 months we went with approach "Fuck scrum, let's just work". It didn't go well. We were really disorganized, everyone going their own direction, things being overlooked, ...
When a new colleague joined recently, he suggested taking more structured (scrum-like) approach. Things improved immediately.
Like I don't know how you want to call it - scrum, kanban, whatever, I don't care. But you need some structure in your team and you need some meetings where you talk about status, about looking back at things, about plans for next weeks, ...
My understanding is that Scrum is a tool box. You figure out what tools fit for your team. The problem arises when people are in charge that don't understand the what the team is doing or the toolset provided by Scrum. They then try to use every tool and it goes poorly.
My only requirement for team processes is that they be mostly up to the team. Absolutely some type of structure is needed. If something isn't working for the team, they need to have agency to address that, whether it means adding, removing, or changing something.
Well, yeah, that's what Scrum is. From the guide which takes maybe 10 minutes to read
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
That's not a throwaway sentence - it is fundamental to how scrum works and that is reinforced throughout the scrum guide.
Every conversation about Agile and/or Scrum being "the worst", after some prodding it turns out that their company has refused to read or implement one or several of the fundamental principles, often without even being aware that was an essential requirement. You're baking a cake and you decided to not use any butter, that's on you champ, don't blame the fucking recipe.
The biggest valid criticism of scrum is that the thing that makes it so great - its structural empowerment of individual teams - is also what makes it structurally incompatible with any traditional top-down management style. The company must fundamentally be (re-)organized to have a flat corporate structure within its R&D department - most are simply incapable of mustering the necessary changes, if only because too many middle managers' jobs are at stake. So they call their middle managers "POs" or "Scrum Masters" and wonder why their version of Scrum sucks.
their company has refused to read or implement one or several of the fundamental principles
The companies I worked for just kept doing shit the same way they always had but renamed everything with terms borrowed from agile.
I reached for the up button about five times reading this. I absolutely 100% agree. Agile, and all of it's little branches, were created by self managing teams. Each team did it differently so named what they were doing differently, we got XP, scrum, kanban, etc. Spoiler alert: it wasn't the specific flavour that led to success, it was the diverse, empowered, self managing team of mature, talented people. Get yourself a team like that and the rest will care of itself.
My favorite approach to team processes was to work entirely alone and do everything by myself.
I can get behind that sentiment.
a true team player. prob mvp too.
This is what’s most important. Allow for experimentation!
What works well for one team might not work well for your team. What worked well for your team 1 year ago might no longer be what you need now.
My team has moved to a thing we call "ScrumBan" and it's worked pretty well. There still are 15-min Dailies, and a Review and a Retrospective each Sprint, but we cut almost all meetings that are about sitting around and "planning" tasks (aka awful 7-hour meetings where everyone just zones out and guesses random story point numbers). Instead, tasks are planned and moved to the board on demand and never in the presence of the entire team. It gives everyone so much more time to just focus on their work.
That’s scrum. One of the defining features of scrum is timeboxing meetings. Daily standups are 15 minutes. A two week review should be two hours. Ditto for retrospectives and sprint planning.
A seven hour meeting means the scrum master wasn’t doing their job.
At my last job I had to endure 2-hour daily standups involving 120 people. Yes, I know that that's as far from actual agile as you can possibly get -- we still called it "agile".
story point numbers
how many different ways can I say "I simply don't know yet?"
well give us a guess
could be one point... could be 50? I DON'T KNOW
well yeah but give it a guess anyway
Most teams I've been in would do a time boxed task (sometimes referred to as a spike) in those cases. Basically, you get a task with maybe 3 or 5 story points, and the goal is to either complete it or find out what it takes to do so. Then you make follow-up tasks for the next sprint. It's worked pretty well for me in those cases with a lot of uncertainty.
that does seem like a better method of working through the "I JUST DON'T FUCKING KNOW YET"s
Yeah thats tough. I hate when they do that. The beauty is, it doesnt matter. Usually I just drop a mid number and agile seems to give the flexibility to change that as you identify the true scope of work. Do what you can in the sprint, but eventually update the points to match or break it up and adjust points best you can at that point. Given I haven't been doing agile long, so I could be missunderstanding how it should work.
I love working on the edge of exploration, but also recognize it's going to be a lot of dipping the toes in and seeing what the water is like before I can reliably predict these things. I'm fortunate that no one on my team does what I do, so, sometimes they just accept "will report back next week with an estimate based on actual research".
also not getting ambushed with large hypotheticals beyond our actual tool chain support help but
I worked with my team and we naturally evolved to a Scrum-lite. Or what scrum consultants might derogatorily call scrum-but. We do sprints, the team plans their own work, we do not do the daily standup since no one wanted it. Just having time blocked focused work has made us very productive without burnout. If your manager locks in too Mich on by the book scrum it becomes a pointless waste of time and ceremony.
My job has a "scrum master". She's nice, I guess, but as far as I can tell her entire job is sharing her screen so we can look at tickets. Then people tell her what to click on and what text to change. It's excruciating because it would just be faster for the person talking to change it, instead of being like "remove the second bullet point. No, not that one"
On top of that they have all these tasks for "unit testing" but they don't actually do unit testing. Someone just said, in the distant past, we should do testing so it's there.
This is just like PMs where I work. They are generic PMs with no background in the work we do, so they end up being spreadsheet updaters and meeting schedulers (which literally everyone can easily do themselves).
which literally everyone can easily do themselves
Key word here is 'can'. People can update it themselves, but unless kept accountable for missing something bad, they don't do it unless a PM drags it out of them. In a perfect world we'd all show enough accountability to share the info that could affect a project in a democratic and orderly way, but even when ignoring a lack of PM experience, people usually feel it's bureaucratic and takes precious time away from their specialisation.
A PM with a good background will definitely have a chance to be better than a PM without, but being able to contact the right specialists at the right time and keeping the project flowing is what truly matters.
I loved being the scrum master but the responsibilities should be more than presenter.
I had to deliver project status notes to product shareholders, let them know of any directional changes we had to take due to blockages, drive the team to deliver on time for product launch, manage the backlog workflow to ensure the dod was accomplished, manage the backlog and attribute 15% of it to housecleaning/bug fixes.
This. A scrum master's job should be first and foremost making sure that the dev team has what it needs to get real actual work done. Ideally, the scrum master should be face tanking status/ update meeting, coordinating with outside entities, and ensuring that as few distractions make it to the team as possible.
Exactly. A good scrum master shields the team from the bureaucracy, facilitates the meetings while keeping them targeted and on-topic, and keeps everything running instead of slowing it down. They also coach the team in self-organisation.
There are far too many people that call themselves scrum masters that are actually just pressurising ticket managers.
I'd rather say an SM does not shield the team from bureaucracy, but makes them face it and empowers them to take it down.
The SM coaches the team on targeting the right topics themselves. Making them realize what to focus on. Ideally, don't to the work for them, that they should be able to do themselves. That would make them ignore these topics, because the SM takes care of it for them.
I don't send my dad memes often, but considering he has that exact book in his closet I had to send him this.
S c r ~~o t~~ u m
So...
I just got my PMI-ACP and PSM I.
I'll just see myself out.
The biggest problems with scrum, in my experience, are when the managers and directors don't understand it and ruin it. I've been a few places that implemented SAFe, but to this day I don't know what SAFe actually is beyond waterfall with pointless sprints. I've worked in a couple of places where the directors kept their noses out and scrum worked really well.
Meetings! Meetings as far as the eyes can see!
There's no escape, there's no rest. Life is only meetings now.
Welcome to the Meeting factory!
Anyone got the original or know the creator? Thanks!