Not much different, really. Most of the so-called agile features existed before with different names. Waterfall is widely caricatured to contrast with agile, but I rarely saw it work much differently in practice. Having worked with both, and after getting certified as a Scrum Master (for what that’s worth), I think the main difference is how much analysis and planning gets done in advance of coding. Too much and the process gets locked up in analysis paralysis and over-ambitious plans (and schedules). Too little and the team has false starts and can veer too far from requirements, or discover important requirements too late.

The defining bad characteristic of waterfall is getting stuck doing a lot of planning and then the plans and schedule don’t change or take customer feedback into account. This doesn’t have to happen but it can and does.

The defining bad characteristic of agile is getting stuck with a lot of half-baked code programmers have their egos invested in, before requirements are fully understood. This doesn’t have to happen either, but it does.

One thing I like about waterfall is having the goals and roadmap defined, so everyone has the big picture. The goals and map might change but everyone sees the changes. In the agile/scrum projects I’ve worked on many didn’t have clear goals, map, or a shared vision, the “conceptual integrity” Brooks writes about. Cards with user stories doled out in sprints aren’t a big picture.

One thing I like about agile is acknowledging up-front that generating complete and unambiguous requirements in advance is impossible for any non-trivial project. Requirements will evolve from feedback and collaboration and discovery. But without a shared vision of some kind it’s just a jazz odyssey, to paraphrase from Spinal Tap.

Errr.. you dont need to live in the past to avoid scrum. A whole bunch of places dont do scrum right now. If you dont like it, just join some place that doesnt do it.

I started before open spaces... so work life was quite different back then. But yet, it doesnt really matter. In the end there’s what you need to do. And different levels of involvement from managers and co-workers.

People were perhaps more chilled...

> A whole bunch of places dont do scrum right now. If you dont like it, just join some place that doesnt do it.

Can you give some examples? As far as I know all the high profile tech companies that everyone tries to emulate use scrum internally. It exists in some form at most places. For the organizations that don't do scrum and the company isn't doing well, it's only a matter of time really ... as the allure and promises made by the scrum cultists are too hard to resist.

I'm not entirely against it. When used properly, scrum can deliver lots of value and lead to a productive working environment. However, it can also be easily weaponized by (mediocre) management leaving few corrective levers. In highly political environments this may still result in passable productivity but low morale and high turnover nibble at it over time.

Google doesn't, I know I worked there. I'm pretty sure Facebook doesn't either.

Some teams at Google uses standups, extremely few uses scrum with sprints. At least from message boards I didn't hear of anyone even talking about sprints or anything related to scrum. Google focuses more on individual responsibility and project/task ownership. Junior engineers gets to own small tasks, and as you move up the ladder you get larger and larger projects.

Edit: A "small" task at Google could be a multi month venture btw, so not really "small" in the context of scrum. It could be to implement and deploy a service designed by a senior engineer etc.

Edit Edit: The ladder even says that as a junior you independently complete tasks no longer than 3 months long or something like that. So giving a 2 month project to a junior engineer and letting him drive it and work on it on his own is expected. That sort of project ownership and experience doesn't exist for juniors in any scrum setting.

Can you name a high profile tech company that does use scrum regularly across teams and groups?

It’s my impression that scrum is largely the ___domain of companies that outsource their tech to consultancies not those that have large engineering teams of their own.

I’d be shocked for instance if any of the faang companies dogmatically applied scrum.

I've mainly seen Scrum with outsourcing companies. It doesn't seem to help them produce anything useful and on-time. It does help them refer to their "process" and obfuscate what's going on (or not) with Jira and weekly check-ins and "sprint planning" meetings and so on. It's not really Scrum, just a simulacrum intended to make the client feel like something is happening.

I'm sure all of our experiences differ, but in my experience, the senior folks would "own" a piece of the puzzle. Depending on the scale, that could be a feature, an app, or in Enterprises, multiple platforms. You'd often be on a team, with each member being primary owner of some areas, and other people cross-trained to back you up. You owned your area like a Scrum PO would, sometimes with your own team to help, while your manager would be the liason with the business to find out what their new needs were, then hand it off to you to make it happen.

For projects too large to take on yourself, there would a be a project manager would would pull everyone together, talk about what needed done, plan it out, and you'd do your part, with the PM checking in on everyone, coordinating meetings, and making sure everyone was on schedule.

That is really where Agile came from - breaking down those knowledge silos, sharing responsibilities, and trying to deliver progress in small chunks vs. 6-12 month projects that would waste an entire year if you got off-track.

If only. The last place I worked that used agile/scrum deliberately created silos anyway. They had a schedule devised by management and the product owners that was opaque to the team. Requirements got doled out every sprint in a disconnected way that prevented anyone knowing the big picture. A disaster, of course. Not an indictment of agile/scrum, but this kind of thing seems more common that the ideals promised by The Agile Manifesto.

I tend to agree - "Scrum" often means some formalized process that goes through the motions of Agile, but misses at least half of the principles behind it. So far, every single Scrum team I've joined ends up falling back to "Someone said this in a class/book/training session, so it must be the right answer, so we'll do it." Not that the books or classes are wrong... but you are supposed to customize the processes to the needs of your team, not follow a rigid script. Scrum is a tool, not a goal.

Agile Scrum was created as a response to Waterfall. Waterfall was, generate a giant spec, like 50-100 pages, then set the developers on it.

Uh, no. That’s a caricature of the process.

Waterfall projects can have all of the important attributes of agile: collaboration with customers, feedback and refinement, intermediate deliverables, etc. They don’t always work that way, but neither does agile. The main difference is the amount of analysis and design done in advance of writing code, and the relative emphasis placed on formalities and artifacts.

In practice agile, especially variations of Scrum, have grown to include rituals (stand-ups, sprint planning) and artifacts, which can turn those projects into coding with no guardrails or clear destination.

Fair enough, I didn't mean to imply that the entirety of waterfall was just that one line. The point was that scrum, with all of its flaws, was meant to correct a then existing perceived bad practice.

Before scrum and agile, there was MS Project, Gantt charts, Excel spreadsheets, bugzilla, etc.

Basically, there has always been some (project) management overhead that you need to pay lip service to. The trick is not to take it too seriously, you can play along with it, provide updates here and there... but still just do what you think is right, in the order you think is best.

No question that project management can range from useless to intrusive. But paying lip service and ignoring it isn't the answer.

Programmers who just do their own thing and play along with or ignore the project requirements, schedule, users, and the rest of the team are not contributing. They are doing what they feel like doing on their employer's time. Every developer can't just decide which requirements or schedule obligations to pay attention based on what they "think is best."

Scrum doesn't matter. Are you working for someone that can do your job better than you? Are you learning new things? If not, go somewhere else.