And then there was Scrum

Background

Don’t be surprised. I already wrote a pretty lengthy article – “Scrum. From developers perspective“. However, I’ve received some “complaints” as well arguing the length of the article itself (hint: it’s pretty lengthy and goes into the depth of it).

Hence, I’ve decided to write a summary of it. And this is what this article is all about. If you want to go full length, which I wholeheartedly would advise you to, then, by all means, go and read “Scrum. From developers perspective” first.

Why Scrum?

In order to actually understand WHYs, you really need to understand what was there BEFORE it. How the expectations were set and projects were managed.

The truth is that even if it seems old to us, software development is really an infant compared to other sciences. To give you a clue – architecture dates back to over 10.000 years ago, whereas mechanical engineering is, according to Wikipedia, around 6.000 years old. That means that people had a lot of time to figure out what works and what doesn’t, and surely many have blown themselves up to pieces in the process. But still, it was a looong period to actually figure the stuff out. As for programming? We’re talking 70 years in the MOST OPTIMISTIC case! It’s more like 50 years, give or take. Now tell me, how old the programming really is, eh?

Can you imagine how architecture looked like 10.000 years ago? It surely sucked, right? And yet, the software development apparently seems to work. More or less, but we seem to have figured out how do to it and we did it in a rather short time. So, the question is – HOW we did it?

Well, the answer is – we sucked at first! The first “programmers”, who actually were mathematicians and statisticians mostly (because, you know, back in 60s you had no new grads who were studying software engineering), had no clue how to build software. Because there was no framework for how you actually build software.

You know what they did? They relied on a simple and proven tactic – write code, run tests and deliver as soon as possible. Pretty much they had “daily sprints”.

Well, as time went on and more complex projects came, people started looking into other areas and they borrowed the frameworks from manufacturing. Analyse, specify, develop, test & deliver. Sounds perfect but kept failing miserably (if you want details, you should read my original article – Scrum. From developers perspective).

Enter Scrum & Agile

People seem to keep confusing Scrum & Agile. Again, I wrote in length about it in my original lengthy post. I’ll give you a short version here.

Scrum was a framework devised back in 90s. The idea was initially introduced in 80s under the name of “New New Product Development Game” (New New is not a typo but a part of the whitepaper name) and it got improved and built upon during the 90s. And in a nutshell, the main idea was really simple — give people a structured way of how to build software projects.

Do note that Scrum wasn’t the only kid in the hood. There was Extreme Programming (XP) and others as well, because, you know, people pretty much figured out they need a better way of building and managing complex software products.

Now during the 2000s, those same people who pretty much worked on similar things under different names, managed to gather together in a Ski Resort and come up with a common name for everything that was considered to be a “proper way to build software”. Hence the name Agile was born (which, btw, from what I understood – pretty much everybody disliked).

So Scrum is a name of specific framework and practices that you apply in order to build software products. Same as Extreme Programming (XP), SAFe, Lean, Kanban, etc. are. They are guides and practices that you follow in order to build software.

Agile, on the other hand is a name of “philosophy’ that unifies all of those ideas under the same “roof”. So all the frameworks from above are called – Agile Frameworks. And that’s pretty much it, in a nutshell.

Why Scrum, again?

Because what else would you do? How else do you manage the projects? Sure, you can use Extreme Programming or any others, that’s a proven way to go as well. But not using anything? Well, trust me, you’ll suffer long term.

Scrum and other Agile frameworks give you the answers. They give you a guideline. They tell you how you answer the “how long will it take”, “how far are you from finishing” and “can you show us something ASAP” questions. They help you when you get stuck and need to brainstorm. They tell you how to keep your project going!

Take my word from it – by not having a clear framework or methodology that you are using, YOU, as a developer, are on a loss, long-term.

So pick whatever you want, but do have something! And if your company doesn’t have a process – what a great opportunity to introduce one!

Conclusion

If you are building a software product and don’t have a process specified – you are at loss. Unless you enjoy the chaos, in which case, just keep doing it really.

Scrum and any other Agile framework are there to help YOU, the developer, build and deliver stuff. And it helps YOU set the stakeholder’s expectations properly. And it does so by giving you clear guidelines on WHAT you do and HOW you communicate.

If you want to learn more and in-depth, I’d advise you to read my lengthier article – Scrum. From developers perspective.