Use Sprints For Non-Tech Employees: Agile Methodology

use-sprints-for-non-tech-employees:-agile-methodology

As a startup leader, you’ve likely heard of “sprints” and “scrums” before, especially if you operate in the tech sector. Both are related to agile methodology, a project management process by which nimble, cross-functional teams complete tightly scoped projects. In agile development, rapid iteration and constant feedback are key.

Fortunately, the agile approach can be valuable outside of software development as well. By creating short sprints around specific business problems, you can manage non-tech employees in a similar way.  

For example, your marketing team could use agile methodology to design a new funnel for an untapped customer segment. Your business development team could plan a sprint around identifying which market to enter next. You could even use a sprint to choose a new CRM or plan your annual company outing. 

Sprints work so well because you can quickly incorporate feedback into whatever process you’re running. And when something doesn’t work, you can easily move on or pivot. As a startup, this type of flexible project management can help you respond to trends and organize limited resources around open-ended questions.

Below, we provide an example of how a startup might organize a week-long sprint. Of course, you could adapt this model to your unique needs, team dynamics, and business.

An Example Business Sprint 
For a week-long sprint to work well, the problem you are trying to solve should be small. Don’t bite off more than you can chew. Otherwise, your work will be difficult to assess and progress will be hard to appreciate.  
For example, only dig into one niche industry that you are considering entering or evaluate a single customer segment you are trying to win over. Anything more will feel overwhelming and impossible to dissect.

Monday
Orient your team to the new goal or objective. Encourage everyone to conduct research and familiarize themselves with the problem you’re trying to solve. Search for case studies or stories that highlight how other startups have approached a similar issue. Set clear boundaries and expectations around what you are hoping to accomplish by the end of the week.

Tuesday
On Tuesday, ideate around possible solutions. By now, your team has had time to think about what your startup could reasonably accomplish. Continuing with one of the examples above, if you’re trying to find a niche market to enter, have individuals present one idea each, choose a frontrunner, and go with it. Don’t try to evaluate several niches at once.

Wednesday
With your plan of attack set, build a draft prototype, presentation, or proposal. Invest an entire day in creating something sophisticated enough that you can reasonably study. If you are trying to build a business case around entering a niche market, gather the most important data points first to get an early sense of what the “right” answer is.

Thursday
Test your ideas, solutions, proposals, and prototypes with the team. Run through different scenarios, pressure test assumptions, and fill in apparent gaps with collective brainstorming. Acknowledge what information you are missing and what you would do if you had more time. 

Friday
At the end of the week, gather feedback from others in the company. Bring together a group of diverse teammates outside of the sprint who can provide a wide range of perspectives on your work. They can point out issues you may have overlooked or validate the potential of what you are pursuing. After Friday, you should know whether to start fresh the next week or press on with whatever hypothesis you want to test further.

Experiment with Sprints Today 
Before the end of the year, try a few week-long sprints to see if approaching other business problems in an agile way works for your startup. You have little to lose and a lot to gain by applying agile methodology to tackle ambiguous problems. 

You may discover that you and your team like working in such a manner where iteration and feedback are paramount. After all, your software developers shouldn’t have all of the fun ;)

Leave a Comment