4 ms·

Things were better before agile / scrum / annoying processes took over. Not all companies were waterfall, they kind of just "did things" without any well defi

Things were better before agile / scrum / annoying processes took over. Not all companies were waterfall, they kind of just "did things" without any well defined process. This was how things were until roughly the early 2010's. I remember working for weeks, after a couple of whiteboard sessions. You'd meet about what you were going to do, work on it, and come back a week or two later. Occasionally there would be informal check ins.

commandlinefan 4y ago
> Things were better before agile / scrum I don’t necessarily agree that things were better - but “agile” was supposed to fix the things that were bad back then but has since somehow managed to morph into exactly the same problems that it was originally purported to solve.
- randomdata 4y ago
  I always found it funny that where I worked we were doing Agile (without knowing it by that name) until the "Agile" Kool-aid was drank, at which time processes started to trump people.
  - commandlinefan 4y ago
    Yep, when I first saw it, it was called "XP" (Extreme Programming). When I read the manifesto, I breathed a sigh of relief: finally, somebody with some authority has some clue about realistic software development! Then the Agile coaches started coming in: "the biggest benefit of Agile development is delivery of software on schedule and with budget!" Ok, new boss, same as the old boss. Gotcha.
amackera 4y ago
Before you did agile, were there ever death marches, slipped deadlines, pissed off clients, or long crunches? Your comment has the sparkle of nostalgia for glory days gone by.
- ryandrake 4y ago
  Seriously. I think people are looking back at "no process" companies with rose-tinted glasses. Software doesn't just leap from the developers' fingertips onto store shelves. I've worked as recently as 2010 at a company with no software engineering process, no release process, no qa process, no feature intake process, no planning process, no bug tracker (!), no source control (!!), and so on. It was a total clown show. Highlight reel: Nobody knew what bugs existed or what features were needed until someone in sales who talked to a customer ran downstairs and recapped their last customer call. Builds were not reproducible. How we decided what we released to the world was we'd poll the room. Who could actually compile the software today without errors? That person would build whatever was on his workstation, debug symbols and all (because the release builds crashed), and package it up for the customer. How did we know what we were releasing works? There was one QA guy, who worked on the assembly line. They'd flash the software onto a single device, and make sure it still booted. Ship it! How did we plan what we were doing for the next N weeks and months? This one's easy--we didn't! The CEO or someone in sales would run downstairs and tell us "We just sold XYZ feature to a customer. We need everyone to drop everything and make this by the date we also negotiated with the customer!" I think "no process" software development only works for a single developer, or for a very small (less than 3 person) team of absolute experts. Mix a single junior person into the team or add more than 3 or so developers, and it's going to be chaos.
  - SillyUsername 4y ago
    Couldn't agree more with this and above poster. Having weekends back by less failing systems caused by cowboy unreviewed code and no crunch caused by inadequate planning are for me the main social benefits of agile.
- icedchai 4y ago
  Yes. And sometimes those things still happen with "agile", too.
conatus 4y ago
> You'd meet about what you were going to do, work on it, and come back a week or two later. Occasionally there would be informal check ins. Planning meeting, ad hoc meeting doing the work then weekly/bi-weekly show and tells to show progress. Sounds like...some version of agile? Remember agile and the XP movement that preceded it was invented by software makers, who had observed the pattern you describe and decided to be self-conscious about it.
- icedchai 4y ago
  It was true agile, not "Agile" in the sense we see today (empty ceremonies, time wasting meetings, micromanagement, endless jira tickets...)
hk1337 4y ago
Things were better before agile / scrum moved from the developers doing it to project managers doing it.
- t43562 4y ago
  "Project Management" and "Agile" IMO are completely opposed concepts so no wonder project managers don't get it. They still want jobs however so now presumably it's perverted agile.
narag 4y ago
That's exactly right. There were good and bad things. Some method was needed, but too much method is lethal to productivity. Agile was sold as less rigid method, but for many shops it's simply too much. You need first to make it work, later to make it perform, then to optimize it, finally to trash and replace it. Many go right away to optimize then stall.
xiphias2 4y ago
I read this all the time and see that software engineers don't even read the agile manifesto: ,,Individuals and interactions over processes and tools'' What you are describing is the opposite of agile
- icedchai 4y ago
  The truth is that the manifesto may as well be fiction. I'm talking about reality... what the industry actually practices as "Agile." That's why you read it all the time: because it's true.
  - xiphias2 4y ago
    Maybe it's true at some companies, but it has nothing to do with agile / scrum, but letting non-tech people who love confrontation take over engineering leadership from engineers who are afraid of confrontation (which sounds like the disaster it is). Robert Martin (one of the creators of the agile manifesto) explains it quite well in ,,Clean Code'' presentation: https://www.youtube.com/watch?v=7EmboKQH8lM https://www.youtube.com/watch?v=7EmboKQH8lM The whole presentation should be a must watch by all engineers so that they understand what _is_ agile to the point when they know it better than product / project managers / non-tech people. It's hard to get a better description than the original source, and no non-tech person has authority to override the real agile at that point.
    - icedchai 4y ago
      I'd be interested to know what percentage of companies are "true" agile. Based on my personal experience, it must be very low.
      - xiphias2 4y ago
        It's not rare in my experience. It's basically a bunch of experienced engineers getting together for a weekend warning inexperienced engineers about newbie mistakes, like obsessing too much about new shiny tools / frameworks / processes created by people from the past, or leaving mess behind. At Google we were doing mostly agile actually (didn't really have any complex process, but had quarterly goals to check ourselfs and get feedback, also weekly check if we are going in the right direction). ,,this week'' snippets about what we're going to do this week. All light stuff to make sure that it doesn't hinder real coding work. Cross team work was much more messy of course, but inside teams this worked fine. At another small company I worked it was almost the same, we just didn't call it agile.
grecy 4y ago
> they kind of just "did things" without any well defined process That's called making it up. While it may have worked for that organization, I assure you it falls it a heap 99.9% of the time large software is developed that way.
Eduard 4y ago
> This was how things were until roughly the early 2010's. "Mid 2000s" for some of us at some places, unfortunately.

commandlinefan 4y ago

> Things were better before agile / scrum I don’t necessarily agree that things were better - but “agile” was supposed to fix the things that were bad back then but has since somehow managed to morph into exactly the same problems that it was originally purported to solve.

randomdata 4y ago
I always found it funny that where I worked we were doing Agile (without knowing it by that name) until the "Agile" Kool-aid was drank, at which time processes started to trump people.
- commandlinefan 4y ago
  Yep, when I first saw it, it was called "XP" (Extreme Programming). When I read the manifesto, I breathed a sigh of relief: finally, somebody with some authority has some clue about realistic software development! Then the Agile coaches started coming in: "the biggest benefit of Agile development is delivery of software on schedule and with budget!" Ok, new boss, same as the old boss. Gotcha.

amackera 4y ago

Before you did agile, were there ever death marches, slipped deadlines, pissed off clients, or long crunches? Your comment has the sparkle of nostalgia for glory days gone by.

ryandrake 4y ago
Seriously. I think people are looking back at "no process" companies with rose-tinted glasses. Software doesn't just leap from the developers' fingertips onto store shelves. I've worked as recently as 2010 at a company with no software engineering process, no release process, no qa process, no feature intake process, no planning process, no bug tracker (!), no source control (!!), and so on. It was a total clown show. Highlight reel: Nobody knew what bugs existed or what features were needed until someone in sales who talked to a customer ran downstairs and recapped their last customer call. Builds were not reproducible. How we decided what we released to the world was we'd poll the room. Who could actually compile the software today without errors? That person would build whatever was on his workstation, debug symbols and all (because the release builds crashed), and package it up for the customer. How did we know what we were releasing works? There was one QA guy, who worked on the assembly line. They'd flash the software onto a single device, and make sure it still booted. Ship it! How did we plan what we were doing for the next N weeks and months? This one's easy--we didn't! The CEO or someone in sales would run downstairs and tell us "We just sold XYZ feature to a customer. We need everyone to drop everything and make this by the date we also negotiated with the customer!" I think "no process" software development only works for a single developer, or for a very small (less than 3 person) team of absolute experts. Mix a single junior person into the team or add more than 3 or so developers, and it's going to be chaos.
- SillyUsername 4y ago
  Couldn't agree more with this and above poster. Having weekends back by less failing systems caused by cowboy unreviewed code and no crunch caused by inadequate planning are for me the main social benefits of agile.
icedchai 4y ago
Yes. And sometimes those things still happen with "agile", too.

conatus 4y ago

> You'd meet about what you were going to do, work on it, and come back a week or two later. Occasionally there would be informal check ins. Planning meeting, ad hoc meeting doing the work then weekly/bi-weekly show and tells to show progress. Sounds like...some version of agile? Remember agile and the XP movement that preceded it was invented by software makers, who had observed the pattern you describe and decided to be self-conscious about it.

icedchai 4y ago
It was true agile, not "Agile" in the sense we see today (empty ceremonies, time wasting meetings, micromanagement, endless jira tickets...)

hk1337 4y ago

Things were better before agile / scrum moved from the developers doing it to project managers doing it.

t43562 4y ago
"Project Management" and "Agile" IMO are completely opposed concepts so no wonder project managers don't get it. They still want jobs however so now presumably it's perverted agile.

narag 4y ago

That's exactly right. There were good and bad things. Some method was needed, but too much method is lethal to productivity. Agile was sold as less rigid method, but for many shops it's simply too much. You need first to make it work, later to make it perform, then to optimize it, finally to trash and replace it. Many go right away to optimize then stall.

xiphias2 4y ago

I read this all the time and see that software engineers don't even read the agile manifesto: ,,Individuals and interactions over processes and tools'' What you are describing is the opposite of agile

icedchai 4y ago
The truth is that the manifesto may as well be fiction. I'm talking about reality... what the industry actually practices as "Agile." That's why you read it all the time: because it's true.
- xiphias2 4y ago
  Maybe it's true at some companies, but it has nothing to do with agile / scrum, but letting non-tech people who love confrontation take over engineering leadership from engineers who are afraid of confrontation (which sounds like the disaster it is). Robert Martin (one of the creators of the agile manifesto) explains it quite well in ,,Clean Code'' presentation: https://www.youtube.com/watch?v=7EmboKQH8lM https://www.youtube.com/watch?v=7EmboKQH8lM The whole presentation should be a must watch by all engineers so that they understand what _is_ agile to the point when they know it better than product / project managers / non-tech people. It's hard to get a better description than the original source, and no non-tech person has authority to override the real agile at that point.
  - icedchai 4y ago
    I'd be interested to know what percentage of companies are "true" agile. Based on my personal experience, it must be very low.
    - xiphias2 4y ago
      It's not rare in my experience. It's basically a bunch of experienced engineers getting together for a weekend warning inexperienced engineers about newbie mistakes, like obsessing too much about new shiny tools / frameworks / processes created by people from the past, or leaving mess behind. At Google we were doing mostly agile actually (didn't really have any complex process, but had quarterly goals to check ourselfs and get feedback, also weekly check if we are going in the right direction). ,,this week'' snippets about what we're going to do this week. All light stuff to make sure that it doesn't hinder real coding work. Cross team work was much more messy of course, but inside teams this worked fine. At another small company I worked it was almost the same, we just didn't call it agile.

grecy 4y ago

> they kind of just "did things" without any well defined process That's called making it up. While it may have worked for that organization, I assure you it falls it a heap 99.9% of the time large software is developed that way.

Eduard 4y ago

> This was how things were until roughly the early 2010's. "Mid 2000s" for some of us at some places, unfortunately.