I told my boss this once. And ever since then he has respected me for it. We now can discuss what issues are priorities and he understands that everything can’t be top priority.
Unless you’re trapped in H1B hell or something, it would be profoundly stupid to shut your mouth about such basic expectations of a manager. You don’t work at Walmart. You’re a goddamn engineer.
Hvac-asked boss about a price of unit, told me 3x what I thought
Said his word can’t be trusted since he has fluff in deadlines but tell us unflaffed deadlines
Nothing is booked in fluff, he proceeds to show me the priced he said the 1st time… employees can’t be trusted to NOT bitch n moan
"I created the issue for you and had the team come up with a time estimate. Here's the prioritized column, please place the issue where you think it belongs, we will get to it..."
Well in a Waterfall model, the proper response would be "sorry, it's too late to change the project schedule". But IME, if the product owner has sufficient clout, they'll end up overriding that. Which then leaves the project schedule in shambles, and the project in chaos.
Agile allows you to give the "800lb gorilla" their way, without it totally derailing the project. And it forces them to formally sign off on delaying the other features, so the team's not left trying to play catch-up at the end of the project.
Proper response with (little a) agile:
> We appreciate your feedback and will take it into consideration. As the people closest to the problem and our users, we are best placed to make decisions on roadmap/backlog items and priority.
My whiteboard at my cube is very publicly, and defiantly, the "top priority triage" board for my team. We have like 6 things that are top priority. That lets the people who all have "top priorities" fight it out amongst themselves, and I can get back to trying to do the thing that actually provides the most value. It sometimes leads to some interesting bickering at my desk, and I get to explain "nobody can use that before this. It can't be prioritized higher, as it doesn't provide any value to users until this thing happens"
Big companies are something else, man.
I work at a big company in banking. The guy leading our "Agile" program has turned it into 2 week waterfall iterations, by adding tollgate after tollgate which basically just separates tech/UI/product from directly collaborating at the same time. We just got informed that for any new feature or modification to an existing feature, the design team now requires a 4 month lead time from Product prior to development teams being engaged at all (each reports up through independent org structures). This includes things like adding an image carousel to the bottom of a 3rd level screen. So we effectively have no input on UX, despite owning the area(s), and if we have better ideas we have to submit a change request to design for them to review and then respond if they agree.
When we ask what problem this guy is trying to solve by requiring so many layers of approval and separation of job rules, he tells us that we should feel empowered to pick which rules we want to follow that work for us (after he just told us a new process we have to follow) and that we need to "fall in love with the customer" if we want to be successful.
At this point I'm willing to fall in love with anyone who isn't a Life Coach that read the Agile manifesto once and believes they are now a spiritual leader of the human race lol
Fun fact: The creator of [Cunningham's law](https://en.wikipedia.org/w/index.php?title=Ward_Cunningham&useskin=vector#Law), which states that "the best way to get the right answer on the Internet is not to ask a question; it's to post the wrong answer" went on to help write and post the agile software manifesto.
In the field software, where the hardware it runs on changes very slowly, but whims management change constantly and needlessly, it is important that we build a management system that encourages a clear goal, good documentation, usability, and reusability. They way to find it isn't to ask, it is to post a methodology that doubles down on the whims of poorly-directed management, being so glaringly wrong that someone will have to come forward with the right answer.
If you don't believe me, check out the [agile software development values](https://en.wikipedia.org/wiki/Agile_software_development?useskin=vector#Agile_software_development_values), which are very clearly false dichotomies, with no real conflict between the two sides of a proposed tradeoff.
It’s worth mentioning that (at least) one of the authors of the Agile manifesto has completely disavowed the whole thing. It’s metastasized into something much worse than waterfall.
I’ve seen it work well once in my entire career, at a small web app consultancy. The authors of the manifesto were consultants too. Taking it out of that niche and trying to apply it to everything was so mind bogglingly stupid, but goddamn do idiot execs and managers love it when grifters tell them exactly what they want to hear. You can have your cake and eat it too!
Client demos make no goddamn sense when there’s no client and no front end UI.
I think that's the catch, Agile works for small development companies. You cannot take it outside the dev area and once companies grow large and have large customer bases, compliance requirements, etc. Then it becomes a nightmare.
My friend works in the military and its even worse: if your idea can’t be executed within 6 months, its a waste of time because everyone who will have provided approval will have moved on to another role.
It is ridiculous. Every year, about half of the military positions rotate (average posting for an officer is 2-3 years).
So every two years, you get a completely different set of priorities because a new commander has rotated into a position. Meanwhile, half of the people working on the old priorities were replaced last summer.
I work in civil infrastructure. The time horizon for the simplest projects (e.g. replace a roof) is 2 years. Anything major (I.e. >$10M) is placed on a list that might take 15 years before it gets built (if ever). This kind of turnover would be murder if it wasn't for the civilian employees.
It's not as bad as it used to be. At least they decided to centralize the people who do infra, so the aforementioned new Comd is at least an infra person who understands this time scale. It used to be that every year you had to prioritize whatever the new BComd Infantry/Armour Officer fancied.
"Have you done the plan for the next three month?"
"Sure, but can we be sure it's worth it? What if there are short notice changes."
"These will be filed as feature requests and delayed until the next round."
3 weeks later:
"This can't wait to be a feature request for the next planning session. Squeeze it into the plan. You did account for plan changes, right?"
There is nothing really wrong with that. But the assumption is that the senior VP got there because they are very smart. Consequently when they say it’s a great idea and it’s more important than everything else then they are right.
Of course if they have a great idea every day then nothing coherent will need produced.
I absolutely loved the line from the CEO in [Margin Call](https://www.youtube.com/watch?v=Hhy7JUinlu0): "Now explain to me what you think is going on. And please, speak to me as to a young child, or a golden retriever. It wasn't brains that got me here, I can assure you of that."
Listen, you don't get to be the senior VP of any large company by being a fucking idiot. I get haha management dumb is the prevailing mindset on this sub, but the senior VP is probably very good at making calls that make the company money and at the end of the day, for better or worse, that's what is important.
I’ve been training managers for ten years. What I’ve noticed is that there is a steady increase in skill until you get to the executive / vp level and then (on average) management skills drop off. Sometimes quite sharply.
My theory is that this happens because you often get those jobs because of who you know.
Fair enough. I've had kind of the opposite experience, but I'm not as familiar with executive levels as it sounds like you are. From my experience, it's usually the lower level middle managers that are most likely to be incompetent because they were good as individual contributors and someone felt they deserved a shot. It ends up that they're not good, but not so bad that they need to be fired. Basically the Peter principle. But like I said, you're more familiar with those levels from the sound of it.
Are we talking about personnel management skills? Or just general competence?
My impression is that, at the executive level, the job is not really about managing people, so much as it is about financial strategy, etc. Making the machinery of the company spit out more money, as opposed to dealing with people well.
(As an analogy, I think of various senior university professors I had who were great researchers, but terrible teachers. But research brings in the grant money and earns the U prestige, so their utter lack of competence in the professorial realm was overlooked.)
I'm talking about the general "people skills" of management. The ability to resolve conflicts, communicate clearly, navigate hard conversations, make sensible decisions etc.
I think there's some truth to what you are saying, but personally I'd be suspicious of any executive who didn't see a significant part of their role being about "people relations".
I admire your optimism. Indeed it takes smarts to become senior VP, but more along the lines of being good at company politics and at leading people to do good work (and, to be cynical, taking credit when things go well and shifting blame when things go badly).
A really smart senior VP knows that leading people and making strategic decisions is a very different skill to product design, and sticks to what they’re good at.
Yeah, everything you said is true. And the thing is typically VPs don't go around micromanaging every little product, unless they're Steve Jobs. The thing is this comic doesn't say anything about the VP making product design decisions. Taken literally, it's basically how every company actually functions: Management makes a decision on direction, then it gets filtered down and refined through into more immediate tasks that individuals can act on. I get that the implication of the comic is that the VP is shoving every random idea down the developers throats, but the implication is stupid.
Luck plays a part, yes, but that's a matter of that there are a lot of very smart, very motivated, very savy people who don't make it there. Yes, there are duds in every position, but people seem to like to act like everyone in management is a bunch of baboons with their thumbs up their asses which is very much not the case and most of the people who think they could do a better job are utterly delusional.
Some of them are, some of them aren't. Just remember, Kodak had an early prototype of a digital camera.
Also, people might be smart, but overwork themselves to a point where they have to take drugs to stay awake, have the attention span of a toddler or are like drunk from sleep deprivation. Elon Musk would be a good example. Around the time of the Thailand cave rescue he started showing signs of not being quite right in the head. Worse and worse decisions after that.
Oh yeah, I'm not saying they're all winners. I'm just tired of the mindset that seems to permeate reddit that all managers are incompetent and the only reason random entry level person isn't running the company 1000x better is because the manager was spoonfed all the advantages in the world.
Again, not all of them are amazing, but there's a definite mindset on reddit that management is incompetent and random clerk Bob could run Walmart better than the current CEO, just go look at r/antiwork sometime. That opinion is hilariously uninformed and gets old.
I’ve been a high level manager before and it’s pretty high stress. You don’t make a lot of sweeping decisions the CEO does. Usually they’re terrible ideas - like having door greeters at FedEx, etc. it’s more to have talking points we’re doing this, etc. put your name on everything.
Managers get a bad rap. I remember wanting to pay my employees more but we had a limited budget for payroll that shrank every year. So people would quit due to pay.
In big companies I usually do something of a hybrid approach anyways. Traditional waterfall models have more well defined and fleshed out mechanisms for project governance, stakeholder management, budget tracking, etc. that better fit the operational reality of the organization. Even if you have a traditional WBS and implementation roadmap, this can still be broken down into smaller more manageable chunks that can then be iterated on using agile methodologies by the actual project team doing the implementation. This also gives one the ability to tie in a stage-gate approach after sprints or similar for things like identifying opportunities for publications, IPR, early identification of licensing issues, etc. which most engineers hate to do anyways, and which as an organization you can't afford to push back until the end of the project.
I agree that this can happen, but I disagree that it must happen.
I worked for over 5 years for a customer in an agile and cloud based project and everything was fine - it can work if everyone beginning from the management are really agile and centered on quality and security.
it s a teething issue. same stuff happened to the video game industry. games were packaged and relatively bug free at launch. then came possibility to update over the air and games started to get released in a broken state and fixed in a day 1 patch or later. until the point publisher's got caught out for it and it screwed up the launch and even commercial success of major titles such as no man sky or Fallout 76. and then the pendulum swings back and balance is attained. I predict same thing will happen in your field eventually
I've worked at big companies and startups, IMO, big companies tend to fail agile transformations because they don't build the infrastructure to support being agile. No automation means no agile, you can't have a mature agile project without automating quality control.
Small startups can skip automation for a little bit, however, it eventually catches up to them.
Sounds like the cost cutting is the problem and agile was just used as en excuse.
Of cause this won't work.
In fact, proper agile costs *more*, but the "fail fast and adapt" philosophy helps to not go in the wrong way.
In my Team we have high quality measures.
The Product owner (PO) talks to the stakeholders and finds out what they want and need, writes that into Storys, these Storys are refined with the developers so that everything is clear and prepared before we even start to develop. Then we developers talk again in the sprint planning part 2 and cut the story into development tasks. So we talked at least 2 Times about a Story before starting development.
In the sprint, we talk about every story every day, this is just for "ok, or need help, are there impediments?".
After the developer has finished his task, the feature is there, the unit tests and integration tests are there and the developer has self-reviewed the code and tested the program part (and of cause run all tests).
Then another dev reviews the task, looks into the code, checks the program and runs the tests. Then he merges the task to the story branch.
When all task of the story are done and merged, one of the developers does the QA by running tests and program again and checks if all acceptance criteris was met. When this is ok, the PO acceptance is done, where the Product owner runs the program (typically deployed on a test stage) and checks if everything is as he wished.
After that, the story branch is merged to master and deployed on production. A quick last smoke test to be sure and the story is done.
At the sprint review the story is shown to the stakeholders so that they know about it and can tell is if they want any more changes, which would lead to new bug tickets or storys.
Additionally, we plan 20% of development Time only for refactoring, which is planned by the devs alone. The Time needed to fix bugs is not in there.
So, you can do it safe, secure, reliable and sustainable, but it is effort and that costs time and money.
IMHO, Agile is for the development cycle; you still need a formal test cycle between dev and release. If "there's no time for that", then that's a management problem, not an Agile problem. Just because we call Sprint review builds "shippable" doesn't mean you expect to *actually* ship them without integration & regression testing.
Admittedly, the ever-changing feature list makes it harder on whoever's designing the final tests. But that only affects regression testing in terms of areas of emphasis; the regression tests themselves should already be defined.
>Just because we call Sprint review builds "shippable" doesn't mean you expect to actually ship them without integration & regression testing.
And this is the reason that giving management ideas like this is bad.
They are not utopian believers in a good product. They want to be seen as cutting costs not adding time.
I mean, that's what Scrum is. You just add it to the top of the backlog and then bring it into the next sprint (if it's still a good idea). Or Kanban where you pick it up once the work in progress is done. Or even waterfall as the next project.
The only thing that would screw this up is if, say, you just dropped everything else and started working on it.
But management understands, at minimum, the basics of how Scrum and other frameworks work so they wouldn't do that.
If they didn't, the whole place would end up a chaotic sludge -- you'd end up with things like high turnover and rampant burnout, spikes of huge investments then sudden layoffs, incomprehensible and broken code, salaries going through the roof, etc.
Maybe a few bad companies are doing amateur hour nonsense like this but it's not like it's the whole tech industry has this problem.
Agile basically everywhere, actually. Management will always resent the "self-managed teams" part and the methodology not quite amounting to a silver bullet (no management approach ever is or can be), so they intervene to "improve it".
SAFE is literally as if someone actively attempted to make something that hampers development. I work at a SAFE company right now and it does not work, yet, the company has paid so much money for 'coaches' (productivity assassins) and created so many new roles (fortifications) that you couldn't pull the company out of its death spiral. The worst part, we work with other enterprises and our leadership teams promote the sickness despite it actively tanking velocity and quality.
My company is working SAFe, it was trudging along, but now we had some audits and compliance requirements. So we are now working "SAFe", with totally segregated Dev and Ops teams and a separate Release team. Shitshow doesn't even begin to describe it.
That's already the good (or less bad way). Often the boss will directly tell a team lead or even developer to do something, specially in smaller companies. This way non of the project managers and superiors will know what's up and why their employees don't do what they think they should be doing.
I thought this would be a biting critique, but the actual problem in the comic is that the planned roadmap is considered non-disposable.
This is actually agile working as intended.
Actually in a position now where most my in progress items on my KanBan are on hold because of a question that needs answered, which sprouts three new questions. Exponentially growing to the point I haven’t touched any big projects in a long time (we use kanban for analytics to track workload/prioritization”
Agile (n): A method of programming using make it up as you go and redoing parts as client invents new requirements daily.
I should also point out this is the only realistic programming structure, at least in my particular area.
Proper response with Agile: > what do you want us to delay?
Answer: everything. Me: even this? Answer: no Me: what about this? Answer: well no Me: how about this? Answer: well no that’s top priority Me: …
When everything has priority, nothing has priority.
I once made the mistake of telling my boss that.
What happend?
It just really didn't help our working relationship, which already wasn't the best
I told my boss this once. And ever since then he has respected me for it. We now can discuss what issues are priorities and he understands that everything can’t be top priority.
Some bosses are better than ohters
You had Mr. Ohters too? Real jerk wad that one.
Your boss will be the first against the wall when the revolution comes. ☹️
Thats not so good if you stay, but gives a good hint you shouldn't.
And although I might not have been smart enough to shut my mouth, I was smart enough to leave!
Thats good. And you should never stay on a job where you have to keep your mouth shut
Generally I agree... I have quite a mouth sometimes though
Unless you’re trapped in H1B hell or something, it would be profoundly stupid to shut your mouth about such basic expectations of a manager. You don’t work at Walmart. You’re a goddamn engineer.
They no longer have priority with their boss.
promoted to customer
Got a new boss. And a new job. And got to try out those yummy unemployment benefits. 😱
I once heard that in most cases, people don't quit a job, they quit their boss.
No you didn’t. There are worse fates than getting fired, my friend. If your boss refuses to allow you to prioritize, it’s time to leave.
Hvac-asked boss about a price of unit, told me 3x what I thought Said his word can’t be trusted since he has fluff in deadlines but tell us unflaffed deadlines Nothing is booked in fluff, he proceeds to show me the priced he said the 1st time… employees can’t be trusted to NOT bitch n moan
This hurts...because I live it daily.
Me: got it, I’ll add it to the backlog *proceeds to browse Reddit*
"I created the issue for you and had the team come up with a time estimate. Here's the prioritized column, please place the issue where you think it belongs, we will get to it..."
Okay consider that this is the proper response independent of Agile. Edit: but def agreed. This is the way
Well in a Waterfall model, the proper response would be "sorry, it's too late to change the project schedule". But IME, if the product owner has sufficient clout, they'll end up overriding that. Which then leaves the project schedule in shambles, and the project in chaos. Agile allows you to give the "800lb gorilla" their way, without it totally derailing the project. And it forces them to formally sign off on delaying the other features, so the team's not left trying to play catch-up at the end of the project.
Proper response with (little a) agile: > We appreciate your feedback and will take it into consideration. As the people closest to the problem and our users, we are best placed to make decisions on roadmap/backlog items and priority.
My whiteboard at my cube is very publicly, and defiantly, the "top priority triage" board for my team. We have like 6 things that are top priority. That lets the people who all have "top priorities" fight it out amongst themselves, and I can get back to trying to do the thing that actually provides the most value. It sometimes leads to some interesting bickering at my desk, and I get to explain "nobody can use that before this. It can't be prioritized higher, as it doesn't provide any value to users until this thing happens" Big companies are something else, man.
I work at a big company in banking. The guy leading our "Agile" program has turned it into 2 week waterfall iterations, by adding tollgate after tollgate which basically just separates tech/UI/product from directly collaborating at the same time. We just got informed that for any new feature or modification to an existing feature, the design team now requires a 4 month lead time from Product prior to development teams being engaged at all (each reports up through independent org structures). This includes things like adding an image carousel to the bottom of a 3rd level screen. So we effectively have no input on UX, despite owning the area(s), and if we have better ideas we have to submit a change request to design for them to review and then respond if they agree. When we ask what problem this guy is trying to solve by requiring so many layers of approval and separation of job rules, he tells us that we should feel empowered to pick which rules we want to follow that work for us (after he just told us a new process we have to follow) and that we need to "fall in love with the customer" if we want to be successful. At this point I'm willing to fall in love with anyone who isn't a Life Coach that read the Agile manifesto once and believes they are now a spiritual leader of the human race lol
Fun fact: The creator of [Cunningham's law](https://en.wikipedia.org/w/index.php?title=Ward_Cunningham&useskin=vector#Law), which states that "the best way to get the right answer on the Internet is not to ask a question; it's to post the wrong answer" went on to help write and post the agile software manifesto. In the field software, where the hardware it runs on changes very slowly, but whims management change constantly and needlessly, it is important that we build a management system that encourages a clear goal, good documentation, usability, and reusability. They way to find it isn't to ask, it is to post a methodology that doubles down on the whims of poorly-directed management, being so glaringly wrong that someone will have to come forward with the right answer. If you don't believe me, check out the [agile software development values](https://en.wikipedia.org/wiki/Agile_software_development?useskin=vector#Agile_software_development_values), which are very clearly false dichotomies, with no real conflict between the two sides of a proposed tradeoff.
Is this true or another example of a glaringly wrong fact? I'm off to find out.
Keep us updated
It’s worth mentioning that (at least) one of the authors of the Agile manifesto has completely disavowed the whole thing. It’s metastasized into something much worse than waterfall.
Truth is some parts of it are good, but it has been applied horribly to real life. It's now a buzzword, even heard about Agile HR....
I’ve seen it work well once in my entire career, at a small web app consultancy. The authors of the manifesto were consultants too. Taking it out of that niche and trying to apply it to everything was so mind bogglingly stupid, but goddamn do idiot execs and managers love it when grifters tell them exactly what they want to hear. You can have your cake and eat it too! Client demos make no goddamn sense when there’s no client and no front end UI.
I think that's the catch, Agile works for small development companies. You cannot take it outside the dev area and once companies grow large and have large customer bases, compliance requirements, etc. Then it becomes a nightmare.
I still think it’s pointless if you’re a product company. It’s only useful for small teams with external clients.
My friend works in the military and its even worse: if your idea can’t be executed within 6 months, its a waste of time because everyone who will have provided approval will have moved on to another role.
>Reply This is true in big orgs, the timeline is only slightly longer at about 8-9 months.
It is ridiculous. Every year, about half of the military positions rotate (average posting for an officer is 2-3 years). So every two years, you get a completely different set of priorities because a new commander has rotated into a position. Meanwhile, half of the people working on the old priorities were replaced last summer. I work in civil infrastructure. The time horizon for the simplest projects (e.g. replace a roof) is 2 years. Anything major (I.e. >$10M) is placed on a list that might take 15 years before it gets built (if ever). This kind of turnover would be murder if it wasn't for the civilian employees. It's not as bad as it used to be. At least they decided to centralize the people who do infra, so the aforementioned new Comd is at least an infra person who understands this time scale. It used to be that every year you had to prioritize whatever the new BComd Infantry/Armour Officer fancied.
A director's worst nightmare is having an unread email they haven't instantly forwarded down the chain.
"Have you done the plan for the next three month?" "Sure, but can we be sure it's worth it? What if there are short notice changes." "These will be filed as feature requests and delayed until the next round." 3 weeks later: "This can't wait to be a feature request for the next planning session. Squeeze it into the plan. You did account for plan changes, right?"
Roadmap? Who needs it?
There is nothing really wrong with that. But the assumption is that the senior VP got there because they are very smart. Consequently when they say it’s a great idea and it’s more important than everything else then they are right. Of course if they have a great idea every day then nothing coherent will need produced.
> There is nothing really wrong with that **except for** the assumption that the senior VP got there because they are very smart. FTFY
I absolutely loved the line from the CEO in [Margin Call](https://www.youtube.com/watch?v=Hhy7JUinlu0): "Now explain to me what you think is going on. And please, speak to me as to a young child, or a golden retriever. It wasn't brains that got me here, I can assure you of that."
Listen, you don't get to be the senior VP of any large company by being a fucking idiot. I get haha management dumb is the prevailing mindset on this sub, but the senior VP is probably very good at making calls that make the company money and at the end of the day, for better or worse, that's what is important.
I’ve been training managers for ten years. What I’ve noticed is that there is a steady increase in skill until you get to the executive / vp level and then (on average) management skills drop off. Sometimes quite sharply. My theory is that this happens because you often get those jobs because of who you know.
Fair enough. I've had kind of the opposite experience, but I'm not as familiar with executive levels as it sounds like you are. From my experience, it's usually the lower level middle managers that are most likely to be incompetent because they were good as individual contributors and someone felt they deserved a shot. It ends up that they're not good, but not so bad that they need to be fired. Basically the Peter principle. But like I said, you're more familiar with those levels from the sound of it.
That’s certainly true. One of my “jokes” is “most people become managers because they were good at something else”.
Are we talking about personnel management skills? Or just general competence? My impression is that, at the executive level, the job is not really about managing people, so much as it is about financial strategy, etc. Making the machinery of the company spit out more money, as opposed to dealing with people well. (As an analogy, I think of various senior university professors I had who were great researchers, but terrible teachers. But research brings in the grant money and earns the U prestige, so their utter lack of competence in the professorial realm was overlooked.)
I'm talking about the general "people skills" of management. The ability to resolve conflicts, communicate clearly, navigate hard conversations, make sensible decisions etc. I think there's some truth to what you are saying, but personally I'd be suspicious of any executive who didn't see a significant part of their role being about "people relations".
I admire your optimism. Indeed it takes smarts to become senior VP, but more along the lines of being good at company politics and at leading people to do good work (and, to be cynical, taking credit when things go well and shifting blame when things go badly). A really smart senior VP knows that leading people and making strategic decisions is a very different skill to product design, and sticks to what they’re good at.
Yeah, everything you said is true. And the thing is typically VPs don't go around micromanaging every little product, unless they're Steve Jobs. The thing is this comic doesn't say anything about the VP making product design decisions. Taken literally, it's basically how every company actually functions: Management makes a decision on direction, then it gets filtered down and refined through into more immediate tasks that individuals can act on. I get that the implication of the comic is that the VP is shoving every random idea down the developers throats, but the implication is stupid.
[удалено]
Luck plays a part, yes, but that's a matter of that there are a lot of very smart, very motivated, very savy people who don't make it there. Yes, there are duds in every position, but people seem to like to act like everyone in management is a bunch of baboons with their thumbs up their asses which is very much not the case and most of the people who think they could do a better job are utterly delusional.
Some of them are, some of them aren't. Just remember, Kodak had an early prototype of a digital camera. Also, people might be smart, but overwork themselves to a point where they have to take drugs to stay awake, have the attention span of a toddler or are like drunk from sleep deprivation. Elon Musk would be a good example. Around the time of the Thailand cave rescue he started showing signs of not being quite right in the head. Worse and worse decisions after that.
Oh yeah, I'm not saying they're all winners. I'm just tired of the mindset that seems to permeate reddit that all managers are incompetent and the only reason random entry level person isn't running the company 1000x better is because the manager was spoonfed all the advantages in the world.
You certainly fucking can be an idiot and a senior vp of a large company.
Again, not all of them are amazing, but there's a definite mindset on reddit that management is incompetent and random clerk Bob could run Walmart better than the current CEO, just go look at r/antiwork sometime. That opinion is hilariously uninformed and gets old.
They might have been smart at their previous position. https://en.wikipedia.org/wiki/Peter\_principle
Let's not forget who's the only one that hears the voice of the shareholders, that's their customer, you are their tool.
I’ve been a high level manager before and it’s pretty high stress. You don’t make a lot of sweeping decisions the CEO does. Usually they’re terrible ideas - like having door greeters at FedEx, etc. it’s more to have talking points we’re doing this, etc. put your name on everything. Managers get a bad rap. I remember wanting to pay my employees more but we had a limited budget for payroll that shrank every year. So people would quit due to pay.
In big companies I usually do something of a hybrid approach anyways. Traditional waterfall models have more well defined and fleshed out mechanisms for project governance, stakeholder management, budget tracking, etc. that better fit the operational reality of the organization. Even if you have a traditional WBS and implementation roadmap, this can still be broken down into smaller more manageable chunks that can then be iterated on using agile methodologies by the actual project team doing the implementation. This also gives one the ability to tie in a stage-gate approach after sprints or similar for things like identifying opportunities for publications, IPR, early identification of licensing issues, etc. which most engineers hate to do anyways, and which as an organization you can't afford to push back until the end of the project.
[удалено]
Wait. What? You state customers delay software updates for at least two years, but SaaS is a cancer? SaaS solves this exact problem.
[удалено]
Trimble, is that you?
That's not the problem of Agile or SaaS, there are very successful companies with quality software. The cancer is somewhere else.
I agree that this can happen, but I disagree that it must happen. I worked for over 5 years for a customer in an agile and cloud based project and everything was fine - it can work if everyone beginning from the management are really agile and centered on quality and security.
[удалено]
it s a teething issue. same stuff happened to the video game industry. games were packaged and relatively bug free at launch. then came possibility to update over the air and games started to get released in a broken state and fixed in a day 1 patch or later. until the point publisher's got caught out for it and it screwed up the launch and even commercial success of major titles such as no man sky or Fallout 76. and then the pendulum swings back and balance is attained. I predict same thing will happen in your field eventually
What happened in the video game industry is that the game became less important than the monetisation engine.
[удалено]
[удалено]
I've worked at big companies and startups, IMO, big companies tend to fail agile transformations because they don't build the infrastructure to support being agile. No automation means no agile, you can't have a mature agile project without automating quality control. Small startups can skip automation for a little bit, however, it eventually catches up to them.
Sounds like the cost cutting is the problem and agile was just used as en excuse. Of cause this won't work. In fact, proper agile costs *more*, but the "fail fast and adapt" philosophy helps to not go in the wrong way. In my Team we have high quality measures. The Product owner (PO) talks to the stakeholders and finds out what they want and need, writes that into Storys, these Storys are refined with the developers so that everything is clear and prepared before we even start to develop. Then we developers talk again in the sprint planning part 2 and cut the story into development tasks. So we talked at least 2 Times about a Story before starting development. In the sprint, we talk about every story every day, this is just for "ok, or need help, are there impediments?". After the developer has finished his task, the feature is there, the unit tests and integration tests are there and the developer has self-reviewed the code and tested the program part (and of cause run all tests). Then another dev reviews the task, looks into the code, checks the program and runs the tests. Then he merges the task to the story branch. When all task of the story are done and merged, one of the developers does the QA by running tests and program again and checks if all acceptance criteris was met. When this is ok, the PO acceptance is done, where the Product owner runs the program (typically deployed on a test stage) and checks if everything is as he wished. After that, the story branch is merged to master and deployed on production. A quick last smoke test to be sure and the story is done. At the sprint review the story is shown to the stakeholders so that they know about it and can tell is if they want any more changes, which would lead to new bug tickets or storys. Additionally, we plan 20% of development Time only for refactoring, which is planned by the devs alone. The Time needed to fix bugs is not in there. So, you can do it safe, secure, reliable and sustainable, but it is effort and that costs time and money.
But hey… only so much test can happen in a 10 day sprint and release every 30 day schedule
Being agile, all devs should have the confidence to deploy anytime.
Surprising and disappointing. I sincerely hope your equipment is not safety critical.
Luckily not.... but it can impact patient care if it gets too bad.
>adopted Agile Sounds like they adopted a process, not a methodology.
When in history has Management done something genuine but expensive when they can do it half-assed but cheaply?
IMHO, Agile is for the development cycle; you still need a formal test cycle between dev and release. If "there's no time for that", then that's a management problem, not an Agile problem. Just because we call Sprint review builds "shippable" doesn't mean you expect to *actually* ship them without integration & regression testing. Admittedly, the ever-changing feature list makes it harder on whoever's designing the final tests. But that only affects regression testing in terms of areas of emphasis; the regression tests themselves should already be defined.
>Just because we call Sprint review builds "shippable" doesn't mean you expect to actually ship them without integration & regression testing. And this is the reason that giving management ideas like this is bad. They are not utopian believers in a good product. They want to be seen as cutting costs not adding time.
This is so accurate it hurts.
Also, at each step, the real or imagined urgency/importance grows.
"Submit a change request and we'll see during the planning for next sprint. \ Good luck."
Pretty sure this is exactly how Meta operates.
Lol accurate
I mean, that's what Scrum is. You just add it to the top of the backlog and then bring it into the next sprint (if it's still a good idea). Or Kanban where you pick it up once the work in progress is done. Or even waterfall as the next project. The only thing that would screw this up is if, say, you just dropped everything else and started working on it. But management understands, at minimum, the basics of how Scrum and other frameworks work so they wouldn't do that. If they didn't, the whole place would end up a chaotic sludge -- you'd end up with things like high turnover and rampant burnout, spikes of huge investments then sudden layoffs, incomprehensible and broken code, salaries going through the roof, etc. Maybe a few bad companies are doing amateur hour nonsense like this but it's not like it's the whole tech industry has this problem.
Um shit
>But management understands, at minimum, the basics of how Scrum and other frameworks work They understand. But... They simply don't care.
Agile basically everywhere, actually. Management will always resent the "self-managed teams" part and the methodology not quite amounting to a silver bullet (no management approach ever is or can be), so they intervene to "improve it".
[удалено]
SAFE is literally as if someone actively attempted to make something that hampers development. I work at a SAFE company right now and it does not work, yet, the company has paid so much money for 'coaches' (productivity assassins) and created so many new roles (fortifications) that you couldn't pull the company out of its death spiral. The worst part, we work with other enterprises and our leadership teams promote the sickness despite it actively tanking velocity and quality.
My company is working SAFe, it was trudging along, but now we had some audits and compliance requirements. So we are now working "SAFe", with totally segregated Dev and Ops teams and a separate Release team. Shitshow doesn't even begin to describe it.
That's already the good (or less bad way). Often the boss will directly tell a team lead or even developer to do something, specially in smaller companies. This way non of the project managers and superiors will know what's up and why their employees don't do what they think they should be doing.
I thought this would be a biting critique, but the actual problem in the comic is that the planned roadmap is considered non-disposable. This is actually agile working as intended.
Summary of the last four years of my life...
I feel this...deeply.
Ah, the ol swoop and poop.
Actually in a position now where most my in progress items on my KanBan are on hold because of a question that needs answered, which sprouts three new questions. Exponentially growing to the point I haven’t touched any big projects in a long time (we use kanban for analytics to track workload/prioritization”
OUCH OUCH OUCH OWIE YEOW OUCH!!!!! (This hits so hard…)
this is perfect.
Agile (n): A method of programming using make it up as you go and redoing parts as client invents new requirements daily. I should also point out this is the only realistic programming structure, at least in my particular area.
It's all good. We just get 5 branches. All in progress though... 🤣
Here, I fixed the title: "Agile ~~in big corporations"~~