Three Key Principles to Use in Applying Agility to Non-Software Work

In my last post I described a session I had with a marketing group who wanted to apply agile practices to  their work. The challenge in this situation was their expectation that agile was a singular, defined set of practices that they needed implement. As I covered in that post, during an exploratory discussion we managed to uncover one, impactful practice that improved their situation.

Not all situations will be as easy as that one! Particularly if we’re dealing with complex knowledge work that involves a variety of interactions with different (complex) people. And therein lies the trick. We need to determine which “agile knobs” to turn – practices – that will be impactful.

Based on my experiences, I’ve found that the three principles in this post help to set expectations and guide conversations when it comes to applying agility to non-software work.

Principle #1: Establish a Working Partnership

If we’re going to be successful at applying agile principles and practices to non-software work, everyone involved needs to agree to making a small investment in time to explore and shape an approach. The most effective solution will be the result of experts in the details of the work at hand and any associated workflows along with experts in agile coming together and co-creating that solution.

This guidance is rooted in the history of the Agile Manifesto. The crafters of the Agile Manifesto were experienced thought leaders in software development who had independently developed alternative approaches to, “documentation driven, heavyweight software development processes.” The Manifesto for Agile Software Development was created in 2001 as these practitioners discussed what was common with their respective approaches.

Bottom line: If you want to save time and reduce frustration levels, establishing a working partnership is vital. A candid, robust exchange of perspectives and ideas is the fastest route to identifying and evaluating options for applying agility to the work at hand.

Principle #2: Use a Customer-Focused Lens

What we’re after here is to provide ourselves with a frame of reference that enables us to readily understand where we can improve. Whether we are talking about software or non-software work, there is a related agile principle that we need to adhere to: our priority and purpose is to deliver value in the eye of our customer.

Maintaining a customer focus in everything that we do gives us full visibility and insight into what it truly takes to satisfy our customer(s). It helps us understand where various forms of waste – inefficiencies – exist. Individuals, teams, etc. – whoever plays a part in the overall, customer-facing delivery – should seek to optimize value delivery in the eyes of the customer.

Without this perspective we run the risk of optimizing in ways that can interfere with customer delivery. We can inadvertently create overhead and delays with well-intentioned efforts to drive efficiencies in the various steps in the process or functions involved. One way we do this is by defining rules of engagement to request and manage work across these steps and specialists, oftentimes increasing the amount of information required to hand off the work with minimal (or no) interaction required by the participants. And pressure to keep specialists fully utilized can lead to the generation of lesser valued work that may strain other parts of the customer delivery chain.

I’m not says that efficiency is evil! However, efficiency at delivering customer-facing value can be a very different thing than efficiencies focused on the delivery of intermediate outputs or keeping a certain subset of functional specialists fully utilized by working in a narrowly defined specialty. Our objective is to eliminate counterproductive sub-optimizations and instead seek to optimize the whole.

Principle #3: Model Interaction Patterns to Determine Impactful Solutions

This is based on an observation that is all too-easily overlooked:  All knowledge work is not equal. By that I mean that all knowledge work is not the same as software development work, which typically (but not always) demands that multiple specialists closely collaborate in order to shape a high-quality, customer-facing outcome.

I’ll refer back to my experience with marketing groups to illustrate my point. In one organization I worked with there were various marketing teams dispersed to align with product areas targeting specific customer segments. Drilling down to the team level, these marketing teams were using Scrum, with the key benefits being:

• They had a shared understanding of the marketing objectives that the team needed to accomplish
• They understood their capacity
• They prioritized key deliverables
• They could visualize their work and track progress, enabling them to focus on getting things to “done” in short cycles (Sprints) and on a regular cadence

Here’s where it got interesting. I observed that unlike software development teams, they did not require a lot of day-to-day collaboration to deliver customer-facing value. Individuals took point in various aspects of the team’s work, coordinating with other team members when necessary, but they rarely required close collaboration amongst themselves to be successful. And when they did need to coordinate on something, it was generally with someone else on another marketing team.

There were times, however, when the marketing function of the organization benefited from close collaboration. It was highly desirable to design and develop consistent marketing messages and campaigns that spanned customer segments and/or resonated with customers who engaged with the company in different ways. Other situations, such as company-wide marketing events naturally required both coordination and collaboration. (I’m obviously generalizing a great deal, but hopefully you get the idea.)

The takeaway here is that understanding the nature of the work along with understanding the frequency and depth of interactions required to deliver customer-facing value are the key factors in creating an impactful solution. Some key questions that need to be answered include:

• What work needs to be performed?
• Are there different sub-types of work with different needs?
• Who needs to play a role in shaping the work?
• Can the work be performed independently?
• Does the work require coordination (synchronization) with other individuals or teams?
• Is there a need for more than one individual or team to interact closely to collaboratively shape ideas, exploring and building upon each other’s thoughts?

Once these elements are understood, specific practices can be recommended. And as always, with the goal of maximizing delivery in the shortest amount of time, for the least amount of effort.

In the example above, a monthly or quarterly cadence might be required for multiple teams (or key representatives) to come together to shape marketing priorities and campaigns, whereas teams focused their day-to-day efforts primarily based on individual contributions and lightweight coordination, tactically collaborating when it makes sense, such as creating a targeted email blast.