Yet Another Post On Scrum, But Different

Everyone hates Scrum, or at least it seems so, except for management.

I did as well, but a difference is that I started my career in 1981, long before the hordes of Scrums took root.

1981, you say, so you must have done Waterfall, so you are old and have no idea how mighty today's Process is! Or how shitty, in some cases, depending on your point of view. But I only retired in 2021 after being tired from working long hours in the land of Scrum, which is to say the land where whatever we were doing was called Scrum because it's the thing we do, even if it's not anything but Scrummy.

I first saw Scrum being attempted while on the mobile team at the Travel Company (between IOS 5 and 7+), which is still a brand but not an actual entity. We had several mobile products (mobile web and orchestration API on AWS, iOS apps, an Android app, and some internal apps). Our process was very relaxed; our team was small (20 people) and mostly sat together with a single manager. Everyone worked on almost everything; in my case, I was responsible for all four iOS apps. We did about 80 releases a year; generally, changes affected all client apps.

Upper management decided we needed to be like the rest of the company (with around 600 people on the web team) and did Scrum. They did about three releases a year, and everything took forever. So they hired a Scrum Master (newly graduated from Scrum Master training with one small previous job switching a Waterfall-based hardware team to Scrum) and assigned him to us. He now insisted we all follow a strict Scrum process with all the bells and whistles and limit ourselves to a single project at a time, with two-week sprints and daily standups (of all 20 people in one Scrum).

Well, that went over like a lead balloon.

Suddenly, we could not ship anything because changes that had to be made in all clients were delayed (some changes, like FAA legal requests, had to go out together and immediately). Meetings took up way too much time. He even insisted that user stories had to be written for every feature and change, even if it made no sense. After a month of this, management started to complain we were not getting anything done. After this, we decided to stop doing Scrum because we had deadlines that often lasted a single day and could not wait for one or two sprints. The Scrum Master, who had started gung-ho on doing all this, watched us crank out things at our usual pace and quality without him and became disillusioned, finally quitting to become a build engineer somewhere else. Our little mobile team made most of the profit for the company, so messing that up didn't last long.

My job after that (our brand was sold, and all 1000 employees were laid off over a year) also did "Scrum," but our daily standup was done sitting down, so it was just a meeting, and no other Scrummy thing was done, so the process was more or less hand-wavy.

My final job lasted 5.5 years. I was at a massive company in a large division on a relatively sizeable, multi-functional team, but my iOS team was small. During that time, my team consisted of 2-5 people, plus QA. But the company did "Scrum". We were supposed to do Sprints, Grooming, Retros, and Standups, and we had User Stories for everything with estimates. But, we were supposed to estimate entire projects at once (often in only a few hours), meet deadlines conceived before the project even started, and have daily burndown charts showing progress to that date (estimates were really for budget purposes). The company also did Scrum-Of-Scrums, a higher-level meeting across all the teams that acted together. Everything we did supported the division's (usually a business unit)  overall business (not tech), i.e., unrelated products. There was something like a hundred teams overall, including client and server and database teams, product teams, testing teams, etc.

None of this worked very well. Estimating a project with a pre-conceived deadline is pointless; for political purposes, the only estimate allowed had to match, which was dumb. Additionally, the deadline changed, sometimes for no apparent reason. On top of that, change requests happened all the time, requiring an independent estimate even if they were related and many could be made simultaneously; every change was required for shipping, and often, the deadline was not adjusted until it was hit. Burndown charts looked like sawtooth waves, but executives complained we didn't hit the original guess. The initial budgets were often left behind after so many changes but could not be changed later, so budgeting had to be creative.

Does this sound like Scrum to you? It did not to my team or any developers, but the official policy was that we did Scrum! We are modern; we do processes like fancy companies do! Somehow, we creatively shipped things that worked and made real money. I could say here I have no idea, but that is not true.

I remember when the process was whatever we did to get the project done. In the '80s and early '90s, we shipped software without tickets, user stories, sprints, standups, retros, change requests, or even email. We didn't even have project managers. In my first job at a Defense Contractor, all we had was programmers, programmer-analysts, managers, and people who needed code written. In the two companies I started in 1985 and then in 1987 until 1994, we built three major Mac apps (4 releases of Trapeze, part of Persuasion 1.0, and five releases of Deltagraph) without any of the Scrummables. We had no email until 1991. For Deltagraph, the publisher's Product Manager, my team and I developed all the features and UI, mostly by phone and FedEx. Fedex shipped the bug database back and forth. Insanity, it would seem, compared to today, but we got a lot of work done without any official process.

Oh, and I didn't hear of Waterfall until 1997, but I never did anything resembling that process. Process, after all, is basically communication: what needs to be done, how we can do it, how we are doing it, and when it will be done. For larger multi-team projects, you need more communication since you have dependencies. That was what I saw until the Travel Company. Sometimes, it worked well, and sometimes, it was terrible. Scrum is just one way to do it, yet it is often the only "official" process today. I imagine in some circumstances, Scrum can work well, and in others, it sucks big time. The same is true of every process. Ideally, you want to find some way to organize what you need to do and get it done in as optimal a way as you can discover. Rather than insist on picking something and sticking with it no matter how badly it is working (assuming those in charge are honest in their evaluation, which is often lacking), decide if something else might work better. It's not easy changing your process, and it can be scary if you make a terrible choice. Scrum may work for you, but only if everyone is willing to be limited by it. It also only makes sense if your business, industry, company, or team is compatible with those limitations. Sadly, I have not seen very many high-level executives actually understand Scrum or any process, much less be able to provide a more sensible option. I worked at one place in the mid-2000s that decided they needed a new process—it took more than a year and, when released, had 15 stages with meetings, documents, and sign-offs—and that was before any code was written, which was simply the last step. The point was IT did not want to write any more code, so the process was designed to ensure that!

Is there a better process than Scrum, or is it terrible but the best we can do? Ideally, you want to optimize your process to get more done with less pain. Sadly, figuring that out may also be painful. There is no easy answer, and no one should tell you otherwise. Every situation may be different and require you to find an optimal way to determine precisely what happened in those early decades. Product demands are more extensive today than in the '80s, but in the end, a process is still communication between people. The teams are bigger, but more technology is available, which is simultaneously helpful and awful. In the old days, we relied on primitive means (phones and FedEx) and personal communication. In my last job, I was the highest user of Slack at one time; I constantly talked with tons of people, including my team, all while writing code full-time and being the lead, which may be unusual. But given my experience back in primitive times, I found it still worked for me, despite our Scrummish process.

So, if you are in a leadership position over a process, you need to be open to doing something different if necessary after honestly evaluating what you are getting out of your current process and looking carefully at how things could be better. Please don't rely on some consultant to tell you Scrum Is The Way! Or whatever they sell.

Perhaps, then, there will be fewer posts about Scrum and how evil it is!