It all feels like theatre. Been working in many companies in “war mode” and they all think that in order to become profitable (none of them were) you need to push the most “important” features out of the door asap, otherwise your competitors will eat you alive.
It’s a lie. Executives and VPs and all those folks that earn 5x what a normal engineer earns, don’t really care about the company they work for. All they care about is to keep receiving the big pay checks until the ship sinks. Obviously you cannot just mandate “normal mode”, otherwise it wouldn’t look as if everyone is doing their best to keep the company afloat.
I hope in 10 years or so, we’ll see “wartime software engineering” with the same eyes we see today Agile and Scrum masters: snake oil.
It's easy to validate the veracity of 'War mode'. If survival hinges on a critical deliverable, then the promised reward must be in line with the stakes.
You can't have an employer offering a 20% bonus for keeping them alive. It's an insultingly low payoff or the crisis was a lie.
There is definitely such a thing as wartime software engineering. But such moments offer a clear path to millions of dollars or generational glory. Otherwise, you're being fed koolaid.
>You can't have an employer offering a 20% bonus for keeping them alive. It's an insultingly low payoff or the crisis was a lie.
I've told my direct reports something similar. "Don't stress out about this. If it were a real problem, someone would have noticed 3 months ago when it broke / was never completed before [employee] left." Most of these crises are painfully fake.
I also often say "this is the scope right now but we can cut portions of this if we need more time. These are the critical elements that we need before the deadline. But the rest of this stuff is us using this opportunity to not ship a pile of garbage we can't support. If we have to do that, we'll fix it as soon as the deadline passes." But also I actually have the mandate to do that.
That is like young media professionals who think being stressed is a badge of honor that shows how important they are.
As a freelancer I had to interact with these people and was constantly annoyed by their lack of efficient communications. If you are a freelancer your own time is actually valuable to you, wasting time is not a luxury you might be willing and/or able to afford, depending on your agreement.
If your company/project is constantly in emergency mode you should reconsider the quality of that companies/projects managment. Personally most companies/projects where I have wittnessed emergency mode the emergency was not only self-inflicted by mismanagment, it was also routinely self-inflicted.
If your emergencies could have been avoided by a thin veneer of foresight that emergency is on you. If you routinely get into emergencies without learning: congrats you're stupid.
If you conjour emergencies out of thin air to squeeze more work out of your employees you suck as a human beings.
If you think working under emergency mode makes for quicker, cheaper or more reliable results you probably never witnessed how quick, cheap and reliable a well planned project can be finished.
Or you know, sometimes your boss just lies to you, you do the crunch time, then when you save their asses you get laid off because that's cheaper than the raises or bonuses and you're prolly burnt out anyway so you won't be that productive again for months
There are definitely critical times where the engineering team can make a big swing in the success of their larger organization. I think that these intense periods naturally invite excitement. Going back to "normal" at the end of such a period is actually pretty hard; the work may not seem as important to the team, yet we have to rebuild some types of quality that were lost during the intense period.
These pivot-points are usually in luls after the storm, when the doomed project has no active-vampireempire on lead due to massive sinking ship jumps but there are suddenly fundings available due to being bought and sold.
Thats the moment you get a chance to re-engineer or develop new capabilities - the moment when the MBA outer bark layer holding us all back cracks and gives.
The above is mostly about times when all conversations start with "for the procto-cull: I was against this and that" and lots of ass covering.
Where do you work that you get to avoid agile, scrum, and war mode? I'm jealous. Then again I've always just been stuck working for startups my entire career. I have a family and desperately need something more stable.
Just sharing my own experience..I used to work for start-ups and now I am working for a seemingly boring, profitable company that is not venture funded. By boring I meant there is not alot of media news about them. They just bunker down and do the work. There's way less craziness - more focused, mature approach towards problems.
These companies do the regular stuff such as advertising via the usual channels- job boards and LinkedIn. And sometimes with recruiters - not those fancy ones who recruit for start-ups.
yea things are crazy now. We're in war mode but nobody knows why. We've been reliably profitable for a decade. And yet we're doing super high risk cost reduction projects that have significant risk of burning down the entire business and have already destroyed what used to be a very skilled and mature engineering team. I get the impression that's a fairly typical story now.
Jobs at big companies are less stable and end with less notice than at small ones, at least in my experience. In a small company, particularly one with engaged and transparent leadership, everyone knows what’s working and what isn’t and about how long the latter can be endured. At a large company the vast majority of jobs are susceptible to the whims and whispers of a few (who likely aren’t engaged and feel they can’t be transparent).
IBM didn't have it's first round of major layoffs until the 1990s, Google and Microsoft didn't have their first major layoffs until 2008-2009, Facebook/Meta didn't have its first major layoffs until 2022, etc. Even then, only a fraction of their employees were affected. People can last quite a long time at such places with a little luck.
You can be in the wrong place at the wrong time anywhere--but, yeah, generally speaking given reasonable competence, you can ride a reasonable, if not spectacular, gravy train at most large organizations for a long time. Maybe that's not your thing--which is fine--but it's probably the case at a lot of large companies.
Don't know why you're getting downvotes, this is indeed a fact. (Edit: you don't have to be a bad performer to get shunted out by stack ranking. In a rotten enough organization, it is possible for a manager to write a performance review that acknowledges every goal that you've met, and still gives you a bad rating for any old excuse)
BigCo is less likely to give a sense of desperation in day-to-day work, but a layoff or forced stack-ranking can still fall out of the clear blue sky due to executive machinations.
A lot of this model is due to the churn of VC companies toxic entry into overtaking and consuming companies... They often force out old company leadership, create & impose hostile policies and requirements on employees the make them leave so that operations will be left as bare-bones and over-stressed operations that just serve to feed investor profits... Our current IT ecosystem, especially in the contracting world is run mostly by finance experts rather than tech visionaries, and it's showing in the outcomes, this is why we don't see truly disruptive inventions like Twitter and iPhones anymore... And why monthly subscriptions are swooping their way into everything, even basic tools like calculator apps, and car starters and seat heating... Foolishness & Insanity.
A real engineering manager, when the execs say "Its Wartime" says "Wonderful, is everyone on the c-suite taking on call rotations so the engineers can focus or just the CEO and CTO ?"
I think that almost no one from the community has any hate for "Agile" as in the manifesto. Quite the opposite.
The problem is that the Agile that is pushed in the corporate world is nothing at all related to the spirit of the manifesto.
Management took over to keep control over developers.
So you have scrum, you have scrum masters, product owners, t-shirt sizes poker, ... All of that bringing more stress to devs than having empowered them to be trusted to deliver what the real client wants.
Can you provide me an actual way to practice these things? Like, specific, exacting ways to execute each of these? Or any of these? Because they don't make any sense.
"Value individuals and interactions over processes and tools". So, rather than put an update in a Jira ticket, DM it to a single person in Slack?
"Value working software over comprehensive documentation". So, never write documentation? And how do you define "working" software? What about features in development? (etc)
"Value customer collaboration over contract negotiation". Lol. I have never talked to a customer, in my entire career. I have also only heard about contracts, and usually they are ridiculous. I guess this is supposed to be different... but kinda hard to make it different if you aren't allowed to get close to a customer or a contract negotiation. (Why the fuck is this in an engineering guideline?? Do you find a lot of developers doing contract negotiation?)
> Value responding to change over following a plan
?????????? Does anyone know what the fuck this means?
....
The rest of the "12 principles" are equally stupid and nonsensical. They only "seem right" if you don't think about them for more than 5 seconds, and you live in some kind of fantasy world. It is absolute bullshit, completely disconnected from reality. (But boy do executives love to eat this shit up, because they will never have to figure out how to implement it)
Agile was a reaction to waterfall and other heavy-process software development practices. You have to understand the bigger picture to fit the Agile points in there.
For example your
>> Value responding to change over following a plan
> ?????????? Does anyone know what the fuck this means?
In waterfall, once you start developing, it's very hard to change something during the process. Due to Agiles iterative and incremental approach (principles 1 & 3), it allows you to change priorities, features, integrations, etc, during development.
New technology also allowed this iterative approach. For example in the past, software was released on disk or CD-roms, which meant a huge release cycle. Nowadays with SaaS, you can constantly release and improve your products (using CI or CD for example, widely adopted now).
Maybe you have to look into other software development processes to really understand what sets Agile appart, for example Waterfall, Spiral, Incremental, Rational Unified Process, etc. A good overview is here: https://en.wikipedia.org/wiki/Software_development_process
Maybe I'm not understanding it completely indeed. To make it more clear to me, can you explain what software development process you prefer so I can contrast it with the points of agile?
> “Value individuals and interactions over processes and tools". So, rather than put an update in a Jira ticket, DM it to a single person in Slack?
Stand up. Walk out of office. Get on train. Arrive at user’s office. Go sit next to user. Spend afternoon understanding how they use the software you are supposed to be building.
Bin the sprint planning, retros, gantt charts, standup and whatever fucking sprint poker is.
Go. Speak. To. User.
> “Value working software over comprehensive documentation".
> So, never write documentation?
Read the phrase again, with a slightly different word in place
Prefer working software over comprehensive documentation.
I.e. working on building the thing instead of obsessing about gant charts.
You can do a Gantt chart if you want. But focus primarily on the software. That’s more important.
> And how do you define "working" software? What about features in development?
Intentionally left vague. “Working”depends on many factors that only the people involved with the building of it can know.
Mainly by getting on a train and sitting down with your users to figure out exactly what they consider to be working software. See above.
> “Value customer collaboration over contract negotiation"
You’ve not been around much contract consultancy work then?
Hey, company X we’d like some software that does Y.
Do you
1. Enter into a lengthy process to establish exact requirements and agree on exactly what needs to be delivered up front, without having touched any software, and trying to cost it all out etc etc
2. Get on a train and sit with the user developing some proof of concepts quickly to figure out what the hell it is they want.
1 is waterfall and contract negotiation. 2 is responding to change. example is a user saying “oh, actually, could we try the page header in pink instead please” after asking for it to be blue last week.
> lol. I have never talked to a customer, in my entire career.
You’ve never spoken to a user?
You need to start.
Ideally right now.
Stand up. Walk away from your desk. Find a user to speak to. Ask them what they think of the software.
> Why the fuck is this in an engineering guideline?? Do you find a lot of developers doing contract negotiation?
Well it’s not in the contract so I’m not going to work on that feature because we won’t get paid for it.
Even though some enterprising engineer went and got on a train and sat with the user for a day and figured out “oh shit, we’re actually building the wrong fucking thing”.
Nope, not in the contract. User doesn’t get what they want because we negotiated a contract.
> Value responding to change over following a plan
Waterfall: We have an agreement and WILL ONLY BUILD ACCORDING TO THE PLAN. We will never deviate from the plan. The plan must never change. Ever.
agile: shit, I went and got on a train and sat with the user and we’ve been building the wrong thing. Time to rethink this.
> The rest of the "12 principles" are equally stupid and nonsensical. They only "seem right" if you don't think about them for more than 5 seconds, and you live in some kind of fantasy world. It is absolute bullshit, completely disconnected from reality. (But boy do executives love to eat this shit up, because they will never have to figure out how to implement it)
A lot to unpack here.
No, they’re not stupid. They may be “of their time” but they’re definitely not stupid.
They seem more right the more I think about them. I think about agile a lot and how to teach the attitudes contained within the principles to my juniors.
Just to reiterate the important point there — the principles are a collection of attitudes. They are not explicit instructions.
No, it’s actually useful. Would I base an entire team methodology solely on this? No. But it informs a significant part of it.
Executives don’t care about by he agile manifesto. Mostly because no one posts about it on linked in and they’d rather pay someone ridiculous sums of money to make the team “Scrum” and fuck about doing whatever the fuck sprint poker is (execs always want to spend money instead of doing the work).
According to the LinkedIn post it made some other team really efficient. They read about it on linked in. It must be true.
—
FYI — just because you don’t understand or see the value in something does not mean it isn’t valuable.
>> So, never write documentation?
>
> Read the phrase again, with a slightly different word in place
I spent way too many years working at an Agile shop that had been doing Agile for a very long time. (This is me saying "This place definitely wasn't Doing Agile Wrong.".)
At that place, "Prefer working software over comprehensive documentation" ended up actually meaning "Do not write documentation. Go speak verbally to the SME for that thing or section of code if you ever have questions. Documentation maintenance is a cost that we never have time to pay. Ditto for code comments... all code MUST be self-documenting.".
It -uh- didn't work out so well.
> You’ve not been around much contract consultancy work then?
Honestly? IME, this is about the ONLY environment where the Agile stuff makes sense. It's just such a very, very, very poor fit for long-running projects that require continuous work that may extend for decades.
> > You’ve not been around much contract consultancy work then?
> Honestly? IME, this is about the ONLY environment where the Agile stuff makes sense. It's just such a very, very, very poor fit for long-running projects that require continuous work that may extend for decades.
I disagree. Like, I was just working at a place that did both analytics consultancy and in-house products. Go. Speak. To. User. worked in both.
For consultancy, yeah we had to go off and sit with the customer and figure out with them exactly what they needed. Do iterative PoCs. Eventually work out, together, what the 'user'/customer wanted to get out of the project(s).
For product, I sat down with one of the lead scientists and asked her what she actually wants. Like, be real with me. It's me here. I don't care if you want to use the products or not. I want to help you do the job you want to do and help you solve those problems you face on a daily basis. What will help you do this.
Answer: Bin the vaporware in-house software product and move to an established off-the-shelf third party system (Benchling).
Repeated the same thing with Data Science.
(Eventual) Answer: Bin the vaporware in-house software product and move to an established off-the-shelf third party system (databricks).
Of course, that didn't fly with the management people who wanted their magical 'guaranteed revenue stream' (which didn't exist). They weren't Go. Speak. To. User.-ing. So they were divorced from the reality of what was going on and stuck in the blue sky management vision.
Agile-manifesto-agile doesn't just apply to engineering. You can apply the principles of Go. Speak. To. User. And. Stop. Making. Gantt. Charts. To. Solve. The. Real. Problem. to a lot of places.
Yes, but "Go speak to the fucking users so that you build the right thing" is such a tiny slice of Agile shit, and it's a product management rule that predates Agile by ages. This is like one of THE big things that Product and Field people are supposed to do, and has been for roughly forever.
As for the rest of Agile? Maybe the idealized Agile (just like the idealized Marxism) works great, but my personal experience at a place that very, very, very much was NOT Doing Agile Wrong[0], along with the personal experiences of an assload of others who work at Agile (and "Agile" shops) indicates that Agile as she is implemented in the real world is incompatible with long-running continuous [1] projects.
[0] I'm afraid you're just going to have to take my word that I know what I'm talking about here.
[1] "Continuous" as opposed to the "parachute in, mitigate the biggest problems, and then airlift out" engagements that are SOME of what contract shops are hired to do.
Is fine. Imaginary internet points are just imaginary internet points.
> It's clear people don't want to talk to users. But in the end, it gives people like us an excellent advantage.
The best kind of user to me is the one who is convinced they’re “dumb” when it comes to software. I always get so much more useful info from them compared to the folks who think they know something.
I don't think people are really unhappy with the manifesto, but with applied Agile as it is experienced out in the world where you're having your workday ordered by high powered productivity consultants and LinkedIn-brained middle managers.
Big A Agile is an exercise in making management happy because they read about it on LinkedIn while having a poo. It usually involves paying several consultants a lot of money.
In my personal experience, pretty much. Theatrically feigned agile is extremely aggravating and grating. Actual agile is in my experience fine and doesn't produce that kind of strong aversion because it 'just is'.
My main point of dislike is that I have never experienced the actual practices called "Agile" on the ground by the consultants/managers introducing them bearing any relation to the oft-quoted Agile manifesto.
"Value individuals and interactions over processes and tools", says the Agile consultant as they open the meeting; they then proceed to shut down any interaction between individuals that is not on the agenda, or that is on the agenda but takes longer than a sentence or two.
"Value working software over comprehensive documentation", says the Agile consultant as they open the sprint planning. "These tickets should contain enough detail that a new hire coming to them cold can pick up the work."
"Value customer collaboration over contract negotiation", says the Agile consultant. "Value responding to change over following a plan. Also, these items must be delivered by end of Q4; let's schedule some meetings with management to discuss why the team's burndown chart is going up and not down."
Agile is like true communism: always preached, never reached. It is a fig leaf for toxicity. The ideal true Agile practitioner cannot be faulted; and you will never encounter them. The word "Agile", when encountered in real-world corporate scenarios, does not mean the things described in the manifesto, though the manifesto will often be quoted; rather, hearing it invariably means the frog has reached boiling temperature and it is well past time for anyone who can still flee to flee.
"Agile consultant" is the modern term for an outsider that management have brought in to whip the thoroughbreds so that the resulting negativity falls on the outside party - which can then be let go again - and not anyone permanently employed by the company. We may want the word to mean nicer things, but that is not how it is actually used.
> "Value working software over comprehensive documentation", says the Agile consultant as they open the sprint planning. "These tickets should contain enough detail that a new hire coming to them cold can pick up the work."
A ticket that tells you what needs to be done / reviewed / tested is indeed in the pursuit of working software. Having detailed class diagrams drawn 18 months ago that you have to follow is what this point is talking about.
No one criticizes the manifesto itself I believe. But there's a huge difference between the abstract idea and principles of the manifesto, and an actual implementation that usually differs from company to company. So, yeah, the idea of babies is nice and all (everyone loves the manifesto), but you need to change diapers and that gets dirty. No one likes to changes diapers (no one likes Agile).
Many, many, many, maybe most people have implemented Agile as a recipe. Without understanding how it could work or why. Since they have no idea what they are doing, people who are forced to use this cargo-cult implementation find it onerous. Just another stupidity forced on them.
The question is how can people collaborate? That is the question. Complex Adaptive Systems (CAS) begins to help us think about how we can do that. Simplistically we can just throw bodies at problems and we get "the mythical man month" mentality. Or we can do it with militarism - we all get marching orders. Unfortunately, good programmers do not do well with this mentality.
So is there another way? At this point, as a community, we do not really understand how people work together. Despite the face that millions of people can live in a large city, we have no clue as to the mechanism that allows this to happen. $. The city does not degrade as the Mythical Man Month predicts, nor are the people ordered about in a militaristic manner. So what gives? How does that work? $.
Why do I keep putting $ in this post? Because $ is a "messaging bus". (You tell me a better word - signalling system?). Everyone can read (get money) and write (spend money) on this messaging bus providing signals to other people.
Agile is a very fuzzy attempt to provide a messaging bus. But if you have no clue as to the mechanism, you can descend into madness - for example "If one scrums are good what if we do ten a day?".
I'll push back in defense of Scrum, but it probably bears a little explanation because my conceptualization of that framework is very likely a lot different from yours. (As something of a bonus: I'll bring in the military given the whole "wartime" trope.)
In particular, Scrum is only there to establish rituals that enable empiricism in decision making. A sprint is a reporting period to keep the team from spending too much time in the weeds. A standup is there to keep the team working together. The andon cord (which is often missing I find) is there when the facts have changed so utterly profoundly that everyone needs to regroup.
Anyone who's been through RTC ("boot camp"), and even some who haven't but have lived vicariously through others, understand that being constantly yelled at by RDCs ("drill instructors") on how you make your racks and fold your clothes is all about building certain habits and only tenuously related to what you'll be doing after A-school. It all has more to do with building trust that the rest of the folks in your ship will help carry you when the going gets tough. Scrum, at its core, is kinda like that.
I really dislike the term "Scrum Master." They're a team captain. The more military-minded might be keener to use "gunnery sergeant" or "chief petty officer:" they're just the most senior person in the rating group^W^W^W^Won the team. (Though, I'd probably take more inspiration from the Marines than the Navy here: a culture of servant leadership seems to bring out the best in people.)
The most popular implementations of Scrum tend to come with a ridiculous amount of meeting and tool baggage, and it's so unnecessary.
Use Excel. Hold your standups at the close of the day so people can go home. Write your product backlog items in delivery order so that sprint planning is less about sitting in one room playing poker and more about just getting valuable shit done.
That said, what isn't unnecessary, however, is kneecapping command a little: the engineering officer of the watch has comparatively little understanding of the actual operation of the machine. They just know that they want operational excellence. However, that excellence also sometimes comes with the watch supervisor—a subordinate—publicly calling out mistakes that the watch officer makes.
> I really dislike the term "Scrum Master." They're a team captain.
Originally that term was supposed to be a temporary role that someone (rotated each time) would take on during a scrum meeting, and referred to them being charged with keeping the meeting on track.
and... it would keep everyone on their toes a bit more, vs just having a group of folks that nod and say 'yes', 'no' or '3 points' a few times at the same time every day.
It was! I've, however, gotten way more use out of saddling whoever is most senior with the role of making sure the team as a whole is on track. This way, it's a little more familiar with the way Western management hierarchy operates without turning it too much on its head. It's something of a leadership billet without removing the ability to be technical, which is important for a lot of folks.
It tends to work pretty well in an environment that both lacks a bug tracker (so that individual people aren't assigned things) and has a culture of pairing or mobbing.
If you don't know what a 5 month run way feels like, you haven't experienced life. It really helps you understand what is important to projects and wtf isn't.
The failure mode of Agile is when the company says "we're going agile" but refuses to adapt or let the team manage itself, as well as having a fixed deadline, scope and budget which have been decided outside the team. In other words, you still have the clueless project managers, but you have to cosplay "agile" within that.
Because, consistently, management doubling down on failure is preceded/foreshadowed/accompanied by a full on theatrical performance of "we're going Agile".
I have no explanation for why /that/ is, mind; except - well, look at the result: the blame and hatred is aimed at Agile and its priests, not at management. Cui bono?
Agile is great. The problem is “agile methodologies” like Scrum which create lots of overhead and ceremony. I have seen Scrum work well but it is the exception.
There is such a thing as a first mover advantage, as long as one doesn't focus on competitors as much as unserved / underserved customers.
Pretty often people that heavily emphasize the competition and push arbitrary timelines have taken shortcuts, or at least aren't being transparent enough to satisfy the team. They may also just be competitive by nature and insecure due to a lack of experience, and bad at communicating - also, due to a lack of experience.
Agile / Scrum: people quickly realized that they had to give up control in order to be agile.
It's possible to do Agile and to structure a waterfall software project into smaller chunks that feel agile, but you need PM's who know how to do that, and they need to show their work to the team in order to get buy-in. It's too bad the jargon got abused to the point of garnering resentment.
At least it's a formalized way to plan and communicate using common terminology. Even this lowest common denominator is worth something. It doesn't have to be great to have some value. I have a hunch Agile can amplify both good a bad company culture.
It’s a lie. Executives and VPs and all those folks that earn 5x what a normal engineer earns, don’t really care about the company they work for. All they care about is to keep receiving the big pay checks until the ship sinks. Obviously you cannot just mandate “normal mode”, otherwise it wouldn’t look as if everyone is doing their best to keep the company afloat.
I hope in 10 years or so, we’ll see “wartime software engineering” with the same eyes we see today Agile and Scrum masters: snake oil.