Scrum. From developer’s perspective.

Background

Funny enough, every Scrum related article that I’ve read was written by Scrum master / coach / advocate / whatever. Or, at least the ones that present Scrum in a positive light. On the other hand, most developers that I know, either dislike it or have heard negative things about it. I do know a few people who happen to be both developers and in favor of it, but they’re in minority.

Let me get straight to the point immediately – I’m a developer and I like Scrum. There I said it. The value that it creates, if implemented properly, can be massive.

Before you start throwing rocks, bones, tomatoes and other kind of garbage towards myself, please spare a moment to actually read the article first.

Before we begin

Before we embark on the journey of why I believe Scrum can be useful, I think it’s worthwhile making some things clear first:

1. This article is long and that’s how I envisioned it. If you want tl;dr version – just jump to the end of it where the conclusion is
2. I strongly believe that the best way of understanding stuff is learning how they came to be in the first place. Hence, I’ll spend the first part of this article describing the “what was there before scrum”
3. We (developers) are used to thinking that building software is about programming only. But that’s usually because we don’t see what happens before/after that; and there’s a lot going on. Software development of complex products involves – requirements gathering, sales pitches, clarifications, presentations, testing, deployment, training, maintenance, etc. Programming is just one part of it really.
4. As Wikipedia article states, Scrum is an agile framework for developing, delivering, and sustaining complex products. What this means is that it makes sense to use it only if you need it. Doing scrum for the sake of doing it, usually results in overkill, especially on products that are way better without any framework or process at all.
5. This article will NOT go into details of how Scrum works. Instead, I will discuss the reasons of why it came to be as well as the general concepts it advocates and why I think it’s a useful tool in a toolbox. If there happens to be enough interest though, I will write a follow-up article with distilled version of how to use it.
6. Finally, for crap’s sake, it’s Scrum. It’s a name and not an abbreviation. It’s borrowed from rugby where it resembles the formation that you can see on the image on top of the article.

Now that we got the important things out of the way, if you’re still interested in reading my view on the subject – I’ll start with a history lesson.

“Little bit” of a history

As I mentioned before, I deeply believe that discussing any matter should involve some history first. As in – how and why the whole Scrum and Agile concepts came to be and what were the driving forces behind that. Scrum was published as one of the solutions to the problem that existed in the pre-agile era, and, even though it might not be perfect, the problem that it tried solving was, indeed, a real one.

Let’s go back to 70s and 80s. Yeah, believe it or not, even though it sounds like medieval age, people did, indeed, develop programs back in the 70s (according to Wikipedia, first program was written in 1950s). What people used to use back then is, what we refer today to as “traditional software development methodologies”. In short terms – in those days, as software development was a pretty new kind of a thing, there was no real battle-tested way of developing software efficiently. So, what they really had to do is to rely on methodologies that were used in manufacturing processes (e.g. building cars). One of those being a Waterfall model.

I won’t go into the details of how the waterfall works, but for the sake of understanding the Scrum itself, I’ll give you a really brief description. The primary idea is that you have couple of phases that you go through sequentially. First, you define what you want to build, then you program it, then test it and finally you ship it to the end-customer (remember – this was in pre-Internet era). And it all worked fine … not.

First problems

It’s funny that, ~60 years later, we are pretty confidently exclaiming “software development is not the same as manufacturing!”. The problem is that, back in the day, that wasn’t really a common wisdom. Hence, people struggled; a lot.

One of the main problems was the fact that each phase of the process was being carried out by a different group of people. For example – first you had analysts and managers collect the requirements, which were later handed to developers, who, once they finished programming, were sending software towards testers who, eventually, after finishing the tests, passed the software towards the client. But what happens if requirements are unclear? Or if customer wants some changes to be made? There was no clear definition on how to do it and you usually had to start from Phase 1 and go through the whole process again. Rinse & repeat until you get it right.

You see the problem already? When it comes to manufacturing, you usually have a pretty strongly defined process on how you manufacture stuff and you definitely don’t see customers asking for small changes here and there. For example, if you are producing a car, the assembling process is always the same, more or less. But software is different, and I guess it’s because it’s “so easy to change”.

This led to various solutions, one of them being the V-shaped model, which was kind of an extension of waterfall model, but with some improvements. In reality though, even though people tried many solutions, and many of those did work, it still required a significant mind shift.

Enter Scrum

Scrum originates back to mid-80s (yeah, that’s ~40 years ago!). Its main selling point was that, instead of having separate groups of people carrying out separate phases, you have one cross-functional team instead. This team moves back & forth through the phases, but does so together. The term itself – scrum – got borrowed from rugby. It is a formation that looks exactly like the picture at the beginning of this article.

In layman’s terms, Scrum was presented as a set of tools that were battle-tested and proven to be useful for development of complex products. Now, please note, it is a set of tools and techniques that you can use at your own will. That’s what makes it a framework and not a process.

What really happened behind the curtains is that two guys, Ken Schwaber and Jeff Sutherland came up with similar ways of building complex products and around mid-90s, they eventually worked together to integrate those ideas into what is to become known as Scrum framework.

The key idea of Scrum, which I’ll quote from Wikipedia is:

Scrum is a lightweight, iterative and incremental framework for managing complex work. The framework challenges assumptions of the traditional, sequential approach to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.

A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited.

As such, Scrum adopts an evidence-based empirical approach – accepting that the problem cannot be fully understood or defined up front, and instead focusing on how to maximize the team’s ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions.

Source: Wikipedia

Agile manifesto

Now that you (hopefully) read the history part, you should be more familiar with the reasons of why scrum came to be. Basically, it came as a solution to a problem of how to develop software; effectively. And when I say “develop”, again, I’m referring to the whole process – from requirements gathering to shipping the working software. Programming is just one of the steps of a bigger process that happens to play out there.

Around the 90s, and early 2000s, and this is really important I’d say – more and more people started to understand that developing software is different than manufacturing products. Hence, more and more of them started adopting variations of scrum ideas. This eventually culminated with a famous Agile Manifesto being published in 2001.

I understand that not many people are aware of what Agile Manifesto is, so, I will give you a brief overview, but I definitely urge you to read the full article. What happened in February of 2001 is that seventeen people gathered together in a ski resort with the primary idea of publishing an official document on how to develop software effectively. Now, pay close attention, all of them were either programmers or were heavily involved in programming. Let me give you some of the names that you surely must have heard of – Alistair Cockburn, Ward Cunningham, Martin Fowler and Robert C. Martin. If you’re not familiar with any of them, I’d strongly advise you to start reading some classic literature on software development.

As you can see, this is not a random piece of crap written by some random coach-wannabe who didn’t spend a single day developing software. No. This is a document, written by seventeen hardcore programmers who have been building software for decades. And that’s what Agile Manifesto is – a list of core principles and guidelines to follow when developing software.

The general idea of this manifesto is that it’s (close to) impossible to build software by following the strict plans, documents and phases. Instead, the focus should be on giving more responsibility to people and trusting them to do the right thing. Customers change their minds and software evolves constantly, so, instead of whining about it, just accept it and collaborate more often. And that’s pretty much it in a nutshell.

Scrum, from developer’s point of view

Now that you hopefully read and understood the reasons of why and how it came to be, I think I can finally share my opinion on it. I like Scrum because it advocates some of the principles that are there to make developer’s lives easier. I’ll repeat that — Scrum is there to make DEVELOPER’s lives easier! Not managers, bosses, masters, coaches, or whatever. No. OUR lives. Simpler. Yes.

If that confuses you, I’ll give you some of the main ideas that Scrum advocates:

1. We all suck at estimating stuff. As in, we suck at estimating how long will something take in terms of time (i.e. hours, days, weeks). But we are really good at comparing stuff relative to each other. As in – we can easily deduce that THIS is way more complex than THAT. Hence, Scrum proposes to use relative measures instead of estimates.
   
   Let me give you an example. If you have number of tasks that need an estimate, instead of pissing in the wind and providing time estimate, what you do is you compare the complexities of the tasks that you have. As in – ok, the task A looks more complex than task B, task C seems way more complex than A. You can do that pretty efficiently and research has proven that you’d be right most of the time.
   
   How do you put that into something tangible though? I’ve seen different teams and companies use different things, ranging from t-shirt sizes (S, M, L, XL), points (1, 5, 10, 20, 50, 100) and even animals (e.g. ant, pig, cow, horse, rhino). It doesn’t really matter what you are using as long as you understand the purpose. If we take t-shirt sizes as an example, task C (most complex one) would be XL, A (bit less complex one) is M and B would be S.
   
   Fun fact: I didn’t know it until recently, but there is actually a so called “planning fallacy” which tries to argue why humans suck so much at estimating stuff. What I found funny are all the examples of failed plannings! Google for “planning fallacy” and see for yourself. It kind of makes you feel good to know that it’s not just you, but everybody sucks at estimates. A lot!
2. Requirements change. Accept that and find a way to turn that into your advantage. Basically, Scrum recognises that customer’s minds will always change and that’s not because they are dumb suckers who don’t know what they want or need. No, that’s because it’s what happens in every aspect of life — ideas evolve. Once you see something, you immediately recognise how to change it or improve it. That’s just how we’re wired.
   
   How to turn that into your advantage though? By making mini-contracts! Instead of gathering bunch of requirements upfront and then working on them for 6-12 months, only to realise that it’s not really what customer wanted, what you do is create a list of things that need to be done and that were agreed on. That list is called – a backlog. Every change that is requested gets added to a backlog as a new request. Rinse & repeat.
3. The best way to reach a long-term goal is to break it into bunch of mini-goals. This is true for pretty much everything in life. The farther the goal is, as the time passes, the less motivated and more bored you become. What Scrum proposes is as simple stupid as it gets – whatever it is that you want to work on, break it into bunch of short term goals and celebrate small wins more often. There’s even a name for it – sprints.
   
   Again, every team / company’s culture is different and Scrum definitely doesn’t tell you how long the sprint should last. The proposed length is 2 weeks. That seems to be a sweet spot that gives you enough time to tackle complex tasks and at the same time keep you sane and motivated. But again, it’s up to your team to choose their preferred length.
   
   Fun fact: I’ve been reading / listening stories from couple of Navy SEALs. Funny enough, all of them agreed on one thing – the only way to survive the hell week (basically, the most stressful test that you can go through – five days and nights of no sleep and constant struggle) is to actually break it into smaller chunks. Some of them break it into six hour windows (i.e. time between two meals), some break it into hours, but you get the gist. If you think about the end goal, which is five days ahead – you will fail 99% of time. Your brain just isn’t wired to handle that.
4. Finally, trust thy neighbor. This one sounds simple but is actually one of the hardest things to achieve; at least in the beginning.
   
   Here’s a thought experiment for you – imagine you are about to paint your living room. And you happen to really love your living room, as you’re spending most of your free time there. Now, a friend offers a helping hand. You’ve never seen him paint before, but he’s a good friend of yours and you know that you will finish the job much sooner. How anxious are you to let him actually do it? Just think about it 🙂 If you’re like most of people, the idea of “losing control” can range from zero craps given to complete paralysis.
   
   Scrum makers, being aware of this phenomenon, came up with ways of building this trust. That’s where the dailies, reviews, retrospectives and other tools come in. These are all ways that, if done properly, help you build trust in your teammates. And having full trust in your team is what enables big and complex products to be built.

As you can see, what Scrum does is that identifies the most common pain points that do occur over and over again, and proposes ways to tackle them. That’s why, if handled properly, you have a framework that HELPS YOU achieve your goals. It’s because it’s made to help you do that. From developers for developers. Just like any other framework is. But you have to know how to use it.

Why do (some) people dislike it?

I actually believe this is the same shit story as the one of people hating PHP. If you’re not familiar, well, a good chunk of non-PHP developers have a certain amount of hatred towards PHP and people using it. Funny thing is – I absolutely understand where this comes from.

This is really from my point of view, but, I’m pretty sure that one of the main reasons why people hate PHP is because it’s so easy to use. As in – within literally minutes and without any understanding of what the hell you are doing, you can actually write some code that works. This, in turn attracts bunch of people who have no clue what they are doing and they start producing tons of shit code. And this cycle repeats itself and the outcome is – lots of shit code being written in PHP.

But does the fact that people use it to write shit code mean that the language itself is crap? Does the fact that you can use a hammer to break someone’s head mean that hammer is bad? Of course not! The tool itself is good for what it’s built, but if used improperly, it will do harm for sure. I would argue that this is exactly is the case with scrum as well.

I already mentioned that I’ve heard way too many horror stories about all the Scrum implementations gone wrong. Everything ranging from doing daily standups for the sake of doing them, all the way to forcing people to sit through each and every meeting that HAS TO take exactly 60 minutes, because that’s what guide says. Just … no.

Scrum is about team and unification and providing teams with tools to help them be more efficient while fighting the outer forces and changes. Anything beyond that is either due to lack of knowledge, bad company culture or mixture of both. I’ve been lucky enough to have closely worked with people who were certified and did understand Scrum at its core. But, oh boy, did I hear horrors from other sides …

So, do you need it?

Let me put this as blunt as possible. If whatever you are doing right now is working for you, for the love of god – just keep doing it and don’t freakin’ change that! Forget the Scrum or any other agile methodology. If you’re happy with what you are doing – just keep it as is!

If, on the other hand, you are feeling like experimenting or if your current development process sucks and makes you nervous – then you should, probably, consider introducing some kind of battle-tested thing. But please, make sure to either properly educate yourself first or to find someone who knows what they are doing.

You should also consider taking just parts of the Scrum framework and incorporating them into your workflow. For example, having clean & groomed backlog can’t really hurt. Doing dailies or weeklies could be a good relationship and trust-building tool as well. Retrospectives are pretty amazing technique. Generally speaking, you can try incorporating parts of Scrum into your workflow and seeing how that works. Some might argue that it’s not the “proper Scrum”, but if it works for you – who cares? The end result is what matters.

What else is there?

I’m only aware of the existence of other agile methodologies, but I’m in no way trained nor certified to discuss them. I’ll just mention a few that I’ve heard of – Kanban, Extreme Programming (XP), Scrumban (a byproduct of Scrum and Kanban’s intercourse). I linked each of them to a corresponding Wikipedia article. I’ve also found AgileAlliance.org to be a pretty valuable resource on the matter.

Conclusion

Scrum was developed as a solution to a problem of developing complex software effectively. It represents a set of battle-tested tools and ideas that were proven to ease the development process. That’s the reason why it’s called a framework and not a process.

Most of the hatred towards it comes from the wrong and horrendous implementations. This usually results in more harm than good and culminates with hatred and horror stories.

Finally, if you don’t have a problem with your current process and everything’s running smoothly – you don’t need scrum; nor you need any kind of change. Stick to what works for you!

Appendix: Where can I learn more?

If you want to learn more about the Scrum or agile methodologies in general, which I highly advise you to do, here are some of the resources that I found useful:

1. Scrum: The Art of Doing Twice the Work in Half the Time – this is a book written by one of the authors of Scrum – Jeff Sutherland. It’s one of the great starting points from the framework’s author himself
2. The New New Product Development Game – original Harvard Business Review article, published in 1986, where the concept of Scrum was first mentioned by Hirotaka Takeuchi and Ikujiro Nonaka
3. Agile Development: Lessons learned from the first Scrum – 2004 article published by Jeff Sutherland. Nice read on how and why they used Scrum and how it worked out
4. AgileAlliance.org – a lot of useful resources on Agile concepts
5. AgileManifesto.org – the Agile Manifesto itself, as compiled by its seventeen authors
6. The Phoenix Project – this book is not about Scrum per se (it’s about Kanban) but it gives an interesting overview of importance of agility and responding to change by sticking to agile principles
7. Software Engineering: Theory and Practice – this one is a bit broader but if you want to dig deeper into the development methodologies topic, this is a pretty handy resource to go through
8. Finally, I have couple of people that I follow on Goodreads and LinkedIn and I think they are a valuable resource as well. Just track what they are reading or sharing and you should be good to go. Here they are: Nathalie Karasek (certified Scrum Master), Bojan Shkordovski (certified Scrum Master) and Jurgen Appelo (author, speaker, and all-around agile-methodologies enthusiast)