Agile is such a joke.
Posted by Delicious-Wasabi-605@reddit | sysadmin | View on Reddit | 172 comments
The theory is good but nearly every place I've worked they just want to track individual's work. Especially on the operations side. Like managers telling me to just put a feature in and add a few stories. Like why am just putting random work in a project. Shouldn't your architects, product team, PMs be reviewing work, planning the priority, and assigning to the right teams.
sir_mrej@reddit
The theory is good.
So say companies suck at agile. Stop saying agile is a joke.
ms4720@reddit
People say the same thing about socialism and communism.
dansedemorte@reddit
and captalism
ms4720@reddit
Yeah socialists and communists say that
BortLReynolds@reddit
Also people with eyes, ears and a functioning brain. A system based on the concept of infinite growth will inevitably fail.
ms4720@reddit
Still mostly communists and socialists, it is one of their big talking points. Mostly peaceful economics
dansedemorte@reddit
i'd rather be both of them combined than a maga/conservative.
ms4720@reddit
You do you, conservatives support freedom and rule of law. Socialists and communists support concentration camps, gulags, the great leap forward, the killing fields, and the list goes on. Do you enjoy looking at the blood on your ideological hands? Does it make you feel powerful?
BortLReynolds@reddit
Bro, the most infamous use of concentration and extermination camps in history came from a right wing authoritarian. Or are you going to sit there and seriously claim Hitler was a socialist?
I_FUCKIN_LOVE_BAGELS@reddit
mirrax@reddit
It's just like any open ended framework. Given enough flexibility, it can be implemented poorly or the flexibility seen as a panacea to Conway's law.
courageous_liquid@reddit
exactly, wait till you go back to the 90s before y2k and see waterfall
vagueAF_@reddit
Agile methodology is for software development, it's not really relevant for a sysadmin
DoorDelicious8395@reddit
Scrum more like I’m gonna scrum
Wonder_Weenis@reddit
Never miss an excuse to repost this
https://m.youtube.com/watch?v=a-BOSpxYJ9M&pp=ygUNYWdpbGUgaXMgZGVhZA%3D%3D
I don't think I've ever seen agile properly implemented for sys admin work. Software, sure, rare, but it does work if you actually apply the logic to your business situation.
awnawkareninah@reddit
It doesn't work when the job inherently means being a fire fighter. When my last "agile" team tried it and asked us to do points for anticipated support tasks, what happened is each sprint more than half of my story points were just "general IT Support and fixes"
pdp10@reddit
Scum is not a great tool for that, correct. One path is to make a single story for reactive response.
Smart management would make the connection that it's a good idea to minimize the reactive workload, with targeted proactive work. But it's rare to find that in practice.
awnawkareninah@reddit
It's really just rare to have the resources to do both at once.
bunk3rk1ng@reddit
We had a label in jira called 'unplanned work'. When asked why something wasn't finished we just clicked on the label to allow all the tickets we had to work on that were not committed to when the spring started.
Management then decided we couldn't use the label anymore.
energybeing@reddit
I like Kanban for sys admin work but as someone who has been the sole sys admin with a team of software engineers, Agile has been a life saver.
Being able to roll back deployments when issues arise that made it past QA is a GOD SEND.
pdp10@reddit
Why do you connect rollbacks to Agile?
Agile would have more of a tendency to fix-forward, while Waterfall would tend to want to roll back.
energybeing@reddit
That's true, it's more that Agile methodology makes tracking these changes more transparent when configured properly with your SCM, so it makes the process of rolling back less complicated than others.
ausername111111@reddit
40 minutes long. I'd like to watch, but I don't have the time.
Turbulent-Pea-8826@reddit
I will not miss an opportunity to repost this
https://www.youtube.com/watch?v=nvks70PD0Rs
So many places say they are 'agile' because it sounds cool but don't implement agile.
ausername111111@reddit
40 minutes long. I'd like to watch, but I don't have the time.
NeverDocument@reddit
We are an lean agile waterfall rapid application development shop.
I wish I was joking.
Soap-ster@reddit
I shall not miss an opportunity to repost this. https://youtu.be/oyVksFviJVE?si=twM4IMOlhQgZQE-1
wanderinggoat@reddit
so ITIL?
scataco@reddit
There's Lean ITSM, from which ITIL 4 adopted some I ideas I think
kremlingrasso@reddit
Never miss an excuse to repost this
https://youtu.be/IBZtTW0pXLE?si=_m_zCYOrk8fclKBj
Agile is a fucking cargo cult that corporations think if we pantomime through the motions somehow things will spontaneously not suck.
Wonder_Weenis@reddit
Reminds me of dickheads who think flinging money at stuff can fix anything.
neosapprentice@reddit
An “agile is dead” video from 9 years ago. And my company just adopted agile lol. Yiiikes.
Wonder_Weenis@reddit
The title is misleading, but the guy in the video is one of the OG authors of the agile manifesto.
The key take away is that if you allow a project manager to try and poke your star situation, into a square agile hole.
You are fucking up.
The not so common senses must be applied to the reality of the situation you're in, and adjusted to properly.
WayneConrad@reddit
Yep. I've rarely seen agile properly implemented in software either. Few teams who say they are agile actually are. Scrum took over, and although scrum can be agile, it often isn't.
So to those who say they hate agile, I can say: you have most likely never seen it.
Appropriate_Ant_4629@reddit
I'm starting to doubt that it even can be.
For decent employees, even in the best case, agile is just a mile annoyance of documenting the obvious.
For others, it's a great tool for sandbagging and making the most trivial tasks balloon to fill 2 week sprints.
Yupsec@reddit
What most organizations call "agile" is actually just the scrum framework.
I've worked at a company that actually implemented agile. The dev team would have a morning standup where they would discuss what they were working on, if they needed help with something, etc. I got most of my requests out of that meeting. The rest of the time it looked like pure chaos. Pure efficient chaos. Best dev team I've ever worked with. They were just allowed to build and change as the environment around them changed.
The very next company I worked for used "agile". So much dev time wasted. So many stupid requests that tried to predict the future. Complete waste of time.
xnode79@reddit
In all my years in Software development I have seen Agile being used correctly in one company and even there only for couple of years. It was beneficial during that time. Lead to company fixing its overall processes and ways of working.
whythehellnote@reddit
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Seems fine to me.
AbolishIncredible@reddit
In my experience agile usually means we’ve taken the worst aspects of 3-4 different delivery models and crammed them all together.
therealfalseidentity@reddit
Almost every team I've been on that has "agile" is just waterfall by a different name. Oh yeah, I'm a programmer.
anomalous_cowherd@reddit
Not only that but it's the same waterfall that 99.9 of waterfall projects use, i.e. one with no iteration and rework on the way down or back up. Just linear and based on initial assumptions.
therealfalseidentity@reddit
At one place, it was always funny to me because they'd get me to give an estimate on time to complete but I always doubled it for testing(they didn't have testers so it was always bad because I don't use a computer like a boomer). So always gave a padded estimate because almost every time I gave a real one I got burned. It would end up that the person who received the ticket would blow the estimate because they're an extreme slowbie and I didn't want to throw them under the bus if they've been decent to me and haven't done the same. Somehow, we were supposed to work on bug tickets too.
anomalous_cowherd@reddit
I'm a hopeless optimist. I used to guess how long it would take me, triple it to be more realistic, then triple it again to allow for project managers over promising and trimming due dates. That triple-triple tended to work out about right.
Calm_Run93@reddit
i've seen it done well. It was great tbh. But they had an agile consultant who would constantly go to war with managers who thought they knew better. Without that consultant they probably would have made a mess of it too.
It does work better on project work, but you can do things to make the day to day ad-hoc work affect things less. I wouldn't want to try and use it where there was no real project going on, or many all at once.
TheWikiJedi@reddit
You just need to become a high agency individual contributor
Sagail@reddit
Dude QA agile is stupid
GrayRoberts@reddit
Agile, much like communism, looks good on paper, and then: Oops, Stalin.
Time_Dot_6918@reddit
“living the dream!”
pdp10@reddit
Agile now has a reputation of being wildly misused by management. A victim of its own initial success, probably.
Run reasonably well, it works fine. Definitely better than alternatives like Waterfall. It's not ideal for devops or ops, where non-optional tasks can come up and need to be immediately handled. It's not ideal for teams that aren't relatively homogeneous, meaning that most of the team can take any particular story. But even in those conditions, it can often still work okay.
Signs that Agile isn't being run sufficiently well:
Different-Hyena-8724@reddit
Maybe for devs. But why do we need to fucking terraform a single SVI? The shoehorning of that shit so you can tell your cio buddies that you CI/CD got old really quick. And the fact that most these asshats can't articulate a reason to burn so much time on one off's helped explify the lack of technology leadership that exists today.
Stephonovich@reddit
I was told that in this case, you needed to continue to break the story down until the entire team was capable of the work. I thought that was idiotic then, and I still do. If you don’t know Terraform, then how far down am I supposed to break down a story of “instantiate new instances of DB foo?” Until there’s a task that says, “make empty files in the expected directory structure?”
ausername111111@reddit
My experience:
I'm in a meeting and I'm told we need an MVP that has these features. I commit to having it built and tested by the end of the sprint (2 weeks). About five days or so later some loud mouth on the standup says we shouldn't use the design I'm working on and instead use something else. I'm asked to stop and use that design in the first place. I spend a few days getting it stood up only to find out it doesn't support most of the requirements. I explain that the new design doesn't work in the next meeting. The loud mouth undeterred suggests something else. We spend the entire rest of the meeting relitigating why we went with the original design. The loud mouth reluctantly agrees. Now it's the end of the sprint and I've gotten about half of the original design tested. As I'm finishing up the loud mouth pipes up again and changes it again. At this point, this thing that should have taken a week to build and a week to test has now taken a month.
It seems like Agile is great if you don't have a culture where the person who talks the most and uses the fanciest words get the most respect. When that happens it turns into a litany of relentless testing so the loud mouth can keep having new worthless ideas, even if occasionally he's right. It's exhausting.
CAMx264x@reddit
Kanban has always worked well for me in every position I’ve worked NetEng>Sys Engineer>Cloud Engineer>DevOps, but it’s always been loose Kanban as these positions always have fires to put out that take priority.
MorpH2k@reddit
Yeah I think this is part of the core issue. Any Ops related team will have to respond to a lot of issues that pop up and needs to be handled now. You could probably have an agile approach to planned changes, projects and such but you'd still need to have some people just doing the regular ops stuff like monitoring and solving incidents. There will likely still be situations where you'd need to pull people from the agile-planned stuff to do triage.
Kanban would probably be just fine for it but going full agile is probably a bad idea. Agile is made for software development, and works fine for stuff like non-software product development if it's done correctly, but when you have urgent stuff popping up or don't have a clear goal to work towards, it's not really the right approach.
At least that's how I see it, kind of from the outside. I've never worked in an agile way but I've studied it in theory in school. It sounds good in theory if you have people with the right mindset, competent people in all the key roles and management that lets them do it fully without interfering.
CAMx264x@reddit
Kanban is Agile, while Scrum is used a lot more for modern software development with 2-4 week sprints. I work with dev teams who use scrum and it works well if you are doing modern development(full CI/CD), while I also work with a dev team who do semi monolithic deployments and it doesn’t work quite as well.
MorpH2k@reddit
Kanban is a board and related workflows, which comes out of Lean. Agile is the umbrella term for a way of working, based on the Agile manifesto and Scrum is a more specific agile methodology.
Any agile methodology would probably be quite well suited for CI/CD. My guess would be that CI/CD is more or less a direct descendant or product of different Agile methods.
LeadershipSweet8883@reddit
Kanban is also a methodology. You map out the current work process in a Kanban board and it has you track certain metrics to figure out where things are going wrong. It doesn't do sprints like Scrum, it's more of a continuous flow of work.
Maro1947@reddit
Kanban isn't Agile - it's a tool
CAMx264x@reddit
Kanban is a framework that falls under the agile umbrella, why would you claim it’s a tool? Unless you’re referring to lean kanban which uses lean tools with kanban?
Maro1947@reddit
You can use Kanban Board just as an organisaationational tool without it being Agile
I left board out when typing.
mirrax@reddit
A Kanban Board is a tool; Kanban the methodology that uses boards to track workflows while limiting the amount of work-in-progress is an Agile framework.
Zaofy@reddit
Yeah. My previous boss would constantly ask us why we would only assign half of our available time to „stories“ and tell us to plan at least 80% of our hours.
Then he’d act surprised because ops always takes precedence over new features and we didn’t finish half our assigned tasks. This happened repeatedly for half a year, it was agonising.
Much better now though. Still technically the same system, but our current boss at least believes us that monitoring, maintenance and incidents take up a lot of time when done properly and we don’t catch flak for doing our actual jobs.
MorpH2k@reddit
Good that your boss gets it. I think if you want to do agile for Ops, you'll need a large enough team in place to cover all of the day to day Ops tasks fully and then add whatever amount of additional people you need for the projects and let them do it separately from the Ops. You could still rotate everyone through doing Ops or project work if needed but it should probably be kept as separate as possible, at least if deadlines are important.
Zaofy@reddit
That’s pretty mich what’s happening. My oldest colleague an I are the most senior people in the team and usually one of us is the designated internal „2.5 level support“ for the more difficult cases whilst the other can focus on whatever project needs one of us to consult/implement. Whilst the rest can be more flexible in how much ops they do on a sprint, as long as it’s still somewhat reasonable. Since we both generally enjoy the whole ops part of DevOps, it suits us both.
Not perfect, there’s the rare all hands on deck emergency. But it’s likely as good as it gets without throwing out agile completely if I’m being realistic.
Fox_and_Otter@reddit
The way we do it is 2 kanban boards, one for project work, one for fires. It's definitely not perfect, but it works much better than anything else I have tried.
GOVStooge@reddit
It's a fad. Just like everything that came before it. Boils down to systems engineering. Every so often, someone comes up with a new language and process, that's just systems engineering with a mask on, then sells the crap out of it to executives. The the executives mandate it and fork over a ton of money for consulting, and training materials and courses.
It's highly annoying to the people doing the work
adx931@reddit
You should do what I did. Retire early and go live in the woods.
rsaffi@reddit
Hoping you never have to deal with SAFe.
Supposed to be "Scaled Agile Framework".
Realistically: Shitty Agile for Enterprises.
pm-me-your-junk@reddit
If it's well managed it's great, and it forces cross-functional/project teams to actually break down the work into smaller chunks which in turns leads to better planning and smaller feedback loops - so you don't necessarily end up being forced to implement something that everyone worked out was a bad idea \~12 weeks ago.
But people in charge need to actually take it seriously, and have a very deep understanding of how it's supposed to work which they almost never do. Most PM's think it's just a case of; you make JIRA tickets, someone else fills them in (if they're filled in at all), and ask every 24-48 hours for updates on them even though the PM has no idea what those updates actually mean.
Marathon2021@reddit
Just to add onto this ... "agile" can't simply be an excuse for poor planning or "we don't want to have to really think about anything" and flying by the seat of our pants. If you have a good general idea of your approximate destination overall, breaking the work down into 2-3 week sprints isn't bad.
If you don't know what the fuck you're doing, then "but we're agile!" is just trying to buzzword over laziness.
(also, agile can work fine for SW dev teams but not always quite as useful for sysadmin-type things)
mixduptransistor@reddit
This is the problem where I work today. Agile is just a way for teams to get around having to make tough decisions. Put all the features and changes you need into a story and we'll get to it! Except no one is actually coordinating what gets pulled into a sprint, devs just get to pick the stories they want or the bare minimum to get past what their manager is chirping at them to finish. Meanwhile critical stuff never gets done and we ship half broken software or on the operations side have huge gaps in automation that we have to paper over with manual processes
pdp10@reddit
The team is perfectly entitled to make its own stories. Normally, you want to budget refactoring and documentation into the "regular" stories, but it's okay to have meta-stories.
mixduptransistor@reddit
My point is what happens here is because no one is doing any planning, and devs essentially get to pick and choose what they work on, is that often requirements are not met. We use "agile" as a way to not work on things we don't want to work on. That saying stories X, Y, and Z are required before release is often dismissed as "we're agile, we are only planning for the sprint ahead of us" and then also setting a hard date for release
It leads to untenable situations where a product team pushes something to be released that does not meet all the requirements, usually missing requirements that the operational side of the house wants like appropriate logging or data resiliency that is not fun to work on and is not a customer facing feature
pdp10@reddit
"Requirements" is largely a Waterfall concept. The top priority of Agile is having the product perpetually in a state where it can ship, with respect to existing functionality and quality. If Product or leadership isn't happy that their "must-have" feature didn't make it in, then that's rather orthogonal. Now, there's no point in shipping if the product is sub-MVP, but getting to MVP is also a subject of its own.
Once, I sponsored a story to revise a major product stack of ours to be multi-environment (or arguable multi-tenant). The devteam rated it an Epic, put it on backlog, and never did anything about it. Outside business changes made the subject somewhat moot, relatively soon thereafter.
That was a disappointing outcome. I hadn't wanted to be prescriptive about the task, but by making it one big feature, the task ended up being seen as huge, monolithic, risky, high-opportunity-cost, and low-RoI. I should have strongly considered doing architectural work in order to re-submit the story as smaller, less-demoralizing tasks.
We've found that tracing/logging is usually straightforward for us to MR, at least if the task doesn't require major architectural decisions like downselecting a framework or vendor. High Availability is harder, but ops tends to know what that looks like exactly, and what it wants, enough to figure out the steps to get from here to there.
Where I went wrong with my multi-environment feature, besides probably scope, was that I deliberately hadn't sat down to decide exactly how to do it. Straight developers rarely have the background knowledge to be better architects than the devops.
mixduptransistor@reddit
There are minimum requirements to be ready to ship in our compnay. For example, it has to meet certain architectural standard. It has to be compatible with our existing disaster recovery procedures, or, have its own. It has to have protections against cross-tenant data leakage, or be scanned for common security issues like SQL injection. The product owner and software engineers are not the only ones that get to set the standard by which something is "shippable". That's what I mean by requirements
The idea that setting even a minimum standard of security, architectural, and feature requirements before something is an MVP or shippable is "not Agile" is why I fucking hate Agile and its disciples. What drives what's an MVP is generally date on the calendar, not the content of the application
pdp10@reddit
Then you can choose not to launch on the deadline, just like Waterfall.
So you have a problem with the definition of MVP, and probably with who sets it. But it's not about "MVP" and its baggage, it's truly about divergent goals with stakeholders.
We're not usually dealing with de novo products. Imagine that a product has been shipping already. Leadership's goal is to be able to release version 3.0 on April 1st, so they can have a communication with customers and an accomplishment for themselves and so forth. A product team wants to veto, on account of there not being enough features. Marketing and PR agree, that without more features, it will be hard to write enough bullet points as part of their work. The infosec team says there's not enough infosec. Ops thinks it's too fragile.
We don't even have to debate if these teams are right, because the most relevant factor is that version 2.2 of the product is currently shipping without those things. Do you create an "artificial quality gate" for 3.0 based you're inflexible? Or does everyone agree that 3.0 is better than 2.2 in the ways that matter, and get with the business of iterating?
Marathon2021@reddit
It really has become an excuse for a lot of overall laziness, unfortunately.
Alternatively, one of my favorite phrases is "bikeshedding" - we spend more time providing opinions on the details of the design bike shed in the parking lot than the details of the nuclear reactor itself (because that's really hard, bike sheds are easy). There's even a name for it - https://en.wikipedia.org/wiki/Law_of_triviality
Djglamrock@reddit
I like that term, never heard it before but it makes sense.
TimotheusL@reddit
The thing is, you are not working agile in your shop. If you execute any idea or framework poorly it of course fails but it does not make the framework bad. E.g. email is trash, our spam filter catches 100% of valid ones, so I don't write mails.
mixduptransistor@reddit
Sure, but a system is what it outputs and it's obvious that the vast majority of companies doing "agile" aren't really, but that still means the church of agile has failed overall
Calm_Run93@reddit
it does definitely work better if you've got a few people who have a longer term idea of where the product is going and how all the little bits done in the sprints might fit together into a bigger picture. That can be a technical product owner, an architect, or a senior engineer, but you need someone doing that duty.
DehydratedButTired@reddit
Literally anything that is well managed is great. Agile is being sold to companies, by consultants, as genius micro management. Agile has been hijacked to be used for any project tangentially related to technology and to push timelines to the extreme.
frenchnameguy@reddit
The worst is when there are two tickets that are the same thing and they ask you for updates about each of them. Like, I get that you’re not technical, but maybe we can go out on a limb and conclude that “fix stage DNS” and “remedy stage DNS” are redundant, yeah?
No joke, I have at least one PM who would with a straight face ask me about both of those tasks right in a row.
pm-me-your-junk@reddit
Yeah they're clueless a depressing % of the time. I've had one really good TPM who was a former developer and could understand what people were saying, and it made SUCH a huge difference.
WSATX@reddit
This is getting old this "against Agile without nuance" simplified way of thinking...
Sorry if your hierarchy wasn't able to implement agile correctly, or sorry if your business model works better with some good old waterfall planning.
Juste be aware There are places Where Agile Works
Djglamrock@reddit
Agi is only good for crit and I’d rather have sustained DPS than it bouncing around unexpectedly because of how RNG works with crit.
purefan@reddit
Not syadmin but we do Shape Up, after a year dropping the ball it looks like we're finally getting the hang of it
jake04-20@reddit
Over covid we did "SCRUM" meetings and it was one of the most half-baked things I've ever seen implemented at this place. Literally all it was, was get on a call, and say what you did yesterday. That's it. In addition to that we already tracked our work in tickets, and had a separate Teams Planner/Tasks project board too. It was so meaningless and convoluted, and my boss still reached out to me individually on Teams to ask for project updates, even when all my progress was updated in the ticket, on the Planner dashboard, and in the SCRUM meeting.
moffetts9001@reddit
I feel you; my org uses a similar system and they’re trying really hard to make everyone on the IT side (from architecture, to developers, to ops, etc) follow the same process. On one hand, I get it. It forces everyone to pull in the same direction, everything is planned and documented, etc. On the other hand, golly is it a pain in the ass for teams that are mostly “keep the lights on”. Unless they are heads down on a project, constantly feeding AZDOs just feels like pointless overhead.
pdp10@reddit
Many organizations try to optimize around this by making Sprints of the maximum length, one month. It's got downsides of its own, considering that it's extremely undesirable to add tasks/Stories during a Sprint.
In theory, the team has just standups, and then the planning and retrospective meetings for each Sprint. Not counting standups, that's supposed to be two or three hours of meeting per week, maximum.
1a2b3c4d_1a2b3c4d@reddit
Agile shouldn't be used in an Operations process, where you do what you need to keep the systems up and running properly. ITIL, with its ticket tracking framework and incident management, is best applied to Operations. Not agile.
Too bad, Agile is pretty good when implemented correctly in true development environments.
Ckirso@reddit
Agile shouldn't be part of infrastructure
Tovervlag@reddit
In my organization it's a synonym for "we don't want to plan anymore".
a60v@reddit
This. Agile is great for people who don't know what they want and are satisfied with half-working, poorly documented software.
Strange-Ad130@reddit
Agile is a highly effective method of getting things done efficiently and effectively. Unfortunately, the company adopting this must actually do it right. They must know it well, ensure everyone in the company knows it well, and must never cut corners. Too many companies (in my experience - all of them) suffer from giving everyone the impression cake tastes bad because the only time they ever make it they decide sugar and eggs aren't that important and don't see the point in waiting more than 5 minutes for the damn thing to bake.
jamesaepp@reddit
I've never strictly worked under Agile (yeah, I recognize that's an oxymoron - strict agile). But from what I've heard about agile and paired with the OP, I'm reminded of this:
https://www.computerworld.com/article/1555366/opinion-the-unspoken-truth-about-managing-geeks.html
Selected quotes, ctrl+f'ing for "organize":
Stephonovich@reddit
My god, that is accurate. 2009, eh? Some things never change.
jamesaepp@reddit
No, some things change. Nowadays you can hire AI assistants for almost no money at all.
Stephonovich@reddit
I also found out you can connect an LLM to Jira, which I am very excited about. Finally, a good use of AI – creating bullshit tickets with flowery language so I can get actual work done!
dansedemorte@reddit
amen to this.
OldeFortran77@reddit
It struck me recently that companies don't fail necessarily because of bad management decisions ... but instead because of bad management decisions that even their self-motived workers can't work around or otherwise overcome.
I waste a lot of time doing something unnecessary, or going through the motions to appear to be doing it.
raxthehusky@reddit
As a Dev with an actually agile team and active PM's. It's nice.
sir_mrej@reddit
A good PM is a godsend.
A bad PM makes EVERYTHING worse.
n0radrenaline@reddit
Where are y'all finding these good PMs? I've only ever had one who even bothered to get to know how the product worked, and he was kind of a jackass. I miss him now, though; he got replaced by an offshore worker who may actually just be an inbox forwarding rule with a 12-hour delay built in.
Yupsec@reddit
I think the trick is finding a PM that has actually been in the trenches. Our current PM bounced around in IT; Help Desk, SysAdmin, Dev, she was even a DBA for awhile. Eventually she realized she preferred working with people more than putting fingers on the keyboard. Probably the best PM I've ever worked with. Her peer though, completely useless and came from a sales background...
XCOMGrumble27@reddit
Seconding this. The absolute best PM I ever had could jump into the trenches and run circles around us if need be. Working under that man did a lot for my career.
AGsec@reddit
They usually are hard to find because they get paid extremely well. Go on indeed and look at PM job postings. a $90k/yr PM is little more than an assistant. a $200k/yr PM is what you want, but who wants to pay for that?
energybeing@reddit
100%! For agile to work, you absolutely need a PM who knows how to delegate tickets and effectively and efficiently handle team communication/standups.
elitexero@reddit
Wait, you mean there's PMs out there that don't live on the other side of the world, try to trick me into doing their PM reports and think the best way to get things done is to ask me every day when a large project will be done?
You mean to tell me when asked for an ETA during the initial discussion steps of a massive project and I provide a realistic one, just saying 'ok I'll put <6 months earlier than I gave>' isn't normal?
Well shit.
kex@reddit
"So, how many hours is a point?"
raxthehusky@reddit
Waterfall and Scrums get real fatiguing on Gov projects.
flushy78@reddit
Try being at an org that doesn't think Agile dev teams need project managers. Or Analysts.
raxthehusky@reddit
I certainly have been. I had one where we built the plane as we flew it. What started as 5-10 on the platform rapped up to 1500 over the course of a year during covid. I was functionally the sole developer and expected to to basically do all the project planning as a BA just by having a conversation or 2 with some team lead. Needless to say I traded up to a position that paid double for less work.
Which is sad cause that was one of the best bosses I had and my coworkers were awesome.
XCOMGrumble27@reddit
Given the persistent outcomes I keep hearing about, I question this premise.
neosapprentice@reddit
My job started using agile 6 months ago. It’s a bit of a joke because the manager has no idea what our work entails soo when it’s time for estimates, everything is 2-3 story points. Stuff that couldn’t possibly take 1 full work day, let alone 3. 3 story points. And no pushback. Soo there’s no incentive to accurately size stories. You’re better off fluffing your stories and having an easy sprint than accurately sizing and then being asked to help your team complete their 2-3 point stories.
kerosene31@reddit
Agile is a useful tool that gets misused and misunderstood.
A good agile team would be 8 Java coders who all do the same thing, and have a bunch of smaller tasks coming in.
When they try to force agile across different IT teams and skills, it falls flat. By definition, your agile team should have a similar skillset and be working on the same things. If Person A is out sick, B can pick up the task.
However, usually what ends up is a team of networking, sysadmins, devs, maybe qa testers, etc. They are all working towards the same goal, but in very different ways.
Agile is also about self managed teams, which 99% of companies want nothing to do with. So it turns into a micromanagement nightmare. The higher ups just expect everyone to work twice as fast and get double the work done thanks to the magic "agile" framework they half paid attention to during a seminar.
I would say, you don't really dislike agile, you dislike the horribly bad implementation of it. Again, it can be a useful tool, but so many agile teams have no business being together.
Agile really has no place in the sysadmin world. It is well suited for programming teams.
steakmane@reddit
Try SAFe. It’s my current hell.
dasunt@reddit
SAFe is an acronym: Shitty Agile For Executives.
jahujames@reddit
I feel your pain. I just left an org that used SAFe, it was a huge pile of shit.
dasunt@reddit
Agile is like a successful religion: flexible enough to adapt to the local culture and be what people want it to be.
Sometimes the local culture is dysfunctional.
vCentered@reddit
Agile is like communism.
Everyone talks about how great real Agile is, in theory.
Nobody does real Agile.
daerogami@reddit
This is an annoying refrain. Just say you have never seen what you deem to be "real" Agile. Plenty of teams are making a decent go of it.
varky@reddit
Agile doesn't work in operations as a method of planning work because 90% of the work depends on external teams or vendors, or appears outside of the planning as additional requirements, tickets and "emergencies".
TheDawiWhisperer@reddit
Agile is something you train people on to tick a box but never actually use properly
supple@reddit
Sounds like poor implementation and education about how to use the tools. Agile doesn't always fit with operational services well, but there are most definitely ways it can be effective for project based work. Measuring and predicting work is one result or aspect of the whole and shouldn't be the only intention. Just adding "some stories to a feature" without a philosophy or method behind it won't work well. PMs can play different roles depending on the project or type of team they work with. For operational work, project managers can be used more as guides and empower the team to self-manage their tasks as they help coordinate interdepartmental tasks, track work, timelines, risks, etc being done by the team. They should be working alongside your team - they shouldn't be reviewing, planning, creating tasks, then assigning them out to the teams without your team's input. Having them work in a vacuum like that will undoubtedly cause issues.
Geminii27@reddit
No-one knows how to do Agile in a way which actually helps. It's just used to micromanage and to jerk programmers around.
chicaneuk@reddit
How do you work under agile framework for project work, when your work also contains unpredictable levels of BAU work which can be up or down to massive degrees every single week?
Hacksie@reddit
I'm an architect on project work, and this is one of the more common risks I raise on projects, given sysadmins often live in their own team. Either carve out a dedicated resource for the project so I can predictably plan their availability, or accept that bau will constantly be smashing over the top and shut will get delayed. Even if I have to up resource the bau team, there needs to be sysadmins dedicated to the project. It doesn't have to be 100% of their time, but I need it to be, I get this person and must be doing my work as 1st priority for X amount of time.
chicaneuk@reddit
Good to get that perspective.. thanks.
Hacksie@reddit
Note, I don't always win the argument (though I do always make it). But I do often get to say 'I told you so'.
Izual_Rebirth@reddit
Any sort of framework whether it be Agile or ITIL is best used when you pick and chose what bits to use. It's best not to take it too prescriptively. Take the bits you think will be useful for your organization. Ignore the bits that don't.
PositiveBubbles@reddit
Yeah, that's why ITIL training isn't a standard and even mentions Agile and DevOps in v4, I've been told. I got my foundations 2011 in 2014, so I really should renew, but I'm less service management these days
PositiveBubbles@reddit
I'm still getting used to it. We follow Agile in our team for projects and ITIL for standard ops/Bau. Apparently, we're advertising for a scrum master. My former manager preferred waterfalls, but his team needs to align with agile with the rest of us.
I've learned after all this just to clarify if I'm not sure and do the work, and it'll take as long as it takes. Yes, things change in terms of technology and methodology, but I try not to get too emotionally or mentally invested
energybeing@reddit
So agile sucks because your management refuses to follow its policies?
I actually thought there was going to be a legitimate criticism of Agile here but if your management won't follow Agile practices, then you aren't actually utilizing Agile, are you?
Additional-Moment922@reddit
Totally agree, it's a term to cover JFDI.
flummox1234@reddit
It's the Communisim of project management. /s
Izual_Rebirth@reddit
The project manages, like all other men, love to reap where they never sowed.
FerryCliment@reddit
I'm a Cloud Sec Eng, coming from a SysAdmin/SRE background.
I fucking hate agile, I get the sales, and dev is all about being agile in adapting to client shenanigans, but Security , Administration and Resiliency, is a fucking steady wall you need to build and plan with time, clear goals, resources and objectives, It takes time and commitment before the results start to kick in.
The issue is companies think "we are a agile company" so everyone must play by our rules, and then you have Sec/SysAdmin or SRE, having to play along with Devs, Sales.
Its not the same maintaining a CSPM, MultiCloud K8s or a huge park of Hardware assets, like Devs push commitments into the repo, or HR hire and layoff people.
Bring back Waterfall atleast for Security, impossible to hit good Compliance/CSPM scores with so much changes like a pinball machine
enigmo666@reddit
In my experience, aglile = a way to allow for infinite scope-creep
Most infrastructure projects require fixed goals and careful planning; what are we building? Why? Is this the best solution? When do you need it? What's the budget? What's our Plan B? What's our rollback plan if things go wrong? You can't do all that on shifting sands.
foofoo300@reddit
try asking for accountability for their work ;)
jhaand@reddit
Agile goes about creating faster flows of requirements to delivered functionality, make the work more predictable and find out what the customer wants.
So the new functionality should go through the process you just described. If it's really important, then all stakeholders can implement this with high priority. Most of the time a rando manager that wants something new, can just go to hell.
Feeling_Inspector_13@reddit
to be honest, alot of sysadmins are lazy as fuck and its well deserved.
yeah_youbet@reddit
Agile is great when you have actual buy-in from leadership who take the implementation seriously, and not just a bunch of ego-driven MBAs who take backdoors and cut corners because they want to feel important.
SirEDCaLot@reddit
Nothing wrong with Agile as a concept.
Problem is for Agile to work well you need buy-in from the whole org, on the whole system. And that means people (managers especially) required to do things differently than they want.
So what usually happens is a manager will 'adopt agile' but really just means they'll apply Agile buzzwords to whatever they were going to do anyway and it just becomes more overhead and bullshit to micromanage employees.
Perfect example is the daily standup. It's supposed to be a few mins, 15 mins absolute tops. Manager is supposed to keep things focused and avoid unnecessary and irrelevant discussion. Yet how often do you have a manager who uses the standup to parcel out work assignments and demand detailed updates from everybody? So you end up with a 45min waste of time that would be 5mins if kept focused, that's the same as the old 'morning meeting' but now we (incorrectly) call it a 'daily standup'.
opus-thirteen@reddit
I got forced into Agile shit ~ 4years ago with a new CTO, and it has been a shitshow ever since.
The QA people log issues correctly to call out flaws they find, but after that... it's all useless comments and meandering direction.
roboto404@reddit
Our company did agile for network integration project. Total clusterfuck. The project team just sucked, not necessarily agile itself.
dansedemorte@reddit
agile's only use is for start up companies just long enough to to either fail or sell out to a real software company.
CAMx264x@reddit
I’m curious what “real software companies” use?
ExceptionEX@reddit
who is trying to use agile for sysadmin, that seems a odd method for something like sysadmin work. that is silly.
gumbrilla@reddit
In general agile is fine, but there is a trap. Team A uses methodology A, they are passionate, resourced, skilled and adopt it, and achieve great success. Books are written, seminars given, the new solution is found. Team B, C, D are early adopters, also achieve success, they are also passionate etc. , methodology/technology/architecture.
Crappie company F wants in, Teams are overloaded, turned-over, unempowered, and they don't get the same results! Colour me shocked!
Anyway, Agile is fine. In part its a list that's prioritised of the planable work. What's not 'planable' in Sys Admin? Daily tasks, checks, incidents under SLA. Building new server? Sure.. fixing the backup server, not. So, after you've subtracted all the non planable work, that's what left. And if a P1 walks in even less planable work gets done. Over time the actual discretionary effort available becomes clear, and you can have a proper conversation.
If you are allowing Product Managament to dictate your keeping the lights on effort, then that's a world of hurt. I would simply make it non planable time. If I was in big corpo land, and I somehow was absolutely forced to, then every single time we didn't do stuff in would raise a formal risk, with Product Management called out.
Tldr. Honestly, I don't care what methodology, rubbish management will screw it up, good management will make it work.
vermyx@reddit
This is poorly managed. When implemented correctly it is great for projects where you have well defined stories. If your manager is telling you to add a feature and add stories, that is not how it works. The party asking for the feature adds the story and the team breaks the story down to tangible items to complete it and decides who works on it.
Oflameo@reddit
No, that's waterfall.
badlybane@reddit
It's 10 times worse if PM is non technical and wants you to eli5 the issue and its complexities then be happy with his judgments. Which are often likely wrong but some other Jr tech they like said something and they latch onto that.
naszrudd@reddit
Agile is great for project/ development sort of task. Things went up in flames when the management decided Operations to practice Agile as well.
notHooptieJ@reddit
thats no actually agile, thats just using it as a title for micromanaging.
Sasataf12@reddit
So is that a problem with Agile, or a problem with your managers?
fuckedfinance@reddit
Yeah. This is an "OK, what are we taking out" conversation.
Old_Acanthaceae5198@reddit
Nah, you're and or your team is just bad at it.
phobug@reddit
http://www.extremeprogramming.org/
This is the original unadulterated for the corporate world.
matt95110@reddit
Agile is dogshit. Even if implemented properly it is dogshit.
Fuck Agile. It is a technical debt generating machine.
Sasataf12@reddit
It generates tech debt IF you let it generate tech debt.
It's like saying GitHub is dogshit because it generates abandoned repos. Yeah, it does if you let it get that way.
matt95110@reddit
Everyone lets it generate technical debt.
Get it done in this sprint no matter what! Fuck fixing it later because there is no benefit to doing it.
GitHub is dogshit too for other reasons.
Sasataf12@reddit
A poor worker blames the tools.
matt95110@reddit
I blame shitty management and paper PMPs with real estate experience.
Sasataf12@reddit
Exactly...blame them instead of Agile.
matt95110@reddit
But fuck agile no matter what, it’s dogshit.
_RexDart@reddit
Agile is a great way to wind up with one-third of a usable product by the time the money runs out
Iceman_B@reddit
I don't think 'agile' was ever concocted with ad-hoc, operational tasks/teams in mind.
Also, yeah couple that with shitty management and you get this. Sorry to hear OP.
homelaberator@reddit
If you're actually doing it, it's good. The problem is usually the organisation saying that they are doing whilst doing a bunch of things that aren't.
The significant thing about agile and adjacent "methods/frameworks/paradigms/etc" is that they start with an empirical mindset rather than a reductionist/deterministic one.
cjcox4@reddit
Like most "methods", the implementation can vary. I find that most don't really do "Agile", but some sort of chaotic thing that's not too far from just merely "stand up" and "contracts". Which, btw, may be all that is needed for most organizations.
Some of the places I've worked had daily standup with contracts (what you MUST deliver on that day). If it gets "loose", then people will not give accurate data about their status and it all becomes a mess. But if you hold everyone to doing what they "said" they were going to do... IMHO, this works ok.
Release management? Still a big problem. All of these "things" usually assume the simplest of scenarios. They don't work with multiple interdependent entities in flight with changing "deadlines". Arguably, nothing works well there. Why? We make assumptions. But because those "in control" make "business decisions", many times you are forced to do a lot of rework (which introduces error, etc, etc).
Life as a former release manager.
As weird as it sounds, I probably did this best with older tooling (stuff nobody uses anymore). New and shiny sometimes isn't best.
Dry_Amphibian4771@reddit
Every early morning stand-up I just have the worst morning wood and everyone can see it through my khaki pants lol.
SpawnDnD@reddit
I detest it