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.

Applying Agility to Non-Software Work

As I discussed in The Agile Stimulus Package, there are key drivers or influencers that lead you towards an agile approach to work. In a subsequent post, I outlined three different approaches to work that agile teams use in actual practice.

In this post, I’d like to tackle a challenge that I’ve been encountering with greater frequency in recent years: How do we beneficially apply agile principles and practices to non-software knowledge work?

My first foray into the non-software agile realm was with a marketing group that had split into three different teams. Within minutes of engaging with this group I learned that they had certain assumptions about agility and what my role was going to be.

Here’s a condensed version of our initial conversation:

“It’s great that you’re interested in being agile!” I began. “Tell me about your work!”

“No,” the manager of the group replied, “you just need to tell us about agile.”

“Well,” I countered, “there are options, and it’s difficult to know what would be useful without a little background.”

“Just walk us through it and we’ll figure out how to apply it.”

The situation was clear – in their eyes I was a Subject Matter Expert whose knowledge they could extract and apply to their circumstances.

Even though I strongly felt that we weren’t getting off on the right foot, I ended up “telling them about agile” by walking through the Scrum Framework. My gambit was that any time that we spent talking about agility would open the door for them to share more about their work and needs, creating the opportunity more informed discussions.

During the Scrum walk-through, they kept saying things along the lines of, “I don’t see how that won’t help us” and, “We’re already doing that.” While their initial enthusiasm was waning, they became more receptive to my, “Tell me about your work” queries as we continued.

The good news was that they had already re-organized to form highly collaborative teams. We quickly validated that the teams were correctly formed in terms of closely aligning individuals who needed to regularly collaborate on developing specific marketing assets.

As we continued to explore the specifics of their situation, a key issue emerged. As a part of forming highly collaborative teams, they emphasized the ability for each team to focus. In practice, this translated to teams being very disciplined about protecting themselves from outside distractions. While this isn’t necessarily a bad idea, they were experiencing pain as a result.

The missing ingredient was something they had stopped doing in their quest to “be agile.” While the teams could independently create marketing assets, there was a need to coordinate and synchronize the collective efforts of the teams into marketing campaigns.

In their pursuit to keep each team independent and focused (agile, as they interpreted it), they ended up introducing unnecessary overhead and delays to address the inter-dependencies that existed between teams by generating additional artifacts to share between teams to help coordinate activities. And between the time spent creating, updating, and passing these artifacts back and forth they had managed to increase the total delivery time of their marketing campaigns.

They needed to support the value of, “Individuals and interactions over processes and tools” along with a key principle that guides our behavior in support of this value, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

I’m sure you can guess where we went next!

Yes, a simple, lightweight scaling mechanism known as the Scrum of Scrums paid off handsomely. They had been doing this in the past (calling it a sync. meeting), and once we talked about what the Scrum of Scrums was all about, they immediately recognized the benefit. The surprise for the marketing group was that this was considered “agile,” but once they re-instituted this practice, all the pieces fell into place and they obtained the results they were looking for.

I’ll dive into additional aspects of applying agile principles and practices to non-software work in a future post.