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.

The Agile Approach is Actually a Varied Approach

In my last post I discussed the conditions that drive organizations towards agility, using an adaptation of the Stacey Matrix (from Strategic Management and Organisational Dynamics by Ralph.D. Stacey). In this post I’ve annotated this diagram in different ways, highlighting how different approaches are required to deal with each type of work:

With predictive work, the path to success is clear. A perfectly valid approach in these circumstances is to plan the work and work the plan. This is an ordered approach where detailed planning helps to ensure that all of the bases are covered and that there are people available with the necessary skills and capacity to perform the work.

The approach to emergent work takes a different path out of necessity. The greater levels of uncertainty demand use of an adaptive approach, making use of a series of small, frequent experiments in order to validate our assumptions about what is truly valuable and how to best go about delivering that value. These are our all-important feedback loops designed to inform and guide us.

A key implication with an adaptive approach is that we focus on defining and delivering against a desired outcome without a defining a long-range, detailed plan up front. We keep our options open and seek to uncover the best possible solution by iterating over the problem, incrementally building value.

Waste will occur if we use an ordered approach to emergent work because the greater levels of uncertainty negate our ability to predict very far into the future. Striving to define a long-range, detailed plan up front forces us to make decisions based on untested assumptions. This can lead to cost overruns and late deliveries due to re-work if those assumptions are found to be invalid.

This does not mean that detailed planning is eliminated! Instead, detailed planning is spread out across those previously mentioned, small experiments that are designed to contribute in some way towards an explicit outcome: we create a hypothesis that articulates the measurable benefit we are striving to achieve, run a quick test, evaluate the results, and if required, we adjust and conduct another experiment to further validate our understanding. If no adjustment is needed, we press on with our next “experimental increment.”

And of course, we must deal with chaotic work, which are those urgent, unplanned issues that arise. The approach best suited here is to triage each issue and respond accordingly. Some issues, like those that are preventing or seriously hampering day-to-day business operations, require an immediate response and will interrupt other, planned work in progress. Lesser-critical issues can be prioritized and dealt with alongside other planned work, with the first response being a communication back to the reporter regarding the disposition of the issue so that they aren’t left wondering what is going on.

Taking a step back, we can see that for each approach for each type of work, there is a primary objective:

A key message in all of this: Achieving optimal results is a function of each approach being fit for the purpose. 

Although agility is intended to help us deal with the increasing amount of emergent work present in today’s globally-competitive climate with high rates of change, agile teams actually make use of all of these approaches in their day-to-day work. They triage and address production issues. Sprint planning and execution (assuming the use of Scrum, the most popular team-based framework) is all about creating and working a detailed plan to deliver. And teams inspect and adapt leveraging short feedback cycles.

The Agile Stimulus Package

Why go agile? Specifically, what is incenting your organization to embrace agile? What is the impetus for change? As you consider this, additional questions will emerge: For example, do you need to be all-in on agility, or can it be selectively applied? And if agile can be selectively applied, what are the conditions or circumstances where it makes the most sense?

The following diagram is an adaptation of the Stacey Matrix (from Strategic Management and Organisational Dynamics by Ralph.D. Stacey) that I’ll gradually annotate to address these questions, building up to a key conversation that you need to have:

This diagram denotes three types of work, two of which are characterized by the levels of uncertainty that are present:

Predictive: Work where the path to success is clear. There is a shared understanding and agreement on what is valuable and how to go about delivering that value.

Emergent: This is complex work where the path to success lacks clarity, at least at the outset. Typically, there are multiple options available, both in terms of what is considered valuable and how to go about delivering it. Experimentation and frequent feedback are required to learn what is truly valued as well as triangulating on the correct path for your team or organization to use to deliver that value.

Finally, there is chaotic work, which are urgent problems or issues that arise that demand immediate attention. You can’t predict exactly when or what problems or issues will arise, but if you haven’t budgeted peoples’ time to address these issues (which can be done to varying degrees, according to your needs) you will disrupt planned work.

Many organizations have traditionally recognized and used approaches to deal with predictive and chaotic work, but they are now increasingly contending with emergent work because the rates of business and technological change have increased. Today’s hyper-competitive business climate is driving organizations to reliably deliver faster than ever before, at less cost.

Consider the implication of that last sentence for a moment. Are you facing these demands? If so, does this indicate that competitive demands and goals of your organization are disrupting your status quo, demanding significant improvement?

If your answer is yes, then you need to consider what agile has to offer. It helps you to tackle the drivers and influencers that are increasingly transforming work to be emergent in nature:

The key conversation that you need to have with respect to agility is how much, if any, of your work is emergent in nature. Agility is all about increasing your ability to rapidly validate your hypothesis about what is deemed valuable while simultaneously determining the best path to deliver that value. This is done by delivering smaller changes with greater frequency. It’s all about being responsive and adaptive, where teams and organizations are continuously learning and improving in an increasing complex, competitive world.

I’ll continue to explore this topic in future posts, continually annotating this diagram in different ways.

Don’t Just Do Agile

The Agile Manifesto can create challenges when it comes to agile transformations, particularly in the early stages. This isn’t a fault with the Agile Manifesto; I regard it as a brilliant piece of work. The issue begins when teams or organizations limit their attention to agile practices, using appealing logic such as, “At this point in time, we’re establishing a baseline.”

This point of view can be inadvertently supported by the Agile Manifesto itself. What happens when those who are new to agile read the Agile Manifesto? Without additional information and guidance, they can come away feeling that the values and principles are nebulous or too theoretical. This can lead them back to that, “We’re just trying to get the basics down” line of thinking.

On the face of it, this feels like a perfectly reasonable approach. Focus on agile practices and framework(s) – which are more concrete because they tell you what you need to do – and you’ll be agile, right?

Caution! The Agile Manifesto is an articulation of what was found to be common among the various approaches to software development championed by the crafters of the manifesto. Don’t get me wrong, I fully support the concept of understanding the difference between doing agile (the practices) and being agile (the values and principles) as being both insightful and useful. It helps categorize aspects of agility, enabling you analyze where you are strong and where you need improvement.

However, if you aren’t embracing and incorporating the underlying values and principles into your day-to-day work, then you have distanced yourself from the very things that distinguish agility from other approaches. Never view any agile framework or practices and the Agile Manifesto in isolation. They are intrinsically linked.

Can you have a peanut butter cup without the peanut butter? No. Practicing “agile” in a way that is removed from the values and principles is nothing more than an application of new vocabulary to existing ways of working, an implementation of cargo cult practices that aren’t actually achieving the desired results. Simply stated, don’t leave out what is truly valuable with respect to transforming to agile in the first place!

And just for fun, here’s this guidance expressed in a user story format:

As an agile practitioner, I need to apply agile values and principles to any agile practice I perform, so that I – and my team and organization – can experientially learn and realize the benefits of being truly agile.

Guiding Agility

I’m an Agile Coach, but I’m branding myself as an Agile Guide. So, what exactly does that mean? And what about my Transforming work. Transforming life. tagline?

Let’s say I’m working with your team or organization. As an Agile Guide, it's up to me to lead you through territory that is unfamiliar to you. If you are in a startup mode, for example, I'm likely to advise the use of Lean Startup principles because they are designed to reveal the correct path forward, informing you about what product or service customers value and how to build a sustainable business.

For established companies transitioning to agile, the dynamic is different. I’m not taking you through completely unfamiliar territory; you know much more about your customer base and your work than I do. The first step in these engagements is all about me acquiring a solid understanding and appreciation of your current state. Generally, I find people to be very helpful and enthusiastic about getting me up to speed on both business and technical fronts. The tricky part usually comes after we’re aligned on what the existing terrain looks like.

It comes when I ask you, metaphorically speaking, to use a different path. Suddenly, things start to look different, less familiar. Your old map doesn’t have the same value it once did, and feelings of uncertainty and apprehension begin to creep in. You might assert that, “We’re unique…” or that, “We need to stay on our old path for a while, then we can cut over and be agile…” – you’re seeking permission from me to stay on that old, familiar path.

I get it. There aren’t any big surprises on that old path. You know what is coming because you’ve walked it many times before. However, you prepared me by educating me about your terrain, now let me return the favor by preparing you with new information and insights. And we’ll walk down that new path together.

That’s why I’m there! Maximize what you can get from me. The objective is for you to have a new experience, covering your terrain from a new angle, working together to address any unforeseen issues as we encounter them. The payoff from all of this is captured in my tagline: Transforming work. Transforming life.

This tagline is the result of my reflecting on my first agile experience. I was a manager in an organization that worked very hard at developing into an authentic, agile organization. Once we got it right – and that took a while – it became abundantly clear just how transformational agile can be.

We created raving fans. We introduced a new, successful product. It became obvious that having a fun, collaborative, supportive, productive and sustainable work environment enabled people to not only come to work feeling energized, they left the feeling the same way. As you can imagine, this in turn had a positive effect on their personal lives as well.

That is why I became an agile coach. To help you create the same impact. I can’t do it for you. But if you are willing, I can help you get there!

Welcome!

Thank you for joining me, and I hope that you find the content (future content as I write this) informative, useful, and even a little inspiring.

Given that I'm actively engaged with agile coaching, my intent is to publish monthly. I consider this to be achievable based on prior experience -- barring any unforeseen problems that may come my way. At any rate, consider this my public statement of intent. 

I welcome any comments or insights that you would like to share, so please don't feel shy! And if you have any burning topics that you would like to see me cover (or at least attempt to), I'm all ears!

Again, thanks for joining me, I appreciate it! I look forward to engaging with everyone on this blog.