Agile for non-tech teams: 8 things you need to know

What is Agile?

It’s 1986. The retro-futuristic 80s are in their full glory. The USA and the Soviet Union are racing in space, teens falling in love with Marty McFly and Doc’s Delorean, Chornobyl explodes into a catastrophic nuclear disaster, and Oprah first airs nationwide. All of these events had a dramatic influence on the way we and our culture are today.

But there was another important event, which at that time went unnoticed. Something that has changed the way 90% of the tech teams manages their workflows and become more productive. The almighty SCRUM was born.

Hirotaka Takeuchi and Inkujiro Nonaka introduced it in their HBR article The New New Product Development Game. Scrum was later heavily embraced and influenced by Jeff Sutherland, who’s probably done the most to popularize and educate the crowd about Agile methodologies. 

Jeff’s book SCRUM: The Art of Doing Twice the Work in Half the Time became the handbook for anyone who’s trying to get their team into the agile routine. And we can’t resist strongly recommending it for starting off. Regardless of whether you need SCRUM for non-IT projects, for tech teams, or whatsoever, the book will come in handy for sure. 

But do Agile methodologies work only for developers? Or are there any non-IT applications for SCRUM? Can you make the most out of these management techniques for your non-tech teams?

I won’t hold the intrigue: Agile is golden for managing marketing, operations, and sales teams. We’ve proved it through our own experience and decided to write about it for anyone who still hasn’t jumped on board the magical train.

Starting with Scrum

At Lemon.io we deal with developers all the time. We’re a marketplace for hiring vetted developers, after all! So, naturally, trying to find the best ways to manage the workflows and improve the customer experience, we’ve learned about Agile.

At first, we started following the framework for everything connected to development and managing freelancers’ projects. Not too long after that, we saw the benefits we couldn’t ignore.

And being a startup, we just couldn’t afford not trying to get the same results for the rest of our team.

Getting into any new routine is quite difficult. Especially, when you need to learn a lot of things you’ve never heard before. With Scrum, it can get extra complicated and confusing since you’ll have to decide which exactly things you should care about and which are irrelevant to your marketing team.

Having made our mistakes in SCRUM management for the non-IT team, we decided to share our list of 8 things you need to know about Agile for starting a marketing Scrum team. These are the 8 things that worked for us the best, the only ones we’ve decided to keep doing. We’ve tried doing some more advanced techniques, but it turned out that they only make the framework more perplexing, and there are no additional advantages to those.

Think of it as your mini “SCRUM for non-technical teams” training course. 

8 steps to a non-tech Scrum team

1. Sprints

Sprints are the short iterations for working on a list of tasks, which last the same specific amount of time.

In our case, every sprint lasts a week. For the majority of non-tech teams week is the best period to settle with for sprints, though some people prefer longer periods up to a month. We felt like sticking to 1-week sprints because we felt they help be the most productive. But feel free to experiment and choose what’s right for you.

Another tip is to start sprints on Tuesday. That way, you still have the entire most stressful day of the week, aka Monday, to round up all the stuff you’ve been working on last week and prepare for the weekly planning.

Looking for remote senior-level tech talent?
Get access to hundreds of experienced devs today and go from zero to hire within 10-14 days!

2. Sprint planning

When planning the next sprint, always remember to include only those tasks that can be completed within a week, or whatever long your sprint is.

If you need to work on some bigger project that requires more time, divide it into smaller bits.

Always include more tasks than you feel you can physically get done. This strategy will not only help you get more productive but also will set your planning game on point.

The best practice is to plan 30% more tasks than you’ve managed to close last week. For keeping track on how much we’ve done in a sprint, we use story points.

3. Story points

Story points are used for task estimation. It’s an intuitive way to rate any task based on how difficult and time-consuming it is.

There are many different techniques used in Agile teams for estimation, but the one we decided to stick to is the story point system that replicates the Fibonacci sequence:

1 2 3 5 8 13 21 34 55 89

This sequence is usually used instead of linear 1 to 10 because it makes estimations easier for the human brain.

Some tasks will be harder to estimate correctly from the first time, and you’ll find yourself adjusting your initial guesses. That’s alright! Because, after all, most people’s tasks are usually repeating, so gradually you will set them up with some standard story points. Like, in my case, I’ve settled with 89 points for any long read I do and 8 points for any Quora answer I write.

One thing we never do inside our team is compare story points between employees or whole departments. The important thing to understand is that Scrum and Agile methodologies are not used for choosing winners in any weird productivity races, and the only person you should be competing with on this matter is yourself.

The main point of Scrum is to reach your full productivity potential. And as long as you feel there is still room to grow, I strongly recommend you to keep score of your story points.

We kept ours in a basic Google sheet for the first few weeks until we felt comfortable saying that we’ve optimized the workflow to the point we couldn’t do any more tasks done in a sprint. And we suggest you do the same. Here’s what the table looked like:

As we’ve mentioned before, it’s best to plan 30% more tasks than you actually did in the previous sprint.

And here’s how to tell how good is your planning:

<70% – either over-planned or unproductive week

70-100% – just perfect!

100% – almost always a sign of bad planning

4. Acceptance criteria

Story points can be assigned only for the 100% closed tasks.

But how do you know the task is completed? One thing when you get a task to write the text for a new email template, and it’s self-explanatory: the acceptance criterium is «written text».

But what if you take a project like creating a new landing page? Is it done when you are all set with copy and design or do you need to make sure it’s released and ready to go for your next marketing campaign? That’s when acceptance criteria come into play!

5. Retrospective

Sprints retrospective, in our case, basically, means a weekly meeting held between the marketing team and founders where we discuss what has been done during the last sprint.

If we feel we could have done better, we try to figure out what exactly happened that didn’t allow us to show the full glory, and how to fix it.

The main point of such meeting is to distinguish what blocked our progress and eliminate that factor. Once we do that, it’s important to see if the result of such elimination turned out to be what we expected it to be or not.

The best time to go through the retrospective is right before planning, since the discussion may actually affect the planning itself.

6. Kanban

Kanban board protects your team from nervous breakdowns and overloads.

It’s a tool that allows you to visualize your team’s workflow and set up the safety switches. Here’s how the classical minimum-requirements-kanban-board looks like:

But we found them to be not so convenient, so we’ve customized the columns according to the workflow we have:

Backlog — the place for all the ideas and things you’d like to work on in the future. You don’t have to filter or prioritize the cards that go on this list. We revised the backlog before every sprint and grabbed any task that belongs on the to-do list.

Chosen to work on — everything you want to work on during the sprint belongs here. A great tip is to check up with any teams that might need help from you. That will allow you to sieve off any unexpected tasks.

In progress — the In Progress list can’t include more than 2 tasks per person at the same time. This is to make sure your coworkers can focus on only one thing without jumping from task to task. This is the safety switch that ensures the maker’s schedule.

Review — the list of all the tasks on the maker’s side awaiting any reaction or approval.

Release — all the tasks completed during the current sprint. We separate them from the rest of the tasks because it makes it easier to go through the retrospectives and to count the story points.

Done — all the tasks 100% done in any past sprint.

7. Daily standups

Daily standups are the opportunity to sync with the whole team. Since we have a distributed team, we started off with daily Hangouts video calls. But we quickly noticed, that those were taking too much time and required some team members to go out of their routines ruining the whole idea of the flexible schedule we have.

So, we switched to writing the daily updates in a dedicated Slack channel.

There are three crucial things everyone has to post every day:

1. What tasks you’ve completed yesterday
2. What you’re going to work on today
3. What obstacles you have that get in your way on completing any of the tasks and how the team can help you with those

8. Management tools

There are tons of management tools that support Scrum, Kanban, and all the rest of your agile team’s needs. We’ve already covered some of them in our earlier article on How to Manage Remote Teams.

After some experiments, we understood that while most of the tech teams prefer Atlassian’s Jira for Agile task management, it is too difficult for our small non-tech team. We preferred the free version of Trello along with the Agile tools extension.

But no matter which management tool you decide to stick with, here are a few tips that will make your team collaboration most effective:

Clear task naming

Try to choose short, but self-explanatory task names.

Choose labels

Labels make it easier to navigate and prioritize the tasks, especially if your kanban is a team board.

Assign the executor

You need to know who’s responsible for the project. It also helps to distinguish the personal workloads.

Describe task

If you are assigning tasks, add a clear description. Attach any files or links your teammate might need to complete the task.

Ask for review

Any time you finish the task, ask them for a review in a comment. Tag them in a comment, add a specific call to action, and provide them with all the needed materials.

Conclusion

Implementing the elements of Agile, Scrum, and Kanban for marketing teams is a great first step.

These techniques help visualize the workflow, keep better track of personal and team efficiency, provide feedback when needed and change faulty processes that slow you down. If you need a system designed to help your business grow fast, give it a go.

From a perspective of a non-tech team that has implemented elements of Agile team management into our daily routine, our biggest advice is to research the basics, experiment, and come up with the framework that suits your specific needs. Don’t stress out in attempts to follow the guidelines that are not applicable.

Too little info? Our FAQ brings more!

• What is Agile for non-IT?

  Agile is a project management methodology used to plan, develop, and deliver products flexibly and iteratively. It is based on the idea of continuously improving and adapting the product based on feedback from stakeholders. Agile is commonly used in software development, but it can also be applied to other fields, such as marketing, product development, and project management.
  In an Agile environment, teams work in short “sprints” to deliver incremental improvements to the product. This allows teams to be responsive to changing needs and priorities and to deliver a product that meets the needs of the end users.
  The Agile methodology emphasizes flexibility, collaboration, and rapid iteration and is designed to be adaptable to the project’s specific needs. It is often used to manage projects that are complex or have uncertain requirements, as it allows teams to be agile and responsive to change.
  

• Is Agile only for technology?

  Agile is a project management methodology commonly used in the technology industry, particularly in software development. However, Agile principles can be applied to various fields and industries and are not limited to technology alone. Agile can be used to manage marketing, product development, and project management projects, among others.
  The Agile methodology emphasizes flexibility, collaboration, and rapid iteration and is designed to be adaptable to the project’s specific needs. It is often used to manage projects that are complex or have uncertain requirements, as it allows teams to be agile and responsive to change.
  By adopting an Agile approach, teams can deliver high-quality products flexibly and iteratively and can be responsive to changing needs and priorities.
  

• What is the difference between Agile and Scrum?

  Agile is a project management methodology that emphasizes flexibility, collaboration, and rapid iteration. It is based on the idea of continuously improving and adapting the product based on feedback from stakeholders.
  Scrum is a framework that is based on Agile principles and is specifically designed for managing software development projects. It is a lightweight framework that is focused on delivering working software in short “sprints” and is characterized by its use of specific roles, artifacts, and events.
  

• Where do I start with Agile?

  If you are new to Agile and want to start using it to manage your projects, here are some steps you can take to get started:
  Learn the Agile principles: Agile is based on a set of core principles, such as delivering working software frequently, welcoming change, and working collaboratively. Familiarize yourself with these principles and understand how they can be applied to your projects.
  Choose an Agile framework: There are several different Agile frameworks that you can choose from, such as Scrum, Lean, and Kanban. Consider which framework is the best fit for your team and your project.
  Establish a cross-functional team: In an Agile environment, it is important to have a cross-functional team that is responsible for delivering the product. Make sure to include team members with diverse skills and expertise to ensure that all aspects of the project are covered.
  Define your product vision: Clearly define the goals and vision for your product, and make sure that all team members are aligned on what you are trying to achieve.
  Create an Agile roadmap: Develop an Agile roadmap that outlines the high-level steps that you will take to deliver your product. This can help you plan and prioritize your work in an Agile manner.

• Which Agile certification is most recognized?

  Several Agile certifications are recognized in the industry, and the most appropriate certification for you will depend on your specific goals and needs. Some of the most widely recognized Agile certifications include:
  Certified ScrumMaster (CSM): The Scrum Alliance offers this certification for individuals who manage software development projects using the Scrum framework.
  Certified Scrum Product Owner (CSPO): The Scrum Alliance offers this certification for individuals who are responsible for defining the goals and priorities of a software development project using the Scrum framework.
  PMI-Agile Certified Practitioner (PMI-ACP): The Scrum Alliance offers this certification for individuals who manage projects using Agile methodologies.
  Certified Agile Leader (CAL): Agile Leadership Network offers this certification for individuals who are responsible for leading Agile transformations within their organizations.
  Certified Agile Coach (CAC): Agile Coaching Institute’s certification for individuals responsible for coaching and mentoring teams in Agile practices.