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.
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.
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.