“Why Scrum” for Software Developers
Many software developers working in a Scrum environment see Scrum as a “company tax” — additional overhead they need to adhere to because their company expects them to. Dailies, reviews, refinements, and retros are seen as ceremonies; something you have to endure that don’t really add much value to your work. If this is how Scrum feels to you, you’re not alone.
In this article, I want to explain why this is a common experience, what IS the value of Scrum, and how a small but crucial rethinking of our role can make all of it click.
Playing a different game
Imagine you’re a hired gun. A stone-cold killer. All you need is a little name on a little note, and that person is gone. GONE. Anything beyond that little note would seem like an awful waste to you, wouldn’t it?
Now imagine you’re that same stone-cold killer, invited to the big-boss meeting where they decide whose name gets to be on that little note. What does it matter to you? They will make their choice and you will do your job. You sit and keep your cold long stare while they bicker and argue. It makes no difference to you.
Does that feel a bit like being a developer in a Scrum environment? That’s because Scrum doesn’t play the game you think it plays: Scrum isn’t the story of a collection of lone killers, waiting for their Boss, Mr. Big-shot PO, to give them a little note, with the only expectation being that he hears that the job’s done.
Are you a Partner, or are you a Gun?
The game Scrum plays, rather, is one where you’re a partner. A partner’s fortune or downfall rides on that being the right name on that envelope. A gun gets paid no matter the name.
Many developers rightfully feel like fish out of water when they are being hired to what they were told is some software work, but find themselves thrown right into the partners’ meeting room. If you’re working in Scrum, it’s hard to avoid: Reviews, refinements, those sessions are exactly about which name needs to go on that little note, and very little about how the job gets done. It’s for partners, not guns. But what are you?
Scrum is for Product Developers
Product development is a highly complicated, cross-disciplinary, dynamic work. Just like software development! But with the added edge that even if well executed — most products fail.
Scrum is designed to handle a reality that’s dynamic, complex, and very, very risky. And it does so by simplifying every parameter it can. For example, it treats all the participants as equals. We’re not either guns or bosses. In fact, we’re not playing Cowboys at all!
We’re here on the serious joint venture of putting out a successful product to the market, and we’re doing it together, as partners.
In Scrum, the feeling of participants needs to be that of partners, not that of guns: Since the stakes of Product Development are high, the vast majority of participants need to be sensitive to these stakes.
Scrum tackles the challenges of Product Development, NOT Software Development
If up until now you’ve seen yourself as a software developer rather than a Product Developer, it can indeed be hard to see the value of Scrum. In fact, Software developers would feel like fish out of water in Scrum, because they would be — Scrum has little to offer to the work of the “gun”. How the gun gets the name off the list is their business; Scrum is mostly concerned with making sure it’s the right name.
Scrum expects that the majority of its participants are Product Developers. It wouldn’t make much sense otherwise. Indeed, in most dysfunctional Scrum environments, you’ve got guns and partners treating each other like partners and guns, and the cacophonic outcome you would expect from such a setup is a guarantee.
As a software developer, graduating to become a Product Developer is a choice. You can stay a gun if you want, that’s a respectable career. And you can even be a gun in Scrum if enough of your teammates are partners.
But if you want to be a Product Developer: Someone who not only builds for the sake of a paycheck, but also builds for the sake of delighting, exciting, solving, and helping? Then you must first internalize the challenges of Product Development.
Product Challenge #1: Product success is RARE
Consider the following:
- Most products fail (Startup Genome 2019 report claims 11 out of 12 startups fail).
- Even in successful products, only a small subset of the implemented features contribute to the success, and/or see habitual use.
In other words, almost anything you would set out to do will fail. This is true on every scale: From the whole venture itself, to one of its smallest components.
In his article, Nacho Bassino provides a list of academic research and internal company research, all saying the same thing:
…the failure risk is high, and having so many good companies and product managers failing should teach us that the most likely scenario is that we will have similar or worse rates ourselves.
- Nacho Bassino
As Software Developers, our expectation from a process is that it would optimize for how efficiently and clearly we get the requirements and then give us the maximum amount of time to spend implementing those requirements. Through this software developer lens, Scrum definitely seems to be an inefficient process, with its constant interruptions in the form of refinements, reviews, and rapid requirements&priority changes. Just give me the goddamn name, leave me to it and let’s talk when I’m done!
But with our Product Developer hat on, any feature or product we spend time on that doesn’t return the investment is already a waste. It doesn’t matter how efficiently we built a set of requirements if they were the wrong requirements. In fact, if even in the last minute we could discover that our requirements are wrong and find out what the right ones are, then, holy smokes! That’s a deal we’ll take all day! Let’s stop building the wrong thing as early as we can, even if we’re already nearly done.
Think about a gun who’s been staking his target all night only to get a note from the Boss the moment before he pulled the trigger: “Mission’s off: here’s a new name”. If that’s how Scrum feels to you, that’s because you’re not feeling the immense pressure of how expensive getting that name wrong must be. You aren’t a partner.
Scrum addresses the high failure rate of Product Development by actively engaging the brainpower of all participants in the business of achieving success, and encouraging the organization to address & validate risks early and often.
Product Challenge #2: Circumstances are rapidly changing
We are living in fast times — the rate of technological, cultural, and product change is truly dazzling and only threatens to increase. In other words, The amount of unpredictable stuff that can happen between when you started working on your product to when you launched it? It’s high, and it’s only getting higher.
The ability of the product development effort to identify relevant change and react to it is therefore increasingly important. You can’t be expected to go in a shed for years and come out with a winning product. Nowadays, in those years, more likely than not, a competitor will beat you or a shift will occur that will invalidate the assumptions you had when you went into the shed. The right idea also needs the right timing, and the timing window is only getting tighter and tighter.
The earlier you realize that your plans need to change, the cheaper it is to change them. This is true for big plans (e.g. whole Product predicates) and small ones (e.g. features).
Scrum leverages short feedback loops in order to allow Product Teams to react to changes early rather than late.
Product Challenge #3: Productizing is a multi-skilled, cross-domain challenge
While software-based Products definitely have a major Software development component to them, to the point that I felt the need to write an explanation to software developers about how they found themselves in the Product Developer’s realm… It’s far from the only domain, and it’s also not always the most mission-critical one.
Imagine you’re writing a tool for yourself to optimize your workflow. Maybe a command line tool that automates some manual tasks you find yourself having to do on a regular basis. Once you’ve developed it and it’s working for you, you start using it and move on with your life. You’re done!
But what if you wanted to productize it? I mean, really make it into something people would say “I’ll pay for that”. Heck, maybe even be excited enough to tell their friends. How far are you from “done” now?
Very, very far. In fact, your journey has merely just begun.
This gap IS the difference between Software development and Product development.
Productizing requires adding auxiliary features and polish to the point that it is available for mass consumption, appealing and streamlined enough to compete in the saturated market of products, is marketed enough to appear on the radar of potential customers, and can be monetized.
No matter how well your tool is crafted to achieve its purpose, if one or more of the above components is missing, it will not be a successful product. That means that even non Software Development activities can be an INTEGRAL part of Product Development. Whatever is needed to achieve product success is part of Product Development.
Traditionally, each activity above would be done by a separate department. Increasing headcount, organizational complexity, and ultimately, cost. It would make feedback and learning take longer to percolate through the system.
Remember how I explained earlier that Scrum deals with the complexity, immediacy and risk of Product Development by simplifying everything else (usually, that’d be us)?
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.
Scrum is concerned with the entirety of the Product lifecycle. It is not intended to be used only for R&D. Scrum aims to simplify the Product creation venture by empowering cross-functional teams to handle many different but interconnected domains, instead of trying to allocate roles&responsibilities to individuals, which leads to overly complex, expensive, and ultimately less agile organizational setups.
Scrum deals with the complex, cross-domain, multi-discipline effort required for successful productization by removing specialists, departments, and roles.
There is only one role: Product Developer.
My previous article on team-based organizations goes into detail on the organizational implications of this.
From Software to Product Developer
I don’t know if I have you hooked or if I have you scared. Remember, being a Product Developer is about making a real impact on the world by creating something that people actually want to use, so of course it’s a bigger challenge than just building something in general. If impacting the world is what you’re out to do, I’ll do you the courtesy of being straight with you about it: It’s no walk in the park.
But, you’re not alone on your venture: Scrum is a collection of Partners working together, understanding each other’s strengths, preferences, wishes and tendencies to organically figure out the perfect configuration that can achieve something that none of them could achieve on their own: A successful Product!
Even this article is a product in a microcosm: I am like a one-person Scrum team in charge of a product called Scrum Articles, handling all tasks and domains related to getting an article out there in the world for you to read. My writing craftsmanship accounts for the quality of the article, and if you’re reading this, then it’s probably good enough for the task. But if you’re one of the far more likely those who will never even hear about this article, that’s because my marketing skills are lagging behind.
Unfortunately, marketing isn’t my forte. I’m not great at everything, nobody is! If I could add one more person to my Scrum Article team, would you recommend that I add another strong writer/weak marketer? Or maybe I’d be better off with a strong marketer/weak writer? If the latter, then you’re starting to understand why a Scrum team shouldn’t just be a collection of Software Developers.
The magic of a good team is in finding ways to multiply each others’ strengths in ways that overshadow any weaknesses. This is the meaning of a team being more than the sum of its parts, and Scrum explicitly seeks to unlock these kinds of dynamics.
If you’re only here to do your one narrow thing; getting a name off a list, you’ll likely not experience that, and Scrum wouldn’t be a fit for you.
Conclusion
Many software developers’ first encounter with Scrum starts with misaligned expectation: That Scrum is just another system that churn its wheels and spits a name at them (maybe with the gears more awkwardly exposed than they’d have liked).
But Scrum is a Product Development framework, designed to tackle the challenges of Product Development. These challenges: High failure rate, rapid action&reaction, and complex multidisciplinary work, are quite different than the challenges of Software Development.
Scrum may not efficiently spit a name at you, but it does something more profound: It extends a hand, invites you in, and if you let it, by the end of it, it might just show you that you’re more than what you thought you were going in. You might discover that you’re a Product Developer, out to change the world.
