How I Learned to Stop Worrying and Love the Scrum

There are few things I love more than a to-do list, which is a blessing and a curse.

To-do lists increase organization and efficiency, but they can also bog you down with so many details that you forget the “do” part. When I started using Scrum for project management on OpenView’s content marketing team, I thought the latter phenomenon might prevail. Thankfully, I was wrong, and have since become a Scrum convert. A “scrumvert” if you will. (If you think that’s bad, you should see my complete list of Scrum portmanteaus.)

The Deal with Scrum for Non-Developers

To be clear, Scrum is a lot more than a to-do list. It’s mainly an agile framework for developing complex products, most often those of the software variety. (Check out this Get Started with Scrum guide from Scrum Inc. for more info.)
At OpenView, we expand Scrum beyond software and use it as a framework to break large projects (like developing an eBook) into manageable pieces (called “Sprints”). Methods of tracking this work range from agile software like VersionOne, to good old-fashioned Post-its. While I can’t claim to be any sort of Scrum expert, I’m grateful for how it’s helped our team manage projects and workload.
As the content marketing team’s Certified Scrum Master (definitely one of the more colorful qualifications on my resume), I’ve lived and breathed Scrum every day at OpenView. I’ll take the lessons I’ve learned into any future opportunities — it’s made me a better project manager and a better employee. Kevin Cain, OpenView’s Director of Content Strategy, has also written about how Scrum can help non-software teams manage their work, so this is my attempt at adding my two cents.

5 Ways Scrum Can Help Any Team (Not Just Developers)

Among the many Scrum lessons that stand out in my mind, there are a few particular ones I’d like to highlight here that I think will appeal to the non-software focused professionals among us. They are presented in no particular order, and they are takeaways that will benefit any team looking to grow in efficiency and effectiveness.

1) Understand How Tasks Fit into the Bigger Picture

As I mentioned above, Scrum allows you to break down complex projects into manageable tasks. It forces you to think about the specific actions needed to reach a goal, and it encourages reviewing and revising those actions with your team. The ultimate goal is always in mind, but the steps necessary to achieve it are the main focus.

2) Know What Your Team is Working On

Scrum encourages transparency, but not micromanagement. Your team needs to know what you’re doing and when they can expect it to be done, but it is up to you to complete your work how you want. There is no real “boss” on a Scrum team, although Product Owners are ultimately held accountable for a finished product. Scrum encourages autonomy within a team structure.

3) Build in Deliverables

This is another way of saying “hold yourself accountable to deadlines and specifics.” It’s not particularly helpful to say, “I will publish an eBook by August 15th.” That’s a good goal, but what specific tasks do you need to complete, and when do you need to complete them? During each Sprint, your items will read more like, “I will complete a draft of my eBook and review it with Kevin by August 1st.” Kevin knows when to expect it, and you know when it needs to be done.

4) Stay Organized

Effective project management requires organization, and that requires open communication and tracking. For me, this is really at the heart of Scrum (and effective project management in general). You are laying out a logical roadmap for getting things done. Whether you use Scrum or any other framework, staying on top of tasks is the key to success.

5) Stay Flexible but Focused

Scrum sometimes seems like it has a lot of “rules,” but remember: it is an agile framework. It is designed to deliver products not just better, but faster. This means you have to leave room in your Sprints for the unexpected, but you also have to be able to prioritize your work and say “no” to low-impact requests that come up. Having a Scrum Master (or equivalent team member) looking out for impediments and figuring out how best to handle them is important to reach team goals.
 

Do you have any additional insight about using Scrum in a non-software capacity at work? Do you have any awesome Scrum portmanteaus to share? Make my day and leave a comment.