BLOG POST

Can I Use Agile Outside of IT

Road sign erading, opportunity ahead

When an organization first adopts Agile, they often begin in IT or software development, as the framework was first created with software development in mind. However, it’s not uncommon for marketing, HR, and other departments to see the success of Agile and want to adopt it themselves. Can this work? Can a framework designed for software development be used elsewhere?  

As it turns out, the answer is yes. This is because the core focus of Agile can be applied to every single department, as can many Agile practices and tools, and the two key leadership roles within Agile. 

Why Would We Even Try This? 

If Agile was first created by software developers for software developers, what’s the point of ever trying to use it outside of that context? 

First, it’s important to understand that the core focus of Agile is maintaining a sustainable cadence, or rate which work is being done, and creating value for the customer early and consistently. This focus is one that any team could benefit from. Every department is prone to developing an unsustainable cadence, where workload can rapidly fluctuate between too light and too heavy at the drop of a hat. Every department can also be prone to not creating any tangible value until the very end of a project. 

Secondly, once you understand that Agile teams frequently include businesspeople and people with other areas of expertise, it becomes easy to see how Agile could be adapted to a non-IT context. An Agile team is meant to have every skillset that the team would need to accomplish their goals. With this knowledge it is easy enough to see how an Agile team with a diverse set of skills could accomplish non-IT related tasks on a regular basis. 

These two observations have led many departments, to adopt some form of Agile. Marketing and HR departments in particular have seen the value of Agile and have adapted the myriad of tools and practices it offers to better suit their purposes. 

What’s in Your Toolbelt? 

Agile encompasses a variety of practices and tools that enable a sustainable cadence and constant value production. Many of these could be easily adapted to benefit any team, including: 

  • Daily Stand-Ups. A brief, 5-minute meeting where team members share the progress they made the previous day, what they plan to accomplish today, and any problems or dependencies that might block their progress. 
  • A Kanban Board. A visible, prioritize backlog of all the work that a team is trying to accomplish, what step of the process it is currently in. 
  • Sprint planning, review, and retrospective meetings. These meetings are meant to make decisions regarding which work is being prioritized, and what teams are trying to accomplish in the next 1-2 weeks. These eliminate many “ad-hoc” meetings by giving the team a clear plan to move forward with, so that they are never stuck wondering what to do next. 
  • Using Story Points. Story points are a rough sizing meant to align capacity to workload, and 1 story point often reflects 1 day of work.   

Helpful Roles 

In addition to those tools, Agile teams have two key roles that help ensure that teams are high-functioning and constantly delivering value. These roles are: 

  • Scrum Master. Scrum-masters are responsible for helping teams perform at the highest possible level. They work to remove obstacles towards them accomplishing their work, guard against outside requests that distract from accomplishing the team’s goals, and coach the team to be as high performing as they can be. 
  • Product Owner. Product owners are responsible for ensuring that the team is constantly delivering value to the customer or other stakeholders. This primarily includes prioritizing the backlog of work and communicating with stakeholders to ensure that their needs are being met. 

First Steps  

So, how should you go about implementing Agile outside of IT? When another department expresses interest in adopting Agile, it’s typically a good idea to ask why they want to. In some cases, their interest is driven by observed needs in their department for a more sustainable cadence and constant value production. In other cases, a department that expresses interest in Agile may only be hoping on the bandwagon. 

In either case, understanding the reasons why a department or team would want to adopt Agile can inform your plan going forward. When departments can identify why Agile would be beneficial for them, it can be easy to build a roadmap for implementation that fits their needs. When departments can’t easily identify those statements, you need to ask more questions to narrow down what Agile tools and practices they would benefit from. 

In either case, it can be helpful to start small. Establish one “pilot” team to test how Agile could best be implemented in the department. Start by only implementing one or two Agile practices or tools, such as a daily stand-up. Then, as time goes on and the department identifies their needs better, continue slowly implementing additional practices and tools that meet those needs.  

When adding additional practices and tools, keeping the needs of the team in mind is vital. Agile is not a set of business dogmas that that must be adhered to at all costs, it is a set of tools and methods that your organization can implement in part or in whole, depending on your needs. There is no good in being an Agile perfectionist. Whether you end up with a framework that is purely Agile or a hybrid of Agile and a traditional “waterfall” framework is not important, only that the result is deliberately chosen to best help the team deliver consistent value. 

After Agile has proven successful in one team, it’s easy enough to create more Agile teams until an entire department has successfully adopted the framework. 

Conclusion 

While Agile may have been designed for software development, its emphasis on maintaining a sustainable cadence and consistently producing value is something that nearly any team could benefit from. Certain Agile practices such as daily-stand ups and Kanban boards, are tools that would be helpful to any team. Similarly, incorporating the scrum-master and product-owner roles into the team will enable them to perform at their best and to maintain a consistent focus on delivering value to the customer. These tools and roles can be adopted in whole or in part to fit the needs of the team. 

EIT has experience helping clients of all sizes make Agile work for them across every department and level of their organization. For information on EIT can help you adopt Agile in a way that meets your business needs, click here