For the older techies, how was life like before scrum?
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.
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...
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.
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.
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.
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.
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.
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.
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."