A Non-Technical Guide To Adopting Agile Methodology for Your Non-Software Team

It often surprises me that, sometimes, tweaking "how" certain things are done, can totally revolutionize "why" they're being done. Methodology, in itself, seeks to re-imagine the meaning.

I have seen so many passion-driven people constantly hit dead ends, whereas, method-driven people kept on finding the way forward while trying to achieve similar objectives. I firmly believe that the Agile methodology (introduced in the early 2000s) is one such example that helps software teams stay highly productive. 

Being from the software industry, when I first heard that Agile for non-software teams is an equal hit, I was like, "Yeah, why not?" Apparently, 77% of respondents in a KPMG survey have reported using Agile project management outside IT functions. Additionally, 59% of respondents found Agile use cases for their marketing and sales processes. 

Agile does have the ingredients that teams need to manage resources wisely, and it shouldn't matter what kind of team uses it. Don't be surprised by the fact that San Jose's public workers adopted Agile to improve their productivity and efficiency, your industry can also do the same. For building software, we use several project methodologies, and team management software to keep things on track. 

While a non-technical team is free to use the same, here are some non-technical ways to adapt to the technicalities of the Agile methodology for non-technical (software) teams around the world. 

What Is Agile for Non-Software Teams?

Agile, which was originally developed for software teams, is a methodology that strives to prioritize team collaboration over siloes, dynamic changes over strict planning, and active stakeholder participation in the project.

You can read the actual Agile Manifesto here. 

For non-technical teams, Agile methodology's core tenets can be reiterated as follows: 

• All of the team members comprehensively talk about the tasks at hand, sharing ideas with each other. It's not like each person only does their fixed things. 
• More focus is put on kicking into action, to execute the actual work, rather than spending good, sweet time on elaborate planning. 
• Keep the key stakeholders (mostly the clients) actively involved in the process to take constant feedback on the progress being made. 
• Make space exists for changes, modifications, and second thoughts to be integrated into the development, rather than strictly sticking to the word. 
• Work is done in manageable iterations of time with defined task priorities. The team doesn't take on all the tasks at once. 

You are free to adopt these ideas into your workflow as you deem fit. As we are not focussing on writing code, these ideas will vary in implementation while maintaining their essence.

Remember that Agile is an ideology and not a list of instructions. It can be best practiced by absorbing the ideas, instead of creating a user manual. 

What Are the Benefits of Agile for Non-Software Teams?

The Agile way of working is designed to overcome certain project management challenges native to software teams. But if we carefully pick these concepts, they have far-reaching benefits for pretty much any team that plans on adopting them.

Following are a few (of the many) benefits that Agile offers for non-software teams.

Feedback Management

Almost all kinds of teams require constant feedback from an internal authority (Manager/QA) or an external consumer (client/customer) to keep the work aligned with the desired standards or expectations. If the feedback isn't absorbed properly or is not handed out consistently, the output can become irregular. My friends from the corporate will refer to this as "inadequate quality". 

In an Agile process, the work is divided into phases which typically last 1-3 weeks. At the end of each phase, the work is reviewed by key stakeholders so that any issues or considerations can be raised well in time. 

Therefore, by following the Agile methodology, teams can build a feedback-centric culture to keep the results as per expectations. 

Faster Progress

Agile teams often deliver projects faster, because the team members actively learn how to prioritize work and cut down on wastage of time. The Agile approach requires the team members to communicate daily, and consistently review the progress being made. This way, any significant changes that need to be made are caught early and worked on as a part of the process. 

As the issues are promptly fixed, the long back-and-forth revision loop is greatly avoided. Projects don't lag behind, and the delivery speed is positively impacted.  

Manage Uncertainties 

The real deal in any project is not to execute the plan but manage the unforeseeable. Any experienced project manager would agree to the statement that "No matter what you do, uncertain situations will arise." Murphy's Law is a classic example of the fact that "project issues are inevitable," no matter how well you plan, something will go wrong because it can go wrong.

The Agile approach is designed to meet uncertainties effectively, as it's not built upon strict schedules. The team members have the flexibility to pivot the flow of the project and accommodate changes wherever needed.  

Definite Workflows 

Most Agile frameworks (more on this in a minute), come with workflows that are designed to keep the project's progress highly organized. Mind you that these workflows are not intended to micromanage, but rather, create reference points for the entire team.

The most common example of this is the Kanban framework, which comes with stages such as "To-do", "In-Progress" and "Done" stages. Many Saas Applications offer Kanban-based workflows.

This is done to lend a systematic task lifecycle to the project as each task jumps from one stage to another. The presence of workflows ensures that the project's flexibility can be compensated with safety rails.  

Client Integration  

Agile methodology stresses involving the client in every phase of the project, rather than raising the curtain to them 6 months later. Client integration resolves major challenges before they take scary forms. Teams who work in the servicing industry well know what happens when the client rejects something after a great amount of time has already been put in it. 

When the client is actively involved in weekly meetings, project updates and clearly understands where the project is headed, the chances of success only become better.

Is Agile For You?

Yes, let's take a moment to recognize the kind of projects wherein Agile might just not work. 

When The Requirements Are Clear

If the client or the project has well-defined expectations, and there are minimum uncertainties, the project can be approached pretty much conventionally.

As you'll not need a lot of client feedback, and team members have to follow a linear path, Agile methodology's core tenets won't be of many benefits. 

Most software projects are exploratory in nature. Everyone, including the client, figures out what they want as the project slowly takes shape. If the project's outcome and direction are already known, Agile won't be of much help.   

When The Team Is Non-Collaborative

Collaboration is the key to running any Agile project. If you happen to have a team that is averse to collaboration, Agile might end up backfiring for you.

Obviously, there are ways to improve intra-team communication such as team communication tools, and group activities, but it's easier said than done. If you feel team communication is a challenge not worth solving, you can do well without Agile.

When Innovation Can Be Spared

Expect no aphorism but not all projects need innovation. Agile is developed to let innovation find an easy fit into your way of working. If the project is a straightforward list of tasks that you can mark done and move forward, you probably don't need Agile.

A quick example of this would be robotic processes such as Data Entry, Customer Support, or Clerical Work that don't require out-of-the-box thinking.

Agile for Non-Software Teams

Now that we know the benefits and considerations of using Agile, let's talk about how non-software teams can incorporate Agile in their work. Here, I'd like to draw attention to Scrum: an Agile framework that lays down a set of rules for getting the best out of Agile.

Again, we'll just talk about the conceptual ways of using Scrum without getting too deep into the mechanics.

What Is Scrum?

Scrum is the implementation-ready version of Agile wherein we talk of scientific terms, work protocols, and defined team roles. It can be non-technically summarized in the following points.

• The client or a company-owned analyst comes up with a business requirement. This could be a material product or a process that needs to be fulfilled.  
• The team understands the requirements and starts self-orchestrating the work for a set time interval, usually 1-3 weeks, wherein they'll achieve a small part of the requirement. 
• At the end of this time interval (let's say the 3rd weekend), the team sits down with the client or the analyst to show them what they achieved and determine if it is satisfactory. 
• If the work is up to the mark, the tasks next in line are planned. If the work requires pivoting, the team works to incorporate the changes and plans tasks accordingly for the next 1-3 weeks. 

 Key Takeaways 

• Split up the work into short segments. 
• Work on each segment for a fixed time.
• Review the progress made in each segment.
• Involve the key stakeholders (clients or the analysts in the review).
• Focus on "What works the best?" and "Is this what we had envisioned?"
• Pivot wherever necessary.

Scrum Team Structure

Scrum has a defined team structure in order to orchestrate the work smoothly. It helps you assign roles and responsibilities, without using the exact labels. 

Product Owner

• Role: The client or the analyst who orders what is to be achieved
• Responsibility: To find out a problem that needs solving, and carefully understand what kind of solution is needed; the Product Owner lays down the expectations and also validates if the progress is headed in the right direction

Scrum Master

• Role: The key person who overlooks the Scrum flow  
• Responsibility: The Scrum Master acts as a link between the Product Owner and the Team. They manage communication, ensure collaboration and make sure Scrum is followed productively. 

Team

• Role: The executioners who carry out the tasks
• Responsibility: The Team is responsible for absorbing requirements and self-manage the executables. They assign tasks amongst themselves and collaborate to stay productive.

Industry Examples of Agile for Non-Software Teams

Lonely Planet

Lonely Planet is a 49-year-old travel industry company that publishes books on travel and has a mobile app with 10+ million downloads. 

Challenges at Hand

• The legal team of Lonely Planet was facing issues in managing day-to-day requirements. 
• There were a lot of legal documentation revisions and work priorities were not set.
• The team members felt stressed out and dissatisfied.

How They Turned Agile

• The team adopted Kanban-style boards to lend a structure to the tasks based on "to-do" or "pending." 
• The team used a Scrum-like framework to manage feedback for revisions and easily managed who will be doing what.
• Without a Scrum Master, the team self-organized the members, prioritized tasks, and made sure the workload didn't become overwhelming.     

Results 

Lonely Planet's legal team was able to increase productivity by 25% and decrease the overall chaos that existed in the work environment.  

The National Art Museum of the Netherlands

One of the oldest Museums in the Netherlands, the NAM was constructed in 1885 and holds exquisite pieces of Dutch art and history. 

Challenges at Hand

• The museum needed to organize its artifacts based on the time in history they belonged to.
• Due to the huge collection of artifacts and expertise required to organize artifacts, the task became hefty.   

How They Turned Agile

• The teams working at the museum organized themselves into self-operational groups and classified the artifacts as they appeared throughout history.
• They established strong communication amongst the several groups that worked on the task and actively collaborated to achieve the goal.
• The approach was non-linear as the team changed their team structures, approach, and speed on the go. 

Results 

The team was able to complete the task with great quality and adopted this Agile process to continuously change museum displays as the museum traffic grew.  

NPR

NPR, or National Public Radio, is a 50-year-old radio broadcaster with over 1,000 syndicated radio stations across America. The shows "Morning Edition" and "It's Been A Minute With Sam Sanders" are two of their popular productions. 

Challenges at Hand

• NPR pitches ideas to executives who make radio shows, but it was hard for them to come up with a formula for seemingly successful shows.
• The ideation process for NPR shows was risky, costly, and often required several changes. 

How They Turned Agile 

• NPR adopted the Agile way of propagating pitch ideas by creating small iterative "pilot shows" that they tested with a local team, regional program directors, and listeners on social media.
• These pilot shows were not expensive and easy to distribute in comparison to full-blown shows that came with uncertainty.
• They used the feedback from various sources to actively understand what the audience liked the most, as the basis for their full-production shows.   

Results 

The team used the Agile way of managing the programming of shows, in order to lessen the uncertainty and incorporate feedback from several avenues, leading to a cost-effective, rapid, high-quality production.

Conclusion 

If project uncertainty, incomplete requirements, and muddled vision are some of the characteristics of your project, you should try giving Agile principles a shot.

It has a proven track record of making software teams achieve more, and has great potential for other teams too. This article is an attempt at understanding Agile and while you may not fully grasp the picture, you can use this article as a starting point.

After all, it all comes down to the "how" of being and staying productive, which takes the most time to master.