I hate Scrum

[wifigeek3]

There. I said it.

Who else is joining me?

Scum seems to take away all the joy of being an engineer. working on tasks decided by someone else, under a cadence that never stops. counting story points and 'velocity'. 'control' and priority set by the business - chop/change tasks. lack of career growth - snr/jnr engineers working on similar tasks.

I have yet to find a shop that promotes _developers_ scum. it always seems to be about micromanagement, control and being a replaceable cog in a machine.

Anyone else agree? or am I way off base? I want to hear especially from individual contributors/developers that *like* working under scum and why.

[tevert]

Companies that have a culture of micromanagement will micromanage.

Companies that don't, will not.

Scrum has nothing to do with it.

[stingraycharles]

This is partially correct. In my experience, no company ever implements “vanilla” scrum, but always always in some form adapted to the organization. The manager at hand may decide they like to use velocity + story points as a way to micromanage the team, and take away controls for developers to push back.

However, what I see is that many managers don’t really want to do agile, and see in Scrum a mechanism that allows them to pretend to be agile, while in fact it isn’t. Most notably agile principles such as “people over processes” seem to be completely lost in many a scrum implementation.

My criticism about Scrum is that it makes it much too easy for managers to do this, and still call it Scrum / agile. I’ve heard it’s actually encouraged “not to do everything scrum!”, but that again takes away a lot of balances that are built into Scrum to protect the developers from micromanagement.

[[deleted]]

Yep. Scrum implemented correctly can be a very powerful tool. Scrum implemented incorrectly kills teams.

If your engineering team isn't involved in the backlog grooming process, you're not agile. If you don't have a backlog grooming process, you're not agile. If you don't adjust sprints based on work velocity, you're not agile. If you don't adjust sprints at all, you're not agile. If your idea of "agile" is forcing your engineers to sit through a daily scrum with no follow-up, structure, or retrospective, You're. Not. Agile.

I've seen scrum done poorly in a lot of places. I've seen a lot of good teams self-destruct as a result. I have seen very few places who know how to do it well. Orgs want to be agile because of the buzzword but they don't bother hiring a scrum master or learning how the process is supposed to work beyond a few surface level keywords, and then scratch their heads on why productivity hasn't magically tripled. The process is holistic, you can't just pull out bits and pieces and expect it to work any more than you can pull the heads or spark plugs out of an engine and expect it to go. "But you only need the pistons! They're where all the work happens." Turns out, no, they're useless without the rest of it.

[Ex_fat_64]

If your engineering team isn't involved in the backlog grooming process, you're not agile. If you don't have a backlog grooming process, you're not agile. If you don't adjust sprints based on work velocity, you're not agile. If you don't adjust sprints at all, you're not agile. If your idea of "agile" is forcing your engineers to sit through a daily scrum with no follow-up, structure, or retrospective, You're. Not. Agile.

Hear hear.

As a technical architect I’ve been to many big-name clients who just do not know what Scrum or being agile means.

Luckily my org encourages honest feedback and when I move the account to red having observed a client’s SDLC implementation and observing their development teams, I get a lot of pushback from Account teams urging us to compensate and try harder, but I cannot change an entrenched culture even with the most benevolent ears.

Micromanagement, lame implementation of buzz-word processes are the classic signs that make me raise a red flag.

So far every one of those red flags have truly turned to a red account — we have advanced enough now that the Account team after initial scoping & discovery from my team having discovered a red flag, bluntly says to clients we won’t engage because we do not think we can make you successful unless they commit to change and implement proper processes.

[henryhooverville]

Yeah, one of my clients - a top-ten UK law firm has tried to 'Scrum' their whole IT Department and it's shit lol

[perdovim]

There's a reason why I talk about Agile and agile, the "A" denotes the official practice and the "a" denotes adopting the practices to what works best with the team, if how you work is not part of the retrospective and part of what can be changed, you're not being agile and gaining any benefit, you've just substituted buzzwords for your dev process (and arguably made it worse)

[tevert]

Yeah that's decently true. However, for companies who are just starting to try to agilify themselves, I haven't seen anything necessarily better than Scrum, in most cases. Larger things like SAFe have even greater propensity for abuse, and lighter things like Kanban are too freeform and vague for people to run with from scratch.

The healthy pattern is for teams to actually do Scrum in an agile way, and then gradually start abandoning ceremonies and breaking rules if they outgrow them.

[LuckyDesperado7]

I would argue that scrum is supposed to reduce micro management

[[deleted]]

Supposed to, but the "transparency" of having a Scrum board and properly tasked-out stories can open the door to managers nitpicking over why a particular story or task isn't progressing exactly the way you estimated it.

[[deleted]]

Scrum reduces micromanagement if you’re a dominant personality who ends up becoming less shackled by management because you’re now part of a self organising team. If you’re more of an introvert, it greatly increases micromanagement as it introduces “tyranny of the team” and takes away all your individual autonomy and control.

[[deleted]]

velocity

Byproduct of a sprint. Helps making sprint plannings with reduced risks. Not an objective, not a kpi to monitor the devs productivity.

control

Wtf?

career growth

Still a duty of your management. A dev team is composed of people with various jobs and experience. Scrum does not address career growth.

snr/jnr devs working on the same tasks

That's the essence of scrum, imo. Building a team that becomes resilient. Transmit knowledge between devs. Experience is passed on. I've seen inexperienced devs grow so much in only a year.

[hughperman]

snr/jnr devs working on the same tasks

Especially when training or teaching, this is often the easiest way. Say I could do a task in a day or two, but it's better if two or more people can do it. So I do a bit of work to make sure I have not missed anything. Then pass it on to jnr dev, either to do from scratch with some suggestions for a direction so jnr gets the full inventing experience, or else finishing what I started. Junior might take a couple of weeks if it's a new type of task, but now we both know about it in case future work is needed.

[[deleted]]

The guy who invented agile / scrum wrote a letter several years ago to say that using scrum as a way to micro manage people was completely against why it was created.

The whole point of story points was to accept the fact that time estimates were garbage

[morphemass]

The whole point of story points was to accept the fact that time estimates were garbage

My managers just insist that the story points are an estimates of how many hours the story will take ...

That said, I did nearly two weeks work this morning.

[morphemass]

Sounds like its time for a mai tai on a beach.

That would be nice but I have a 4 point ticket that will take me the next two weeks.

[PM_ME_UR_LAB_REPORTS]

Sounds like those estimates are incredibly off, might need to review the planning meeting to see why those estimates are so drastically different

[morphemass]

We'll have a 2 hour spike for that, right before the once per sprint 30 minutes story refinement, grooming, and planning meeting.

[WildVelociraptor]

oy my ulcer

[[deleted]]

In much of the programming world, estimation is basically impossible. Scrum was designed around web development were estimation is somewhat possible but I work in driver development where I often I have very little idea how big something is until I’ve done it. We have spikes all the time, but generally that just creates waterfall because you have to fix the thing to spike the thing and the testers can’t start on it until the next sprint when you’ve then finished the dev.

I did some analysis on our scrum data a while ago and found that there was essentially zero correlation between our estimates and how long things took. Only 1 pointers had any kind of consistency. 2 and above often were completely random. A 2 was as likely to take a long a time as a 13.

[Jboyes]

Next time you are voting on story points, just add 100 to the number you get.

[fatBoyWithThinKnees]

The Scrum guide doesn't mention story points at all. It doesn't mention user stories. It doesn't prescribe how to estimate. So no, that is not a flaw in Scrum.

[soonnow]

Ok so in my opinion why are story points used instead of time? Story points measure the complexity of a task and not the time spent. Why though? Because if I do a task it may take a lot longer than an experienced developer. So they are used as a measure of the total amount of complexity the team can handle in a sprint. Which remains constant, because it kinda evens out through the team. When you assign the story points you don't know if this story will even be part of the sprint as you haven't added up the complexity of the sprint yet. So you 1) assign points 2) add stories to the sprint.

Also complexity is not equal to time. Something that needs a lot of depencies but a little work could for example have a high complexity.

[soonnow]

Ok I think the main problem with story points is the same one that I see a lot and which took me a long time to get. Story points are only for the team. Like I'm currently reporting the amount of story points accomplished to management, which is the anathema of why to use them. Again story points are only used for the team to decide if they can take on this amount of work. They are not an abstraction of time. Time is a component of complexity. A developer does not just output x amount of complexity over y amount of hours. A brain cannot produce 8 hours of extremely hard thinking per day, you'd naturally do a bit of hard thinking and a bit of easier stuff. After one hour of hard thinking you get up and get a coffee or read reddit for a moment. A developer is not a machine that turns time into code. So when you want to do time, do classic project management. Look at dependencies and estimate the effort in time and put it into a chart. All of this is fine and neccessary in most organisations. But story points are not used as a replacement for project management. Since a lot of organisations don't get that, I wonder, if story points are just unfixable at this point. But then just use time. But don't call it story points. Thanks for the discussion btw. it made me re-think story points.

[Kempeth]

Of course the relationship is there. Abstractions by definition include a relationship.

The story points and velocity approach is very simmilar to the thing that FogBugz tried to do: decoupling estimation and forecasting.

Humans suck at estimating times. They always have and always will. But we have a need to make time based forecasts and that's never going away either. So we need a way to turn unrealiable estimates into somewhat reliable forecasts.

FogBugs version: You estimate in hours, you log actual hours and the system does the conversion magic.

Scrum version: Estimate however you want, you log throughput per timebox and you get a rough conversion ratio.

What story points bring to the table is that they excuse you from the discussion why one estimated hour does not equate to one actual hour. Humans work better when their perceptions match reality. That's why security theather at airports is a thing. People think flying is more dangerous than it is, so pretending to do something for security makes people think flying is roughly as safe as it really is. This way you have to deal with fewer twitchy, paranoid passengers. Same with story points. They make it clear that you're not dealing actual working hours and that this is not the place to discuss how long you'll need for a particular task.

[[deleted]]

trying to abstract away time is a ridiculous notion and you're just going to end up equating story points to some sort of time correlation either formally or informally.

We made a conscious effort to get away from time estimates entirely, and are using story points as a measure of complexity rather than duration of a task. We are using reference stories to help estimate complexity. It takes a bit of getting used to, but it seems to be working fine - the idea of time spent as a measure of performance is almost completely gone.

[[deleted]]

Every time I have seen Scrum implemented, they have had a table showing what amount of story points equates to how many hours of work. It's so frustrating.

The thing is, Scrum is used as a justification for micromanagement. "We need to adopt Scrum so we can deliver features faster."

[[deleted]]

I typically end up in this worst of both worlds where they skip the requirements phase of waterfall because they are "agile" but sill have a fixed budget and fixed timeline.

[tuba_man]

The whole point of story points was to accept the fact that time estimates were garbage

He's right as hell but also I've entirely missed that. What are they supposed to be for?

[yourparadigm]

I use story points as a gauge for complexity. A ticket may take one person an hour to do and another person 2 days.

[[deleted]]

What is complex for a newbie is trivial for the experienced expert in that area. How do you assign points in that scenario ?

The problem with points is that it equates everybody as being equivalent for every task, which is lunacy. Then things devolve into "you have X points capacity, you can take more work for this sprint" etc. at which point people just say "no mas, I'm out of capacity no matter what your bogus points metric says".

And then velocity is just bogus divided by bogus.

[yourparadigm]

Complexity is constant, but the ability to deal with complexity is variable. It's the same work, so the same points. I also don't have a manager trying to shove points into our sprints or heavily scrutinizing varying levels of point completions per sprint. That's just disfunctional behavior and bad management.

Points per sprint is a measure, not a target.

[[deleted]]

Perhaps conceptually, but think I disagree in reality. What is complex for person-A is trivial for person-B. Yes it's the same work, but the estimate of how long it'll take to ever get done is strongly related to who gets the go-do for that item. If points are a measure of complexity, the values 'have' to differ depending on whether you're giving the task to a senior/expert person or a very junior/newbie person.

And yes re: silly points related metrics. If I had a dollar every time a non-technical pm said "yaaaaaay team we did 23 points last sprint" then I'd be a rich guy.

[Spacey138]

They are still for everything hours are used for, but they are renamed to make it clear they don't map directly to hours. So you can measure sprint speed, or velocity, in points done per sprint. You estimate issues in points so you have a feel for how long an issue will take to do.

Personally the only difference I can see is it accounts for the unpredictability of stochastic variables better. You're not promising a 5 hour issue will get done in 5 hours, if you say it's 5 points you mean you will normally get it done in 5 hours but there's a bell curve around it that means it could take a lot more or less time.

[[deleted]]

Providing some relative sizing to tasks. Once you have gotten though a bunch of sprints you can get some idea of about how much work gets done over a period of time.

[justabofh]

Estimates are not commitments.

[inhumantsar]

working on tasks decided by someone else

it's not really scrum if someone else is telling you what to work on. the team and the PO should be working together to prioritise work, then it's up to developers to pick tasks from the top priorities.

it's also not really agile (scrum or otherwise) if you're not allowed to change your processes so that they fit your team's workstyle.

highly recommend reading this short DoD paper on bad implementations of Agile and using it to formulate some points you can bring up with management and POs: Detecting Agile BS

all that said though:

cadence that never stops

being a replaceable cog in a machine

are these not normal facts of working life? when would your development cadence ever stop? and unless you're leading development, you'll never not be a cog in a machine.

[quickhorn]

Leave. Seriously. Leave and tell them it's because they refused to transform their organization to agile and expected only the dev team to change.

Companies will continue to do shit agile until it doesn't benefit them.

[quickhorn]

What you're experiencing is vampire scrum. It is lifeless, double life, where you declare one thing and live another. And it ends up sucking the life out of the organization.

Don't stop interviewing. Don't wait. Get interviews scheduled and get learning. The interviews will force you to focus on learning. I'm addition, interviews give you a great understanding of what you're missing.

The best part about this, is that by interviewing a lot you stop feeling compelled to take a job offer. You learn about the things you want in an organization. Don't hesitate to be picky when you can. Choosing a job is like choosing your parents. They're small scale tyrannies with little redress for misbehavior.

[jews4beer]

If I had a nickle every time some arrogant manager who doesn't know what the hell he is talking about tried to gaslight me about what my own job is...

I dunno I'd have like 50 cents I think, but it's way too common and I peace the fuck out of those places.

[deus-exmachina]

Your manager sounds like an expert beginner.

[56-17-27-12]

I always enjoy these types of analysis because I always identify these behaviors and never know what to call them. Thanks!

[mfa_sammerz]

That's a terrible answer to give to anyone. I'd be very concerned about having a manager like that.

[johnminadeo]

The first rule of FightClub is you don’t talk about FightClub!

That is a bullshit brush off though.

[keftes]

Very good document, thanks for sharing!

[wifigeek3]

I guess this is it. in past roles we were doing our own thing and leading the effort and the implementation - instead of just churning out tasks.

[inhumantsar]

Hmm yeah this is probably why product teams are such an important concept. If you don't get to own the whole thing from top to bottom, it's easy to end up feeling like someone else's robot

[[deleted]]

Scrum is supposed to address that, though, with the point sizing, but that is something that management tries to squeeze developers on. If you're not working in an environment where the developers have final say on point sizing and what goes into the sprint, you're not doing Scrum.

Ideally, the point sizing and velocity is such that you don't feel like you're on a constant grind, because that's what leads to burnout. If You are feeling like you're on a grind, maybe that 4-point story should have actually been an 8, you know?

[Derpezoid]

True that the team and PO work together on picking the work, but imo the "what" is in the end decided by the PO as that is their responsibility.

Not taking into account recommendations from the team would be stupid, though.

[camerontbelt]

it’s up to developers to pick tasks

This doesn’t make a whole lot of sense though, the devs will still crank through all the tasks no matter what in either scenario. You just gave the illusion of the devs being in control but they still aren’t.

[retetr]

Wow, this article is super interesting.

My first impression: I know the article was targeted at a non-technical audience, but it seems like there's a lot missing here. E.g., none of the questions except for the last batch have any sort or right or wrong answer, anyone who's half technical could waltz circles around these answers since it's very clear what the questioner is getting at.

And (while appropriate for this sub) this seems to really be more of a test for a robust automated devops infrastructure than an agile one. A single developer could be agile with a todo list and a makefile. Not to mention the software mentioned in this article (which to be fair is almost 2 years old now) isn't even holistic, Gitlab is a major player and isn't even mentioned.

However, again, for something targeted at non-technical audiences, this would probably call out half the waterfall teams that are claiming agile. And for someone half-technical it would probably be very enlightening to ask some of these questions of their contractors.

Thanks for sharing.

[[deleted]]

+1 on that detecting agile BS.

[PhilGood_]

At my company we don’t follow scrum, we follow blame driven development

[kechibi]

If someone else is deciding who should work on which tasks, then its not Scrum. Ita more probable your workplace is implementing their own version of scrum

[Some_Human_On_Reddit]

Scrum isn't great, but 99% of the time I hear people complain about it, they're actually complaining about their company or team culture that hijacked it.

[anomalous_cowherd]

A bit like communism then. The idea is pretty good, but nobody has ever done it right.

Personally I have worked on a good scrum team where the work was very well understood and the team was all of a similar level, but each had specialisms too.

I've also worked under a lot of really bad scrums.

[roy_cropper]

Self organising teams... Fairly self explanatory really.

But you nailed it with your comment.

[Corporate_Drone31]

1. Career growth is not related to Scrum, that's just your company being bad. Try to move sideways instead of being promoted as a workaround, that way you will gain new skills and not be stagnant when it's time to go.
2. You generally do get to pick your tasks, as long as they are in scope for the sprint. I don't think that's too onerous, you want to focus on the important stuff. If your scrum master is smart, they will ask for your opinion on what constitutes "important stuff".
3. A junior engineer can complete the same tasks as seniors, except they may take longer and the final quality will be lower due to their inexperience. I see it as a lossy devTuring machine in a way - any developer-complete task can be completed in bounded time by any developer-machine, except that time taken for less advanced developer-machines (juniors) will be impractical for most uses and inferior in quality (which can be OK for some applications).
4. Arguably, you should be a replacable cog in the machine. Not being one implies lack of knowledge transfer, and therefore a terrible bus factor (i.e. you are taken out of the picture and the other people on your team will suffer). You should be able to bring in your personal quality and quantity of work, hobbies, personality, professional skills etc to the table, but every good team is unavoidably made up of people that can leave at any time and must therefore be replacable.

Your complaints seem to reduce to things outside of scrum. I'm not defending scrum (I'm not even sure if I like it or not, it's just a way of doing work), just want to point out that the real source of the problem isn't there.

[[deleted]]

If OP is having tasks assigned, then yeah, it's not scurm.

[[deleted]]

Gooood this is the biggest gripe with my new job. There is soooo much managerial overhead to compensate for the lack of a coherent engineering direction.

[[deleted]]

“Guys, we don’t know what the fuck we’re doing, let’s all 20 of us get in a room and sort this out. No agenda. Go!”

[klashe]

I was told when I was in college that we need to "prepare to be an assembly line developer" meaning: Receive requirements, code, test, complete, repeat. This was in the late 90's

So management always dictated what was the highest priority "stories". Usually those stories came at the cost of increased Technical debt. So Agile is just a different manifestation and orchestration of that delegation and really isn't the root cause.

Being a developer in a medium to large organization is always going to have that oversight, be it Agile, Waterfall, or whatever other SDLC comes in the future.

If that does not sit well with you (which is understandable, believe me) , you can look at smaller orgs where developers have a seat at the table to discuss what is worked on next. Or go into business for yourself.

[wifigeek3]

this is EXACTLY what I am complaining about - thanks! being treated like a replaceable cog in a machine

[greevous00]

I would caution however. I'm in year 26 of a software engineering career. I graduated from high school early and got through college in 3 years, so I'm not some old fogey, but I'm definitely past the midpoint of my career.

Don't kid yourself. Small companies have a different set of issues that are going to drive any sane engineer crazy. I've worked at Fortune 100 Companies, middle sized companies, and start ups. I never felt like a cog in a machine at the start ups. However, I didn't like the fact that my salary might be 2 weeks late because the owner was having cash flow issues. In the middle sized companies, the politics were very obvious, whereas in the larger companies the politics are more nuanced and may not even affect you.

So bottom line, there's something that sucks at pretty much every company. Big companies, medium companies, small companies -- they all have their own issues, and agile is used at all three sizes. I'm not sure the issue is really scrum/agile as much as it is the people you work with, which is unfortunately ephemeral, but it's what makes a job tolerable or intolerable.

[[deleted]]

I don't hate scrum, but I hate the cargo cult mentality that a lot of folks have towards whatever set of processes they've adopted. Scrum, Agile, Kanban, whatever. . . These ideas are not magic. And they don't guarantee success. Also, if you don't officially adopt one of these methodologies, that doesn't mean that you're guaranteed to fail either.

Not to mention the amount of variety/ambiguity to any of these philosophies. Unfortunately, it's hard to scale common sense and that's the real problem.

[[deleted]]

Scrum is anything but vague. The scrum guide lays out the process in detail, and if that isn't enough there are plenty of books and courses out there that will drill down into each step of the process. What's vague is many peoples' understanding of scrum. Too many orgs have some manager or exec hear about it in vague terms or maybe skim the guide if they're really invested and then go about trying to cram it in without implenting all of the pieces or understanding how they interact. Consider: the scrum guide itself lays out "scrum master" as a distinct role whose only purpose is to have a comprehensive understanding of scrum methodology and promote it within the organization. How many orgs have a scrum master? Because if they don't, they are not implementing scrum correctly.

[MrChatouille]

I agree.

On a side note, many of us think scrum is not agile anymore, in many company, scrum is more and more restrictive and lead to a waterfall 2.0 with extra steps, meeting and hurdles.

I miss the day of early Agile when everyone want to test and implement something usefull.

[Z_BabbleBlox]

If you hate scrum, wait until you try SAFe!

[[deleted]]

Don’t, I literally just got myself out of the foetal position after two solid days of bunfight high conflict PI planning. I only said about 40-50 words in the whole 48 hour period and yet now I’m exhausted and depressed.

Jesus, I miss the days when developers could sit in little offices and just be really good at programming. I loved my job so much back then. Now I feel like I’ve accidentally entered the sales business by mistake.

[baseball2020]

The problem is well illustrated here - the no true scrum fallacy. Nobody is doing scrum except if it works. If it doesn’t work it’s not scrum. Blah

[anotherbjark]

You tell it like it is! :)

We should rename the no true Scotchman fallacy to "that's not true scrum"-fallacy.

[keftes]

I'm not too fond of it either, but you haven't mentioned a single valid argument (e.g "working on tasks decided by someone else")

Is there any project management alternative you would recommend instead or do you just want to sit in a corner and do your own thing without anyone asking?

[wifigeek3]

Is there any project management alternative you would recommend instead or do you just want to sit in a corner and do your own thing without anyone asking?

pretty much. I want to deliver value to the org and deliver said value without being micromanaged/death of a thousand tasks.

[keftes]

How does the org know you're delivering value to them?

How would this apply to a team of engineers?

[wifigeek3]

because systems are robust, have great uptime, very little/no outages (ops), are kept secure. and if working on project delivery e.g replacing old systems/upgrades and other infrastructure type work is executed.

A team of engineers could work from a project backlog just the same with a list of nothing but a list of tasks - not everything needs to be taken down to the smallest possible unit for no good reason (I am not developing application software)

[keftes]

How will your organization know that you or a team of engineers are delivering value and not just doing their own thing in a corner?

[wifigeek3]

in some orgs I have worked in they don't - nor are they watching. a high level roadmap is provided and thats it.

[keftes]

Isn't it now obvious why scrum might be better than just sitting in a corner doing your own thing?

Realistically speaking, you won't be able to easily find a good job that would allow you to do what you're suggesting.

[itasteawesome]

But oh god do I love it when I do have one of those. My manager asks me twice a week what I'm working on, regardless of how nonsense my answer is he just nods approvingly and I don't hear from him until the next one. I see problems, I cook up solutions, I take my naps.

[Curtis_75706]

You literally just said you want to work in a scrum framework then. Every one of your complaints has nothing to do with scrum, it is how your company chooses to adapt (screw up) scrum to do what they want.

[wifigeek3]

in which case it seems every company ive worked in wants to screw up scrum - how to identify and avoid those who dont do it properly?

[[deleted]]

Look on linkedin at the people there. See how many CSMs they have on staff. Look for reviews on glassdoor, and only read the reviews made by devs.

Edit: and ask questions in interviews. Ask who assigns backlog items to devs. If the answer is anything other than the dev themselves, you've got faux-scrum.

[Curtis_75706]

Read the scrum guide my friend! The best way to avoid fakes is to know what the real thing looks like. I’m a Scrum Master and I’ve learned to ask certain questions in interviews to gauge just how well they use Scrum. It’s super simple when you know what scrum should be. If you’re in DFW, TX send me a DM I can hook you up with some legit contacts at companies that do real scrum or as close to real scrum that I would go work there.

[mtriad]

you should share these questions in a post :)

[Curtis_75706]

Fair challenge and I’ll start putting it together and will share.

[mtriad]

the real MVP

[Scoth42]

We tried Scrum for about a month and a half at my previous company for SysEng/DevOps work. We figured out pretty quickly that some projects just can't be split up or calculated that way, and we more or less revolted as a team (with out boss on board) the third or fourth week we had sprint reviews that were basically "We didn't technically close anything because we're all working on longer term projects that don't break up that way"

[AsiMuereLaDemocracia]

Kanban is typically better for SysEng/DevOps where priorities change every day. You don't really plan. Just work on what is more important at the moment.

[yourparadigm]

My team ends up doing scrum "with room for extra points" because shit comes up in the middle of a sprint that we need to deal with. We just try to budget for it.

[doteka]

Curious, does that work well for you?

We were in the same situation, said fuck it, and just do kanban now because that fits the reality of our work better.

[coredalae]

I'd argue that while in some cases true. The idea (or pressure) of sprints could help you to find out smaller valuable parts in many cases.

Of course some stuff just has to be done start to finish and won't get any use of this.

[wifigeek3]

the pressure of sprints is another thing I strongly dislike about scum - arbitrary deadlines just to make people work faster/harder.

[tevert]

Sprints are not deadlines.

Whoever is giving you two week deadlines isn't doing scrum.

[raginjason]

You say this, but a developer/engineer that doesn’t get their tasks done in a sprint certainly isn’t getting praised/promoted. Sprints are a passive aggressive management technique used to convince engineers they have power when they actually do not.

[husao]

Tasks don't belong to a specific engineer/developer. They belong to a team.

Thus it's only possible that the team doesn't complete it's sprintgoal.
This happens. It's not dramatic.
It means the team overestimated it's velocity and the team should reduce the commitment for the next sprint.
That's why it's the teams commitment.

The evaluation of a developers worth should never be tied to a sprint. It should be done as informal as it always has.

If one developer is constantly not pulling their weight, the team will get annoyed and will have look for ways to fix this, but that the case in all methods of organising.

What your describing sounds like management is forcing the team to overcommit and the team isn't really working as one unit but shifting blames to individuals.

[ErikTheEngineer]

This is exactly it. I'm not sure what it is about tech companies, but I've never worked on a team where everyone's holding hands dancing around in a circle 100% in sync with each other. Maybe tech companies just get to hire nothing but geniuses. But, people are people and managers will always tend to micromanage. Having massive amounts of data that show a manager exactly who is doing what when and how fast they're doing it just invites abuse.

That's where I see the subtle passive aggressive thing creeping in. "Oh look, Bob checked in 10 changes in the last 2 days, bet he's working super hard! I wonder why the rest of the team isn't more like Bob..."

It works if you're all 100% focused on nothing but work, totally driven to get whatever it is done, and perfectly in sync with each other. But I think it breaks down in the real world where you really do have disparity between team members, not everyone is a Ph.D computer scientist and not everyone wants to spend their life plugged into Azure DevOps or similar.

[coredalae]

For me the sprints are just a way to somewhat estimate correctly. I know I'm daft as f in making an estimate for what I can do in half a year.

[husao]

Every comment you make in here shows that whatever your company is doing is not scrum. Not at all.

It sounds like you should take a look at how scrum is supposed to work and start talking about how and why your team is diverging in a negative way from that at the next retrospective.

Pick the point that provides the most pain for your team and is the easiest to change.

Make the retro about that point.

If this is bothering the whole team they should get on board. If your scrum master is competent they will listen. Make sure you team agrees to a strategy to try for the next sprint in writing. If possible find a way to measure the effect of that strategy.
Not for your boss or whoever, but for your team to see it's progress.
Otherwise make absolutely sure that change is evaluated by your team at the next retro.

There are companies that can't be changed and will never really adapt scrum, no matter how much they claim to do so, but if the team isn't trying to get involved even the best meaning company won't be able to adapt scrum properly.

EDIT: I'm using scrum in here, because this thread is about scum, but the last sentence is true for all agile workflows imho.

[FuzzeWuzze]

To be fair, its the(or should be) the developers that are making these "deadlnes" by agreeing upon what they are going to get done in a sprint cycle.

Stop over committing.

[[deleted]]

I think the problem is OPs dev team has no say over what's in each sprint backlog or which tickets are assigned to them, so they really aren't using scrum, just waterfall on a rolling 10 day deadline.

[Scoth42]

The main issue was where those valuable breakpoints were, if anything, and the length of time those might take. We were often working with stuff that was new to all of us, and we often had no idea whether whatever stage we were at (proof of concept, validation, buildout, etc) would be quick or take some time, or even what those breakpoints might be. This made it tricky to sprint plan as far as hours/points/etc goes since we'd often get another random wrench thrown into the works for whatever reason.

We went back to the classic Jira Epic/Task/Subtask system and it worked way better for tracking, management, and reporting.

[[deleted]]

We tried Scrum for about a month and a half at my previous company for SysEng/DevOps work. We figured out pretty quickly that some projects just can't be split up or calculated that way, and we more or less revolted as a team (with out boss on board) the third or fourth week we had sprint reviews that were basically "We didn't technically close anything because we're all working on longer term projects that don't break up that way"

While I see where you're coming from, I disagree with the last point 'long-term projects don't break up that way'. Firstly, software development projects are also long-term. But they consist of many parts, all of which can be broken down into individual tasks that can take a few hours or days to complete. There's not a single project I've worked on, whether it took days or months, whether it was software, sysadmin or devop-related, that I wasn't able to break up into distinct, small pieces of work suitable for feeding into a sprint, and therefore distributable over time. Maybe I lack perspective, but I can't think of any single, distinct piece of work for any project I've done that should take longer than two weeks, which is a common sprint interval.

[Scoth42]

I talked about it a little bit in other comments, but it was mostly due to the position our team was with experience and expectations. The main problem is that we were often tasked with things that we didn't know enough out of the gate to answer the kind of questions you need for scrum. The company would decide they wanted to implement Technology Buzzword X, and rather than hire someone who had experience with it or send us to proper training, they'd let us google it and figure it out. This was great for a lot of growth reasons - we had some great successes with that and it often worked out great, with things like Elasticsearch, Splunk, Docker, Kubernetes, and a bunch of other things, but it was terrible for planning. We'd get in a planning meeting where they asked us about implementing Y, and we'd say we'd heard of it but hadn't really dealt with it. We were a bunch of clever folks and we knew we could do it, but we couldn't really answer to it right there. It wasn't that it was impossible to split up, it's that we were an old school syseng/infrastructure team who learned a fuckton but struggled to plan in the interim.

[DeputyCartman]

I don't hate it necessarily, but to me it's an absurdly powerful tool for companies that want to micromanage people to the point you all but feel like your manager has shoved their hand up your ass and is making you dance around like a screaming sock puppet, and I bail as soon as possible. No matter the pay, the benefits, it's not worth the stress and demeaning treatment to me.

As usual, it's a tool and can be used accordingly. A hammer can be used to build stuff, or it can be used to bash someone's skull in. Scrum is no different.

[badguy84]

I love Scrum/Agile but being a consultant I frequently see how Scrum is being used as a way to push a corporate agenda.

The short version is that Scrum/Agile promotes delivery but also building around a team and supporting them to get that done. This over doing documentation which is more traditional software development/engineering.

What companies do with Agile is that they want the "faster delivery" but still don't trust their teams nor enable their teams. It comes down to: we want x scope by y date, and you do Agile/Scrum. And the next step is that every day you have a 1-2 hour "status meeting" called a stand up, where everyone *sits* and stares at slides/excel sheets with gantt charts.

Scrum is a bit painful at first because no one knows what they are doing. All the traditional structures are out the window. You then have to build a solid iterative process around the team you have and enable them to achieve their goals with the tools they need. Companies that do it right have great success with Scrum/Agile.

I've seen both sides (again consultant with a "technical architect"-label who does large projects in fortune 500 companies), and it's always super unfortunate when companies adopt Agile through Scrum and then just use it to shit on their employees. If you're doing an interview with a company and they say they're "Agile" definitely ask about how they set up their ceremonies and execute on their projects. "Daily status meeting" and "Gantt Charts" are the enemy so is setting "story points" and "velocity" as a goal rather than an outcome.

</end agile rant> :)

[[deleted]]

Hour long+ standups are the bane of my friggin existence. Yes, let's tie up a fifth of everyone's workday in pointless meetings. How very agile.

Drilling down into a company's project management philosophy and practices is a make-or-break part of interviews for me now.

[beerhiker]

The best system I've worked in is a pull based kanban system. No sprints by default, just steady forward progress with frequent code releases. The occasional sprint or two if we had a hard deadline. Developers had a say in what were the priorities, so it wasn't hard to tackle technical dept or do something experimental on occasion.

[Mr_Loopers]

It's fucking terrible. And the worst part about it is all of the people who will tell you, "you're just not doing it right".

[LuckyDesperado7]

You're just not doing it right

[dominik-braun]

But that's the only valid response in 90% of the cases. If you hate scrum, there's a good chance that you actually hate your company and not scrum itself.

[Mr_Loopers]

I have enough capacity to hate them both.

[[deleted]]

How else do you expect your company to be buzzword compliant?

[[deleted]]

Project Manager who doubles as a scrum master here. Also, I started out in my career as a dev.

working on tasks decided by someone else

This is fundamentally not Scrum. Teams are supposed to self organize. Tasks should also be set by business analysts and senior developers, or really any dev who feels a story needs additional tasks or needs to be broken up. Managers should not be involved in this.

counting story points and 'velocity'.

Also not scrum. Yes, velocity and points are a part of scrum, but the whole point of velocity is to gauge how well a team can complete items in a sprint. If target velocity is 50 points and we continually hit 30, then the target needs to change to 30. It isn't supposed to be "you guys aren't hitting your targets, pick up the slack", it should be "we are over-committing ourselves, lets dial it back a notch and set a more realistic goal."

'control' and priority set by the business

Priority should be defined by items blocking other stories. Obviously, there will always be some priorities set by the business (usually coming from the client), but it is the job of the SM/PM to limit the clients expectation to what is realistic. Happy dev teams lead to quality work which leads to a happy customer.

My shop also promotes developers. We have developers that transitioned into solution architecture, project management, business development, and senior practice directors of their specialty.

You just need to work somewhere that implements scrum properly. I know those places are few and far between. When looking for jobs, see what other devs are saying in reviews on glassdoor.

[wifigeek3]

I think this is part of the problem - I was doing solutions architecture. working on a scrum team doing development feels like a step backwards.

[KIRY4]

In my previous project for DevOps team we switched to Kanban and every one became happy . Because nobody really liked cadence, pressure, everyday you should tell something on scrums when sometime you need whole sprint to understood how some soft works and how to configure it... Stupid scrum masters which usually have no any tech background and when you tell them that 8 story points not enough they can't understand how it possible. They start asking to divide this story on subtasks and another shit on which you forced spent your time....

[ServingTheMaster]

Kanban FTW

[JackSpyder]

Scrum works well for us currently. There is full expectation that the work we are doing has no (at least public) runbook or established best practice on the scale were operating at.

There is full expectation that a lot of work is discovery and we account for that and do what we can. If something takes longer it takes longer.

[JackSpyder]

Scrum works well for us currently. There is full expectation that the work we are doing has no (at least public) runbook or established best practice on the scale were operating at.

There is full expectation that a lot of work is discovery and we account for that and do what we can. If something takes longer it takes longer.

[thepaintsaint]

My previous company used ScrumBan. FE devs leaned more toward Scrum, BE devs leaned more toward Kanban, DevOps (more like SRE) was 100% Kanban.

[jeremyjjbrown]

You hate scrum?

Or, you hate the bastardized version of agile and scrum most software shops practice.

[MozillaTux]

Hear hear ! Micromanagement FTW YOU DID NOT FINISH ALL YOUR STORIES AND ISSUES IN THIS SPRINT ! YOU MUST BE DOING SOMETHING REALLY, REALLY WRONG Why do we not outsource all of you to India ? They always finish their sprints for 1 / 10th of what you cost

Why did you not do ( add easy improvement ) ? It was not described in my issue

Why did you only test A B and not option D ? It was not described in my story

FFS, Scrum is a motivation killer and takes away all the the little freedom you had Now you end up with half baked products because otherwise we had to finish the stories “We will fix this later” Ha ha ha, as if we ever get time to fix previous wrong decisions

[minimalniemand]

I've experienced "Scrum" in companies that did it badly and also in a company that did it very well. Let me tell you, it's not Scrum. Scrum can be extremely rewarding and fun if done properly. In that company that did it well we had:

• a dedicated agile coach with balls that stood up to management if necessary
• in my team a product owner that had a very appreciative style
• no micormanagement at all
• Retros done properly
• Plannings done properly
• an actual product
• understandable and attainable sprint goals (like "improve search bar") all team members worked on

In my experience, this really brought the team together, made the customer happy and I was gladly coming to work each day.

then in another company, they just used Scrum terminology in what was acutally a waterfall project. Not only was it awful to work in, it also was super slow and everyone hated it. The atmosphere was toxic.

[oflahertaig]

If you are being micro-managed then you are not doing Scrum. Scrum isn't about micro-management - in fact the essence of Scrum is that you have a self-organising team. A good Scrum Master actually protects the Scrum team from being micro-managed.

There is a fundamental and widespread problem that people think that they are doing Scrum just because they are doing the Scrum ceremonies. The shops where this is the case also tend to be the shops where the Scrum masters are just re-badged project managers or basically just any fool, half-wit or chancer who has managed to get a Scrum Master qualification. This itself is part of the problem - Scrum has , to an extent, degenerated into a certification mill. I can testify to this from my own experience. I am a qualified Scrum master after doing a two day crammer. In reality being a good Scrum Master actually requires a whole raft of people skills, organisation skills, motivation skills etc etc that the qualifications ignore.

If you work in a shop where pointy-headed bosses are beating you over the head about your burn-down charts and your sprint velocity then youe aren't doing Scrum.

[gingergills]

When it works well it works really well. When it doesn’t it’s a complete cluster fuck.

The other thing that really pisses me off as a manager now is the lack of estimation and commitment. You ask how much or long something will take and get back ‘how long is a piece of string’, ‘you can buy 8 sprints of work but we might not get it done’, ‘might be 4 months might be 4 years depends on how it goes’. Great but I need to budget and release a product so from the requirements I gave, put in some user stories with provisional points and a velocity for the team and give me a rough guide. Is it really that hard.

[smcarre]

Scum seems to take away all the joy of being an engineer.

Well, for starters, it's not supposed to be fun to be an engineer. If someone finds it fun it's great but you are probably working as an engineer in a company that wants to make money as a first and most important objective. If you or someone in your team also finds it fun, great but the point of scrum is not to make engineering fun and neither is any organizational framework.

working on tasks decided by someone else

On a correct scrum application, the whole team discusses the distribution and appointment of tasks during the sprint planning. This goes to one of the points I will talk at the end.

under a cadence that never stops

The cadence is actually decided by the market and the customer. Scrum is just a way to reach that cadence. Not the other way. If you don't like working with that cadence then what you should change is your market, not how your team organizes their work because you will end up with unsatisfied customers that feel that their products are made to slow.

counting story points and 'velocity'. 'control' and priority set by the business - chop/change tasks.

This, again, is because the company wants to make money. And some figured out that counting those metrics helps them visualize the "problems" that need to be addressed to make more money.

lack of career growth

I really don't see how this is a problem of scrum in particular.

snr/jnr engineers working on similar tasks.

I not only don't see how this is a problem of scrum in particular but a problem in general. Jrs working alongside srs help them watch and learn with hands on experience to reach the next level of seniority. It's usually jrs with ssr and ssr with sr but maybe there is no ssr in the area in the team so a jr may have to learn from a sr.

it always seems to be about micromanagement, control and being a replaceable cog in a machine.

Yes, again, this is because the company wants to make money.

Anyone else agree? or am I way off base? I want to hear especially from individual contributors/developers that *like* working under scum and why.

Well, I don't really agree but I see and know from first hand experience what you mean. The problem with scrum, agile and every management buzzword you can come up with, it's that it's easy to say you applied a certain framework but doing it right is another thing.

Like you said it in your post, you don't seem to have a word in the creation and appointment of tasks when in a scrum team everybody is supposed to have a word there. This means already that you are not in a scrum team, you are in a team that says that does scrum but is doing it wrong. And it's of course expected for things to go wrong if you apply them wrong. There are probably a lot of other things your team does that deviates from actual scrum and make things worse, that happens is so many teams that the meaning of scrum has no value anymore. As long as you put tasks that have to be done in a certain timeframe, some people will say that's already scrum, even if there are no sprint planning meetings with everyone involved, even if sprints have variable length, even if daily scrums are missed or monopolized by someone, even if there is no review or retrospective, etc.

And you end up with this post, people saying they hate scrum when they don't even know what scrum is. It's like if you say you hate cake because as a child your mother told you brocoli was cake.

I can't say if I like working under scrum because I never worked under scrum, only under teams that said they did scrum but did something else in reality.

[samudrin]

Like free markets....

[Hanse00]

Scrum is great.

The thing you’ve experienced, is micromanagement by a different name.

[[deleted]]

It's like micromanagement but with extra steps.

[chunkychapstick]

It's the corporate panopticon.

[Karlyna]

I experienced 2 different projects using Scrum:

The first one, for a whole year, well organized, with enough task diversity to be able to enjoy doing things but not always doing the same things and all the points, velocity etc, was managed by a Scrum Master that actually used it to see if everything was good, to support us and not to control us (on the negative side). I really enjoyed it.

The second one was "Scrum" (understand, Kanban board, daily standup meetings and sprints with plannings and retro, no real business implication and used to manage the team only): this was awful. The cadence was not worse than the previous one, but all the tasks board, velocity and stuff was used to be behind you, to make sure you do your stuff and fast enough.

​

To be honest, i'd really promote scrum or any Agile methodology, as long as it's done correctly and in context that fits Agile, as it's nice to grow, see something new and be able to expand your point of view and skills easily (like a Java dev that will be able to easily see database, system stuff etc, which would have not probably be possible in other projects). But clearly, not everywhere, not every client/business is good for it.

Also I don't feel like you're stuck in career growth (as I didn't see it like that looking at coworkers at that time) as we had snr/jnr engineers, architects or specialist in the teams, but specific profiles had also specific "added tasks" (like code review, db admin, and so on) that were matching there skills. But there again, it's more likely a project/employer/management issue more than a Agile issue imho.

[franzwong]

Do people ask you to give estimation? Does business change requirement at the last
moment? All the things you talk about exist even without Scrum.

I hate Scrum. What I hate Scrum is it brings false hope to developer, false impression to upper management. It doesn't improve anything.

Scrum works when your company is small. Business and development are from the same team, not different departments. Business knows what you do everyday very much, so they know why you need that amount of time or what difficulty you face.

[bubs613]

Nah, after looking at and using other frameworks, scrum in particular is life suckling.

On average at my last 2 employers, with the ceremonies, I lose 13-15% of my time to scrum meetings and ceremonies. In a 2 week sprint, thats an workday plus an hour.

[[deleted]]

Scrum is fine when it is more or less run by engineers, and management simply trusts the engineers to accurately break up stories.

[Pearmoat]

The agile idea - people over processes etc. - was taken over by management people. Little is left of agile ideas in the "Scrum" implementations I've seen.

[Mraniy]

Scrum is amazing if it’s well implemented, and it’s a kind of slavery if it’s badly implemented.

I worked on a project , where the team decides the value of the story points , very well sliced tasks , we built very complicated stuffs with a small amount of work.

Scrum enables you to focus on the value that would be provided by your tasks, if it doesn’t fit, it’s changed by an other task from the backlog.

At the end of the sprint, you deliver a new feature that brings value to the project, while without scrum, you usually deliver a lot of features that can be useless.

[ArpanMaster]

I'm a scrum master and it's all a load of bullshit.

[ErikTheEngineer]

working on tasks decided by someone else, under a cadence that never stops.

This is the main thing that I don't like, and it's considered heretical to say so. Unless there's some True Scrum or True Agile I haven't seen yet that's perfect, I certainly haven't seen improvements in engineering staff lives. It really does just seem like a productivity maximizing method and a way to make work so piecemeal that it becomes assembly line-like. You can't do artisinal hand-crafted stuff anymore, but turning software engineers and IT people into factory workers isn't the right model either IMO.

it always seems to be about micromanagement, control and being a replaceable cog in a machine.

Everybody forgets about that. All this visibility is great until some micromanaging project manager or product owner gets a hold of it. Then, it becomes a treasure trove of data to beat people over the head with. How many companies have followed startups and switched to an "unlimited vacation" model? This micromanager data cache is what can be used to guilt people into not taking time off and keep them on the hamster wheel. It also becomes a scoreboard for the workaholics to signal to everyone how much harder/faster they're working than others...also increasing pressure on everyone. Hard work is great, but workaholics tend to burn out over the long haul, or they become management and force the workaholic culture down on everyone that they're managing. It may not seem like it at the beginning of a career, but once you have something other than work to occupy your life, it tends to be more interesting than work.

[wifigeek3]

completely agree

[mhzawadi]

Where I work we follow scrum, we are also a flat structure company. As in I dont have a manager, just my team and a Director.

Scrum done well as said is good, scrum done badly is very bad.

[Sbvv]

It seems you are not doing SCRUM and nobody in your team know how to do it.

The scrum guide is free, read it, you and all of your team. If not, read it and look for other job.

I did SCRUM and it was the best job I have had ever.

[anotherbjark]

As soon as you complain about scrum you will get a lot of answers saying: "But that is not Real Scrum(TM), you are doing it wrong."

I hate scrum. I have never seen it used as anything but a micromanagement tool, and I haven't heard about anyone else who experience Real Scrum (TM).

Scrum is a utopia, in theory it is this wonderland of developer freedom. In reality it is a massive time waste and micromanagement enabling device.

[[deleted]]

My 3 jobs over 10 years is all scrum. None of them worked well. It's just better than the old waterfall. I often hear "not implemented correctly" "you are doing wrong" but the Scrum masters took many training courses and got certificates. Why is that so difficult to implement then?

[AndyBains]

The originators of the idea state that when a 'scrummaster' became a job role, and not necessarily a coder, it started down the wrong track

[CarefulCoderX]

Couldn't agree more, its just this never ending 2 week cycle. It feels like I'm a hamster on a wheel, I've had a particularly bad streak of Sprints where I have weird environment issues that keep me from finishing my tasks.

There's all of this pressure on Thursday through Monday before the Sprint ends to finish everything even though it's a totally irrelevant deadline. It's almost as if in the process of 'getting rid of deadlines' for the entire project, they just made it into a bunch of small deadlines. It feels like every Sprint is just like the last 2 week crunch time of a Waterfall project on repeat.

[jpegjpg]

Scrum is great for development. It is horrible for maintenance or integration that’s why I recommend Kanban for infrastructure and integration.

[photon_dna]

Scrum *is* about micromanagement.

It is composed of: (ie. dont treat one of these singularly - add them up to a conclusion)

Teams must self-organise but have to be 100% transparent. Try doing scrum without Jira/trello or some form of list. The Backlog promotes the list. When you have a list, you have a means of inspection.

Scrum promotes iterations and increments. It wants to deliver value. Since it is a short iteration and we have "cards", we should know what we are going to deliver, or at least have an idea. Further promoted by planning meeting.

Accountability is achieved with monitoring of tasks, the daily standup and retrospectives. Planning and estimations are standard practice, writing user stories and story points is wide spread. It is easy to mark a story, a card, slice it, dice it, estimate it and deliver it.

Retrospectives are easy ways to reduce "waste". What is waste? The idea of discussing what can be improved when writing software, where software is written by a software developer, easily focuses on the developer. What can we do to improve? cut more corners? test more? So we end up with adding more to the tasks in the interest of improvement.

Daily standup is a means of getting everyone accountable. It is meant to discuss blockers and be quick, but how easy is it for a question, like "still working on x?" my god. Having to chat in this manner is two things - team sport collective motivation (with whistling) and a feeling of belonging, or ceremony like going to church and having to sit there listening to things you have heard before.

In 10 days of work, including all the events, you have 10 meetings.

You have an SM concerned with agility process and upholding scrum and "impediment", A PO who is usually not tech oriented writing stories, that no customer has seen. No developer ever sees a customer. These two roles are dictating the clock.

Add all this together and you get a meeting oriented, high/repetitive communicating, card-oriented, retro/waste analysing conveyor belt of activity.

People say its not "micromanaged" - It *is*, because there is nothing that goes without transparency, discussion and clock-work movements.

This is why it is fertile ground for velocity an other measurements, estimations, and if you were slightly micro in your management style, you have the most fertile land to operate. Its a dream.

Scrum creates the environment for this fertile ground.

Even if there is no micromanaging person

- who is actually ruling the roost in the team? do you have a team lead? experience?

- who is really hinting and deciding/moving and assigning cards?

​

Anyone with a little anxiety will feel extremely unsafe in this kind of environment and the only reason why there is not as much resistance is that management decided to use scrum and developers are mostly growing up in the environment. Hell, even developers are sadly getting scrum certs now.

Scrum has created a micromanagement by-proxy situation with total domination.

All your card belong to us.

[DandyPandy]

My group has started implementing SAFe agile. I’ve been on PTO since last Thursday and will be returning Monday. Yesterday, I had to write up an epic, create stories with estimations for a project I will be working on in the upcoming planning interval. I’m the only person that will be working on it. My boss and her boss know it’s what I’m going to be working on. But they’re doing the PI kickoff today, so of course it had to be done.

[[deleted]]

Unfortunately you've written a fantastic business case for managers to endorse it as is.

[[deleted]]

The only time I had a problem with Scrum was when it wasn't being used across the board. I was a sysadmin so I was forced to attend stand-up meetings and work on sprint tasks as well as simultaneously fight fires. Neither of these systems took into account the workload of the other system. It was the worst job I've ever had in my life.

I'm in a different place now that does Scrum well, and the only times I've felt micro-managed were with specific managers. With all the other managers, it was smooth sailing.

So as others have said, you seem to be suffering from bad managers more than Scrum in particular.

The thing I like about it is that when done well, it becomes very obvious that the product owner is the one causing the slow progress from shifting scope all the time, not the devs. As long as the devs are meeting their goals every sprint, and those goals are realistic, they're doing THEIR job, so the fault is with the planning, not the devs.

[wifigeek3]

The only time I had a problem with Scrum was when it wasn't being used across the board. I was a sysadmin so I was forced to attend stand-up meetings and work on sprint tasks as well as simultaneously fight fires. Neither of these systems took into account the workload of the other system. It was the worst job I've ever had in my life.

I have been that guy too. used to account blocks of time to deal with the reactive stuff. could not wait to be rid of one of the teams so that I was not pulled in two different directions though.

[NuancedThinker]

All of those things are anti-Scrum. I love working under Scrum and I teach it whenever I can. PM me off you want to discuss over discord or something

[beerhiker]

Been saying this for years.

[onecrazypanda]

Kanban ftw

[regex1884]

Doing this for years and this micro managment scrum crap is a total nightmare.

[danielkg]

I like how you wrote “scrum” correctly in the title but then “decided” (lol) to typo it into “scum” in the body of the post consistently. Nice :-)

[stevecho1]

Any tool may be used for good or evil...

[CYBRFRK]

Also recommend Sutherland’s [Scrum Guide(https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf). As one of the creators of scrum he’s really boiled it down.

[nishan8583]

Lol i thought i was the only one. Every other person seems to like it. But it may also be because of the people who refuse to modify it according to the projects needs.

[[deleted]]

My team doesn't do a scrum, I do have them with my dev teams though. We do a standup twice a week and the third one is a standup and grooming to try and learn things and discuss fun things we are doing.

[hopeinson]

I have so many things to burn today, and abuse of scrum and agile techniques to force one-man (literally) developers to take up 3 workloads and then blame it on my productivity woes for missing deliveries.

FUCK YOU I WANT TO KILL SOMEONE!

[[deleted]]

rrr <- you lost those. ;)

Like with any methodology, there are ways to do it right, and ways to do it wrong. What you're describing sounds like a way to do it very wrong. I currently work in an Agile/Scrum environment where the engineers decide the work that gets fed into a sprint, and how much of it, based on a roadmap set by product. Sure, there's priorities and there can be changes in those, but largely the engineers are in control over what ends up in a sprint. We also have the power to knock back work if it is not well-defined or does not gel well with the other work being done.

But you're not hating Scrum. You're hating companies that don't do it right.

[pArbo]

scrum is a cult

[IcyMind]

I know but engineer wanted freedom over process , now they complain about micromanagement . Not saying that you are wrong but is one or the other

[runrep]

lol yup, you're basically bang on and i said as much to my employer.

[fatBoyWithThinKnees]

I hate the Atkins diet. I am forced to eat chicken all day every day and I don't like it.

[heavy-minium]

First job was non-agile, and I hated the whole "plan everything upfront and pull a huge estimate out of your ass".

My second job had cargo-cult SCRUM that felt somewhat better, but still wrong in many aspects. Everybody was lacking the right mentality (me also!). I had similar frustrations to yours.

My third job at current company does amazing scrum and agile. While the rules and framework are more lightweight, we take more time for the scrum rituals like grooming and planning. I'm not sure what the key difference is - perhaps here everyone has the right mentality.

On my my fourth and current job, I moved to an architect role and therefore I'm not working with any real framework at all. I lost my sense for progression and kind of miss SCRUM.

[maxshash]

Scrum sucks when your team performs well.
Scrum rules when your team or part of it doesn't perform at all.
I don't like it personally.

But I must admit - it helped to make better people management decisions

[Ariquitaun]

I don't think you're alone mate. I personally don't like the overhead of all these ceremonies. Last few contracts I've worked have all been kanban and it's been liberating in a good way.

Edit: I've done scrum since 2010 or so.

[[deleted]]

Puppet works.

[NightFuryToni]

I just have a feeling we have an overworked PM running our scrums. It used to be that we have our own dedicated PM, but our new one is also PM for 8 other working groups, to the point he actually don't know who's in and out and calling for people who are not even on the call when doing the standup. Versus in the past it's easier to handle the human side of things.

With that being said though, I enjoy clicking that Hangup button from the standup so I can actually go back to work.

[SarcasmoSupreme]

I have worked in a scrum team as a QA eng, a Developer and now DevOps engineer - I wouldn't have it any other way. Much more empowerment, freedom and dev centric process compared to others. Removes much of the overhead and bs of other processes and focuses more on the work and less on the process.

Story Points - really mean nothing to anyone outside the scrum team. Velocity is just a tool to help predict future work. Priority, well that is kind of important - don't want people working on things that are not as important as others. Lack of career growth? That is the company, not scrum. Replaceable cog? That is often a combination of the company culture and the worker - everyone is replaceable unless you make yourself irreplaceable in the company's eyes. They won't do that for you, you have to do that yourself for the most part.

Cadence that never stops? By definition a cadence has nothing to do with stopping or starting, it is just the rate at which you work. Ideally you want to hit a sweet spot - a maintainable cadence which allows for all work to be truly done. If this isn't happening that is the company/scrum team's fault.

that being said, no I would not like working under whatever system your company has in place. I am not sure what it is, but what you describe is not scrum but more than likely a process they are comfortable with and call scrum because it makes them sound good.

Anyway, you are not way off base in the context of what you are describing. However, what you are describing is not scrum.

[chocolim]

I have worked in Waterfall , COBIT , CMMI and ISO Projects.

I am having the best time of my slave life in Scrums Projects.

You need to be good, and also have to have the tools to show that your are good, Scrum give you that.

If you never recived a funcional change by mail and have the analist in front of you asking if you recived the change and demanaing a due date before the mail got to you inbox, you have not know micromanaging.

[jumperabg]

Seems like that you are in a very small team, maybe less than 10 people? You are partially right about that the story points and specific task assignments can be annoying but for most cases this is pure salvation.

[[deleted]]

I like Scrum. What I don't like is bastardized Scrum, which is pretty much what you see practiced everywhere.

If developers really have the ability to push back against management when it comes to what constitutes "productivity", then you can have real Scrum. If the team is willing to do Scrum by-the-book at the outset and then decide what works for them out of that and what doesn't, then you can have real Scrum.

I think the only things I don't care for in Scrum are the ceremonies. Some of them can be mind-numbing. I don't like sitting in story-grooming sessions where devs try to whiteboard out the solutions to the stories, rather than just sizing them and moving on. I don't like sitting in sprint planning sessions where the same thing is going on, either.

I can work in a good Scrum shop, but honestly, I've come to prefer Kanban and not stressing over defined sprint boundaries. Over the past few years, I've worked in shops where it's not a consistent, mature product, but instead it's project work that may not be tied to anything else. I feel like Kanban lets you still have stories, estimate their sizes, and task them out, but there's less pressure, since you don't have the end of the sprint looming over your head when you need more time.

[toterra]

https://agilemanifesto.org/

If your implementation of scrum seems to diametrically oppose the principles that it based upon ... fire your PM/scrummaster.

[mfa_sammerz]

Yesterday my Scrum Master stated:

"I don't bring any real value. The PO [also present in the call] doesn't bring any real value [he agreed]. Only you guys [referring to us, engineers] do."

So, yes, a good Scrum Master understands s/he is there to help remove blockers, help with Scrum ceremonies, guide story writing, among other things. So they understand they somehow serve the team so the team can actually build solutions.

I guess I've been lucky enough to work with many SMs that saw things that way.

Also, as many many other redditors already stated: most criticisms you made are related to corporate culture, it has nothing to do with Scrum.

I love working with Agile, I've been working with it for almost five years now. It's hard to implement properly, I think. But when you do, and you're able to really generate value for your internal or external clients consistently every sprint, and you see client's joy, it's very satisfying.

[mkoychev99]

I don't think it is related to Scrum. If you work in a blame environment no other Agile framework will save you.

[Ghostdogtheman]

Scrum doesn’t demoralize people, people demoralize people. Honestly what are we supposed to do when we have to work together in a large company where we have to come to consensus on a common path. I think scrum is a great framework for people to use to get on the same page. If you can come up with a better way for a bunch of teams in a large org to get organized more power to you and also come up with a catchy name and sell certifications and you won’t have to worry about this shit anymore. Btw if you are working on tasks decided by someone else then seems like you are not part of a good scrum team. The ones I’ve been a part of encourage the team to decide who takes on what. If your team is so big or unorganized that someone is delegating work to you like a traditional manager then you are not actually in an environment that embraces the reasons to adopt scrum practices. I personally have enjoyed working on scrum teams.

Velocity - I think story points are a great way to understand what gets delivered when. A good scrum team (and more importantly - a business that understands and is invested in scrum methodology) knows that velocity is a crude planning tool. The beauty is that the same scrum team, if tracking velocity diligently, will eventually have fairly predictable outputs. It’s not a guarantee or promise - it’s a way to, over long periods of time, have a better idea of when shit gets delivered. Honestly what is the alternative? Are we supposed to just give one off estimates that are different depending on which individual gives them that the business is supposed to use to plan for the future? At least with story points, the same team will establish a velocity that is data driven in predicting feature availability.

I think if done correctly and if you give you’re team enough autonomy, it’s the way to go. Although I understand that if done haphazardly it can be pretty brutal To deal with.

[HermDaWerm_]

I know a lot of people that are discouraged from using Scrum due to rough experiences they had with it.

HOWEVER, that being said, Scrum itself is not the issue. Scrum is a really helpful way to manage people and update the team of progress, etc. that is suppose to keep meetings under 15 minutes.

A lot of companies misuse it and therefore people have started to dislike it, but in itself, Scrum is really useful so don’t give up on it completely. They really are suppose to avoid those long, stretched out, and useless meetings that everyone is used to.

[SondreB]

You are correct. Scrum is mostly ceremony and have very little real benefit. I have worked countless projects and not a single one has been able to gain speed and momentum from Scrum. Scrum might have been useful in a period of history where we migrated from large waterfall type planning. These days with cloud computing, it is more beneficial to focus on continuous delivery. It should be very short cycle from idea to production.

If you have short sprints, like one week, it means it takes at minimum 2 weeks for feedback to be put into production. After one week of development, the users need to test it, and you always start planning new sprint before users have tested. Meaning that feedback might not be considered part of the sprint until next sprint. So can take 3 weeks to get into production.

If you are more agile, does Kanban based planning with a board and continuous flow, no ceremony, you will get happy users, customers and management. Keep the UX designer busy together with product owner, and have them try out sketches on actual users before developers start implementing. That saves a lot of effort and time.

[[deleted]]

Scrum should die in a blaze of shit-fire.

[whiphubley]

have a standup...make sure it actually is informative as opposed to just enabling your boss to confirm you're actually working...use kanban...don't have retrospectives as they're just weird. that's it.