How to introduce Agile to non-IT teams

It’s clear that the Agile Methodology is not restricted to software development teams. Countless organizations have improved their flexibility and delivery speed with an Agile mindset, and many have successfully scaled Agile through every department. Agile is already widely used in marketing, education, and even auto manufacturing.

If you’re a non-IT team that wants to adopt the Agile mindset, you will likely encounter some resistance to change. This is good. Criticism of Agile can help your application of its values to improve. To encourage the implementation of Agile in non-development teams, you should first demonstrate the value that an Agile mindset can deliver.

Don’t prescribe; encourage

The Agile methodology has (unfortunately) been fairly well-saturated with buzzwords and prescriptive practices. As Dipanjan Munshi puts it, “The process whose manifesto declared ‘People over Processes’ has now became a standardized prescriptive process in itself.”

To avoid putting anyone off unduly, don’t introduce Agile as a set of prescriptive processes. Instead, frame it as a cultural practice and a mindset for approaching work. Applying Agile to non-software projects will bring additional value to your business, and should not be treated merely as a trend. Non-technical teams usually have specific requirements that are not easily met with classic Agile methodology right away. However, there are certain elements that will advance your existing workflows and move your team towards an Agile culture in just a few iterations.

Note that a successful Agile culture will help to increase employee independence, trust, and personal responsibility. In a traditional environment, management ends up being responsible for both failures and successes. In an Agile environment, responsible individuals shoulder this responsibility.

It’s important for Agile transformations to happen more-or-less organically. Nobody wants to put up with another vague strategy change that’s been mandated by management. This is the the sort of thing that an Agile mindset is supposed to eliminate.

Don’t transform; iterate

There are a lot of practices that have formed around Agile; introduce them iteratively, and you’ll can avoid the culture-shock that has stagnated many transformations. To get started, research Scrum and Kanban. Try to understand which practices might work for you, and why:

Kanban – Kanban uses a board with cards that represent work items. As a work item progresses from idea to completion, it is moved forward through the board’s swimlanes. It’s great for helping teams adjust to frequently changing priorities. Setting WIP (work in progress) limits helps teams to reduce context switching and avoid getting bogged down by an ever-expanding scope of work.

Scrum – Scrum is great for organizing teams and for making continuous improvements to your work process using Retrospectives. It’s fairly heavy on planning (compared to Kanban), and uses fixed iterations to help teams understand and improve their velocity. Most teams utilize a Scrum Master – an individual whose job it is to facilitate meetings, remove impediments, and generally help the team get their work done.

If you’re aiming for a large scale shift to Agile, take extra care when planning change. Peter Merel, a long-time Agile consultant and founder of the XSCALE Alliance, advocates the use of steel-thread squads: A small number of progressive people adopt Agile practices and measure their metrics to prove the productivity benefits. The team then divides like a cell and spreads to other teams. This allows for a natural change that doesn’t disrupt the established organization. The transformation is iterative rather than sudden; Agile is adopted using Agile.

Bridge the gaps between software development and the domain of your teams

Some Agile coaches have noted that it is difficult to link the idea of “delivering working software” to other fields of work. Opposition tends to come in the form of rebuttals such as “We’re too quality-focused to adopt this practice.”  This line of thinking comes from a lack of understanding about the core principles of Agile.  Keep in mind that Agile does not mean sacrificing quality for speed. Rather, it means you should deliver the highest quality you can, without getting bogged down by process or bureaucracy.

The concept of developing “working software” can easily translate to any field. It simply means the first point where you can deliver real value to your customers. Define the variables of what “working software” and “end user” means to your team. Figure out what what could be considered as one of the basic building blocks of your final deliverable so that you can get feedback at an early stage.

You also shouldn’t feel obligated to use the vernacular of Agile. It was created in an IT world, and might be irrelevant or confusing for your teams. Consider changing the terminology of your tool or processto reflect the vernacular your team already feels comfortable with. For example, a marketing team might rename Features as Campaigns, a sales team might rename User Stories as Leads, etc.

Synchronize, but don’t get bogged down by ceremony

When you have multiple teams practicing Agile, you run the risk of creating what has come to be called “Agile silos.” These are teams which are practicing Agile internally, but lack cross-team or cross-departmental coordination. This is not a good recipe. There needs to be some sort of unifying vision to help turn these different teams into a collaborative ecosystem. There are multiple frameworks to help you plan this out, including SAFe, DaD, and LeSS. Our Targetprocess tool can be set up to support your unique workflows and processes in all stages of Scaling Agile.

So, it’s important to synchronize your teams, but you also have to be careful to not get bogged by ceremony and bureaucracy. A central pillar of Agile is replacing processes with interactions. Adopting the ceremonies of Agile without understanding their purpose is a huge red flag. Don’t constrain your teams by trying to over-synchronize them with processes that they don’t need.

“Humans are of very low value as cogs in a machine doing identical things in interchangeable ways. That’s for robots. Humans are most valuable when they have high autonomy, and able to play to their unique strengths and histories, particular sensitivities, op-tempos, and patterns of privileged information. The idea of “wisdom of the crowds” in fact rests on humans having diverse, unique private knowledge bases. The madness of crowds kicks in with synchronization and imitation.”  –Premature Synchronization is the Root of All Evil

Final thoughts

One of the biggest pitfalls you can fall into is looking at Agile as a cure-all panacea that will help you do more work in less time. This is not what Agile is about. It’s about breaking out of the rigid structures that constrain individuals from completing their work in the best possible way. Get a live product demo today and see how Targetprocess can help you move closer towards Agile success for your non-software projects.

Learn the various techniques and strategies that Agilists have accumulated over the years, and pick the mixture that works best for you. Above all, don’t lose sight of the values in the original Agile Manifesto.