You’re Crazy… If You’re Not Using Scrum to Help Manage Remote Teams

For the past 20 years, I’ve been starting, growing and managing software development companies. Early on in my career, after dropping out of grad school and securing about $46 million in venture capital, I set out to recruit a world-class CTO. I was fortunate to land Jeff Sutherland, PhD, an experienced CTO who also happens to be the co-creator of the Scrum methodology.

Jeff Sutherland (circa 2000), inspecting my pilot logbook.
(He is a former fighter pilot.)

Jeff and I have been colleagues and friends pretty much ever since. We’ve had lots of conversations in the office, in the boardroom, on planes (and trains and automobiles) and in a few pubs, too. These conversations have been invaluable in shaping my worldview and setting the direction of Newfire Global Partners (where Jeff serves as a senior advisor).

So What Is Scrum, Anyway?

You can find plenty of articles about Scrum online, so no need to be redundant here. (If you’re interested, here’s a video as well as a book worth checking out.)

To be as succinct as possible:

1. Scrum is a low-ceremony software development methodology designed to empower teams with minimal administrative overhead, maximum transparency and elegant “checks and balances” that quickly identify problems (usually misunderstandings) and enforce participation of all team members.
2. A Scrum team features well-defined roles, including a Scrum master (part project manager and part referee), a product owner (the proxy for the voice of the customer or marketplace), developers and testers.
3. Scrum usually works in short, repeating cycles (often two weeks) known as sprints. Each sprint includes key ceremonies that help ask and answer specific questions, such as what are we building now? (backlog grooming); do we know how to build it, and how much time will it take? (estimation); did we build what was expected? (demo); how did we do in the last sprint, and how can we improve? (retrospective); and what were yesterday’s results, what are we working on today and what’s blocking us? (daily standups).
4. The end result of each sprint is production-ready code. The aggregated work represents the team’s velocity. Reporting and comparing velocities between sprints can motivate the team, communicate progress to stakeholders and highlight areas of improvement.

Jeff co-introduced Scrum in 2001 with the Scrum Manifesto. It has since become increasingly popular — even earning mention on HBO’s “Silicon Valley” (warning: NSFW). Most modern software development has adopted Scrum over other methodologies like “waterfall.”

Team-building event at Newfire Global Partners.

Given that most software projects fail, Scrum’s aforementioned features and many advantages have made it a welcome addition to the world of software development. In fact, some enthusiasts will tell you that Scrum can solve all of the world’s problems. I’m not quite there yet, but I might be someday!

Remote Teams and Scrum

With the insatiable demand for software and software development teams, companies are recruiting worldwide for the best talent. (As mentioned in a previous blog post, I have a long history of engaging teams across the world.)

Newfire Global Partners operations are based on aggressive Scrum.

With remote teams, Scrum has produced many success stories. Here’s a look at how aggressive Scrum (i.e. enforcing all the Scrum protocols — not just some of them) can serve as a potent prophylactic against common failure scenarios:

1. Team builds the wrong thing: Embedding the product owner (usually a product manager or business analyst) into key ceremonies and enforcing demos at each sprint help ensure the features are built correctly. With relatively short sprint cycles (i.e. two weeks), “drifting off course” is greatly minimized to about the length of the sprint, thereby avoiding big, unwanted and expensive surprises.
2. Team says they understand the specs, but they don’t: Requiring every developer and tester on the Scrum team to estimate the work effort of each user story (spec) is a great way to ensure the team’s understanding. Some teams assign story points using “estimation poker,” a practice in which individuals reveal their estimations simultaneously. This technique both enforces engagement and quickly identifies misunderstandings.
3. Team generates lots of activity but very little in terms of results: Velocity is measured as an aggregation of story points of completed specs during the sprint. Story points are only awarded for production-ready code, and no “partial credit” is given. This is the equivalent of only paying sales commission on closed business.
4. Team misses deadlines: The beauty of having meaningful velocities is that burndown charts can be created. If an estimation of the total work effort is known, then deadlines can be more accurately calculated. For example, if there are 100 story points of work and the Scrum team completes 20 story points during each two-week sprint, then we can estimate the project will be completed in five sprints (10 weeks). Deviations are quickly observable and correct measures (e.g. removing low-priority user stories) can be implemented.
5. Team is dragged down by unproductive members: A cornerstone of Scrum is transparency. Each developer’s individual velocities are known by the Scrum team. High performers can mentor weaker performers. Non-performers can be quickly identified and removed. This is the equivalent of the sales team’s leaderboard.

As you can see, Scrum has a lot to offer anyone managing a remote software development team. If that’s your responsibility and you’re following a methodology other than Scrum, I have one question for you: Why?