Intro to Scrum—and Why You Need to Use It
Some of you are probably wondering: what in the hell is a scrum, and why are some of my friends frothy about it?
Yeah, it can be a little confusing when someone busts that word out—
—and you still think it's the stuff they scrape off the bottom of ships.
But this funny little word is behind a huge pedigree of success—and there are reasons that some people get so passionate about it.
What do tech giants, winning start-ups, and the biggest corporate turnarounds in history share? Say hi to Scrum. In this post, we'll catch you up on the basics.
We don't make many book recommendations.
Partly, we don't read tons. Partly, we expect you're busy and picky like we are.
Having said that, just consider that this entire post is basically a book recommendation.
Entitled Scrum: The Art of Doing Twice the Work in Half the Time, it's written by Jeff and J.J. Sutherland (father and son, respectively). It's a quick read, it's got great case studies, and it does find ways to both illustrate the point and make it applicable.
Scrum is one of those easy-to-learn but hard-to-neatly-explain concepts. If we're boiling Scrum down to three quick pieces of advice, they are streamline, stand up, and check in. Let's talk just a little about each.
One big problem for lots of projects is that they're just... big. They're complicated, they have lots of parts and contingencies, and through no one's fault, it can be easy for any one person to get confused.
But even if that's no one's fault, complication costs time—and to big companies, lots of money.
Now, the solution is NOT to make a plan so detailed you need an atomic microscope to read it. As discussed in the book, that's the mistake many companies make—to the point that some people, their ENTIRE job is just keeping the flow charts and plans tidy.
Remember what happens to best-laid plans?
Now, you might be saying to us: but guys, we build software. (As one example.) This stuff can't be dumbed down and we need to plan it out.
Yes, of course, you should have the big picture handy. But it's asinine to believe you can work long periods in isolation without missing something. That's how you waste huge amounts of your own time.
Keep it simple. Plan 3 steps ahead, not 30. And remember that a working prototype is always better than a perfect concept.
One of the practices that helps Scrum work is the stand-up meeting — so named because you traditionally stand up on your turn to report. They're brief, usually no more than 15 minutes, and that's by design: a stand-up is supposed to be quick and simple so you can get back to what you're doing.
A few vital things happen at stand-up meetings. The first is that team members inform one another what's going on. Specifically, each member is supposed to share two things: (1) what they've done since the last meeting and (2) what they're going to do before the next one.
The second is that team members hold one another accountable, even if no one gets "called out" per se. Think about it: it can get real awkward if the only thing to share is that YOU didn't do what YOU said you would last week (and it's therefore still on your plate this week).
The third is that team members can help one another with problems. Scrum is NOT designed so teams can micromanage each other. Quite the opposite: it takes into account that being stuck is a waste of time — and that five heads are way better than one for solving most problems (or coming up with ideas).
There's one more foundation of Scrum that makes teams and meetings way more useful: they can make sure their work is actually working.
Part of the problem with big, long plans is that, if something takes a long time to build, there's more possibility that someone will be off doing work.
So if you're a manager and you only check in once per quarter, you might be disappointed at what your reports have done. But check in every week, much more briefly, and there aren't surprises for anyone.
One of Scrum's "rules" is that, each time you check in, you should have something working that wasn't before. Focusing on small units of usefulness—features here, modules there—can eventually add up to most of your product, assuming those little units are smartly conceived. Little things can be built fast and tested fast; big things can sometimes meander for months before they shit the bed anyway.
One last note: Scrum is not simply for internal use, for getting more done in the office. Some of Scrum is reflected in good customer service: staying in touch, getting feedback, and taking swift action are examples of the magic in action, especially when they're done all at once.
If you're in the market for a notebook, head on over to our store!
If you want more than one, check out our discounted notebook bundles!
If you just wanna say hi or look at pictures, come see us on Facebook or Instagram.