Practicing Agile with non-tech teams of a startup — is it worth it?
WHAT IS AGILE?
It’s 1986. The retrofuturistic 80s are in their full glory. The USA and the Soviet Union are caught up in the space race, teens falling in love with Marty McFly and Doc’s Delorean, Chernobyl 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 is today.
But there was another important thing, which at that time went unnoticed. Something that has changed the way 90% of the tech teams manage their workflows, and become more productive. The almighty SCRUM was born.
First introduced by Hirotaka Takeuchi and Inkujiro Nonaka 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 from strongly recommending it for starting off.
But do agile methodologies work only for the developers? Or can you make the most out of these management techniques for your non-tech teams as well?
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 the sake of anyone who still hasn’t jumped on board of the magial train.
GETTING STARTED WITH SCRUM
Both at my previous projects and StartupSoft we deal with developers all the time. So, naturally, trying to find the best ways to manage the workflows and improve the customer experience, I’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, 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.
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 past week and prepare for the weekly planning.
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 comparing 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.
I kept mine in a basic Google sheet for the first few weeks until I felt comfortable saying that we’ve optimized the workflow to the point I couldn’t do any more tasks done in a sprint. And I suggest you do the same. Here’s how my table looked:
As I’ve mentioned before, it’s best to plan 30% more tasks than you actually did 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 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 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.
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 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 future. You don’t have to filter or prioritize the cards that go on this list. Backlog should be revised before every sprint planning, and we can grab any task we feel belongs on your to-do list for this sprint.
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 get rid of any unexpected tasks that are to be avoided in agile.
In progress — the In Progress list can’t include more than 2 tasks per person at the same time. This is done 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 for all the tasks that have been done on the maker’s side but are awaiting any sort of reaction or approve from someone else.
Release — all the tasks completed during the current sprint. We separate them from the rest of the tasks because it makes easier to go through the retrospectives and to count the story points.
Done — all the tasks that have been 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:
- What tasks you’ve completed yesterday
- What you’re going to work on today
- 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.
What we’ve discovered through experimenting, is that while most of the tech teams prefer Atlassian’s Jira for agile task management, it turned out to be too complicated for our small non-tech team and 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 label
Labels make it easier to navigate and prioritize the tasks, especially if your kanban is a team board.
Assign the executer
You need to know who’s responsible for the project. Also helps to distinguish the personal workloads.
Describe task
If you are assigning the tasks for anyone else, add the task description that clearly states what needs to be done. Attach any files or links your team-mate might need to complete the task.
Ask for review
Any time you’re done with the task, but still need someone to review it or do anything else with it, before you can complete it, ask them for a review in a comment to the task. Tag them in a comment, add a specific call to action, and provide with all needed materials.
CONCLUSION
Implementing the elements of Agile, Scrum and Kanban is a great first step for every team out there, no matter what they are working on.
These techniques help to visualize the workflow, keep better track on personal and team efficiency, provide feedback when it's needed and change faulty processes that slow you down. If you need a system that is 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 advise is to research the basics, experiment and come up with the framework that suits your specific needs, instead of stressing out in attempts to follow the guidelines that are not applicable.
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +418,678 people.
Subscribe to receive our top stories here.
