Since 2001 when Agile values and principles were formalized in the Agile Manifesto, Agile has become the standard process for software development. Studies show that about a third of all software projects use some form of Agile methodology.
Though Agile was created with software in mind, non-tech teams have begun adopting Agile. A notable example is NPR has used Agile to reduce programming costs by up to 66%. Like the folks at NPR, many non-tech teams have found that employing an Agile mindset and using Agile practices can help their team or business get more done, make their customers happier, and make their teams more collaborative.
SEE: Tech Pro Research’s Project Management Resource Kit
What is Agile?
Before describing how non-tech teams have used Agile practices successfully in their teams and businesses, let’s review what Agile is exactly.
The Agile Manifesto came from a group of developers wanting to write software better, and the Agile movement has been generally taken over as a project management approach. Scrum, Kanban, and XP are the most widely-used software development frameworks under the Agile umbrella. And, each of these frameworks stem from the values spelled out in the Agile Manifesto:
- Individuals and interactions over processes and tools
- (Or: Getting people to self-organize and talk to each other about what they’re working on. No one likes to be micromanaged!)
- Working software over comprehensive documentation
- (Or: Getting stuff done is better than talking or writing about getting stuff done. When you get something done and show it to people, you can see what’s working and what’s not.)
- Customer collaboration over contract negotiation
- (Or: Stay in touch with your customers. Give them what they want and need, or you may run out of contracts to sign.)
- Responding to change over following a plan
- (Or: Things change. Let’s be flexible!)
There are many Agile practices — all of which are subservient to the larger effort of operating within Agile values. But, some key practices most of the frameworks share include:
- Creating a list (or backlog) of prioritized work
- Writing tickets that describe all the units of work necessary to accomplish the items in the backlog
- Displaying public boards so the team — and stakeholders — can track progress
- Planning out the work to be done in a sprint, or a set period of time (usually 2-4 weeks)
- Holding daily 5-10 minute standup meetings where the team checks in on progress and discusses challenges
- Doing retrospective meetings when the sprint is over to discuss what went well, what went wrong, and what could be improved
Many software teams follow an Agile framework closely, meticulously employing each Agile practice, including the ones above. This helps these teams satisfy the needs of their customers, respond to changing requirements, and maximize their output.
SEE: Agile development: Cheat Sheet
Agile success stories from non-tech teams
Let’s see how three non-tech teams or businesses employed some of these Agile practices effectively.
How creating a prioritized backlog helped a non-tech team create synergy and communicate with stakeholders
Marney Andes is Sr. Director of Learning and Development for Air Methods, an emergency air transport company. The company has about 4,500 employees and 2,000 outside medical crew. Andes and her team are tasked with creating or managing the strategy for creating training and education for the organization.
Andes says when she first came to Air Methods, stakeholders (and even her own team) didn’t have an understanding of how long it would take to create all of the trainings or projects needed.
So, Andes and her team started using the Agile practice of keeping a prioritized backlog in a public Trello board. The board lists training requests, trainings currently being built, and more. When stakeholders’ requests are added to the board, Andes and her team give the request a green or red code; green means they can currently take the project on, and red means it goes into the backlog.
Every month, the group of stakeholders meets to prioritize the backlog by, “voting democratically on what gets pushed to the top.”
Andes says using the Agile practice of the prioritized backlog helps “communicate expectations to the business about why and how we are doing things the way we are.” She also says this practice has created synergy within the group. “They get to see what the other groups are doing. They also aren’t doing each other’s work since they can see that something was already created … it reduces waste.”
How a traditional publisher iteratively developed products with customer feedback
Before I became a software product manager, I worked at a traditional publisher as an editor for a print curriculum product. Our editorial product team applied facets of the Agile practice of continuous development to create and improve our product before and after launch.
Every week we developed one week’s worth of lessons. Once we had a finished draft, we sent it to a group of alpha testers who used the product with real kids and gave feedback on what worked, and what didn’t. We incorporated that feedback and then sent it out to a group of beta testers, who did the same.
Even in this traditional print publishing environment, we were able to get a bare-bones version of the product into the hands of users as soon as possible, so we could start gathering feedback on how we could improve it. This helped us identify flaws, and fix them before publication.
How a recruiting team used a Kanban board to be more efficient
While working at email data solutions provider Return Path, William Kammersell (former Agile coach and now Sr. Product Manager at CA Technologies) hosted an AgileCamp to spread Agile through non-tech teams. He recounted how the recruiting team used Agile practices to streamline the way they handled candidate phone screens.
“A recruiting team can’t predict candidate outcomes,” says Kammersell. “Recruiting can have a pretty standard process flow from start to finish. However, there are factors on a daily basis that can rapidly change the flow.” Because of the irregular nature of recruiting, the team needed to be flexible and efficient, while also maintaining transparency among their team and stakeholders. If they weren’t, a recruiter might get bogged down in the workflow, causing candidates to drop out, managers to become impatient, or the cost-to-hire to rise significantly.
So, Kammersell worked with the team to use the Kanban board practice of the Kanban Agile framework. The team displayed the work they had on their plate on a public, physical board for the team and other stakeholders to see.
Kammersell says displaying a Kanban board helped team members understand when another team member was overloaded. “Traditionally, people don’t really share what they’re working on and people might not know how they can help each other,” says Kammersell. “Things take longer that way.”
Start using Agile practices with your team or business
As Martin Rowe from Petroc College in Cornwall says, “Even badly implemented [Agile] works. Applying just a little bit of Agile can help.”
But, before teams take the step to apply Agile, they need to ask why they want to use it. What problems do your non-tech teams or businesses have that an Agile mindset and practices might help solve?
Maybe your team members struggle with duplicating each other’s efforts. Try keeping a daily standup: a 5-10 minute meeting in which everyone shares what he or she did since yesterday, is planning to do today, and finds is blocking his or her progress. Tip: have everyone actually stand during the meeting to keep it short!
Maybe the members of your team don’t feel trusted or empowered to do what needs to be done to meet goals. Try creating a backlog of work to be completed during a sprint (try 2-4 weeks), and allowing the team to come up with the plan for accomplishing the work.
Maybe your business can’t seem to understand how to give the customer the product he wants. Try delivering the smallest, most valuable thing as soon as possible to a small group of customers. Get feedback on it, improve the product, then repeat.
Still not sure where to start? Kammersell recommends trying Agile as an experiment. His suggestion is to try it out for three sprints with retros in-between that allow the team to iterate on their process. If at the end of three sprints the experiment is a failure, the team or businesses will have likely found at least one part of the Agile mindset and practices that makes them a more successful team.
Use Agile to start using Agile? Now, that’s one way to do it!
