Blog

Agile is a solved problem, in the tech world. In software development environments, it’s now a staple. You would struggle to find a single development team or technology project that isn’t using an agile framework to plan and execute their work. The idea has long passed from experimental to adoption; it has saturated the market.

Little proof is needed for this claim of complete saturation. Just look at the list of certification-ready agile methods: SAFe, Scrum, Crystal, DSDM, Feature-Driven Dev, ASD, Lean Software Dev, Disciplined Agile, RAD. Beyond the certifications you’ll find (often decades old) schools of thought around Wagile, eXtreme Programming, and others. When you can certify yourself in a handful of different frameworks around the same concept, then it’s safe to say that the school of thought is here to stay.

Outside of tech, though, the potential of agile is still largely unrealized. Waterfall methodology is still the dominant approach to project and product management. At the Gunter Group, we feel this is a missed opportunity. The practice and benefits of agile should no longer be the sole domain of nerds. 

The Coming Revolution

Agile has revolutionized development, or rather, agile is the response to development’s demand for revolution. Waterfall was the child of the uniquely meandering progress of early software projects. Early development borrowed from manufacturing, aerospace, and defense methodologies of the time, and depended on long runways for delivery (and even occasionally relied on physical manufacturing processes).

However, as software leapt forward, the waterfall methods of old failed to serve the split-second pivots required by the go-to-market environment of modern technology. Software development demanded a new kind of organization, one as iterative and quickly-changing as the 1’s and 0’s upon which it was built. From this need, agile was born.

It is a mistake, however, to limit agile to the tech environs of its birth. There is nothing about agile that is necessarily specific to software development. We repeat: there is nothing about agile that is specific to software development. It is a framework that has application well beyond its homeland.

A renaissance is before us. Agile has yet to have as meteoric an effect on the broader business world as it has in all-things-tech, but this change is on the horizon. In this article, we will explore several simple means for the application of agile in non-tech environments.

This article is for agile practitioners. It is also for anyone else who works in a world of projects and output-oriented teams. That means everyone. Yes, you read that right: everyone. (Even construction has room for agile. There are certainly limits to the application, as failing fast in that landscape could be catastrophic. Construction is a mature industry with many unique frameworks for success, but the concepts of agile are still applicable in creative ways. Design iteration, proposing and awarding subcontractors, and daily standups with subs might be areas for immediate agile-inspired growth).

Tried and true in the tech-focused backbone of our ever-changing world, the revolution of iterative, cross-functional, self-forming teams will ripple through organizations and markets of all kinds. The thoughts below are intended to give you a leg-up in this revolution, to find yourself ahead of the curve in the battle for better business.

The Business Cycle & Agile: An On-Again, Off-Again Relationship

Agile has a place in the business cycle, but only one place. The picture below illustrates this (a notable exception to this limitation can be found in the SAFe framework, which has made progress in utilizing agile in a broader business context). Agile is often embraced by a development team or manufacturing process, but everything upstream and downstream from these teams still think of their work in terms of waterfall. As the landmark book The Lean Startup explains in detail, this often results in products reaching the market after months or years of investment without validation that the product is even needed.

This can be fixed. At TGG, we have seen successes and failures with clients attempting to embrace agile methods. There is no one right or wrong way to embrace agile, but we have seen some general activities or mindsets prevail over others.

Below is a list of high-level considerations you should keep in mind if you are interested in adopting agile in your non-tech team:

Don’t Do Agile for Agile’s Sake: It can be easy for a leader to say, “It works for the Unicorns so it should work for us.” As a result, agile or lean Centers of Excellence sprout up in organizations that are not ready or willing to embrace these methods. Agile only works when a team understands why they are doing it and are engaged in the method in a way that adds value. It is all about developing business agility and driving value to the customer—not just about “doing” agile.  

Find the WHY (Value Added): People are more willing to change when they understand why a particular change will benefit them. This is universally true, and is a fundamental concept that drives all successful change efforts. When accompanying a team that is new to agile, break the component parts down into WHYs that demonstrate the value added by an agile element. More on this below.

Use a Light Touch: For teams that have been thinking in terms of waterfall timelines and years-long delivery plans, agile is not intuitive. This is even harder for teams that don’t operate in a project environment, such as operations, finance, or HR. It is uncomfortable for someone new to agile to imagine releasing their work before it is “completely done.” For these people, adopting agile represents a culture change. Use a light touch, and embrace change management best practices. Educate on the value of embracing agile ceremonies and artifacts (see Point #2), and give them time to adjust to a new work culture.

Think About Slicing Small: You might think that the key difference between waterfall and agile is the speed of the work. However, this doesn’t quite capture the power of agile methods. Agile teams don’t work faster—they work smaller. Sprints are only successful when a team can break their work into smaller chunks that can be accomplished, reviewed, and delivered to customers in a matter of weeks. When looking to adopt agile in your non-tech team, this can be one of the hardest yet most rewarding mindsets to shift. Ask yourself the question: “What can we complete this month and deliver to our consumers?” 

Start with Standups and Retrospectives: When in doubt, the easiest place to start with agile adoption is with standups and retrospectives. Gather your team together so everyone can give a 30 second status update and share any blockers. Encourage recognitions, because they actually do boost engagement. Periodically bring everyone together to reflect on the way they work, and encourage them to think creatively about small changes they can make to boost productivity or morale. These rituals are baked into agile systems but are often overlooked in the recipes of other structures. They are ceremonies that are simple to implement (their WHYs are easy to understand), and they immediately add value to your team.

Find the WHY: Representing the Value Added by Elements of Agile

In tech, it is easy to take agile for granted. There is little need to investigate why that is the case. Dev teams embrace the frameworks without the need to justify why. Tech simply trusts the efficacy of the model.

Non-tech environments are more skeptical, however. Business units accept the place of agile in their organization’s tech division, because the quality and turnaround of their tech solutions are desirable outcomes. But a chasm exists, an us versus them void between tech and business, in which each realm agrees to the ways of the other without cross-pollination. “Agile works for IT,” says the non-IT department, “but we will carry on as we always have.” 

When making the crossover from tech to non-tech, asking WHY is essential. When making the case for an agile adoption in a non-tech environment, it is not enough to know THAT agile works; you also have to understand WHY it works. 

The core concept of this article is this: by breaking down the framework into a series of WHYs, you are able to build a business case for its adoption.

In Search of WHY

Before diving into case studies, we’ll pause to give a couple brief examples of how to find WHYs. First, we’ll give an example of finding a WHY, and then we’ll observe an organization that has used this WHY thinking approach to maximize the benefit of agile enterprise-wide.

We’ll start with an example of a WHY. Any agilist knows of two basic roles that tend to show up in any agile framework: the Scrum Master and the Product Owner. But why are these roles so valuable? In short, they capture a tension that exists in every project: throughput versus quality. 

The Product Owner represents the customer. He or she is ultimately accountable for the product that hits the market. They massage the backlog, prioritize features, and vouch for the throughput and objectives of the customer. The Scrum Master, on the other hand, is a servant to the team. He or she is responsible for maximizing the value of the team’s work by removing impediments and maintaining focus. 

In every project, there is a tension between speed and quality, and often these elements are at odds. Teams have to choose between the speed or quality of their throughput. The roles of the Product Owner and Scrum Master capture this tension, striking a balance that delivers a timely, quality product. 

Here’s the WHY: agile purposefully creates this tension. The Product Owner advocates for the deliverable; the Scrum Master advocates for the team. There is no consensus without dissent, and the dissent built into the agile framework ensures a consensus between the competing demands of immediacy and quality. 

You’ll notice, in this example, that the WHY is subtle. It simply looks at two roles and understands the purpose for each of them, both individually and together. But their purpose, the WHY, is powerful. Maintaining the tension between throughput and quality ensures that an agile team continuously delivers a product that is valuable. 

There are many examples of organizations finding the WHYs, but a fantastic example can be found in the way Spotify approaches an agile culture. Spotify, a tech company, started from the assumption that agile adds value. But they also embraced a key mindset: rules are a good start, but let’s break them when needed. This led Spotify to match its needs (autonomous squads, short term goals, and an enterprise-wide holistic product strategy) to the WHYs of agile (throughput vs quality, flexibility, consistency, autonomy, alignment) to create a truly unique structure of tribes, squads, chapters, and guilds.

These unique, overlapping structures don’t conform to any particular agile method, but point to the WHYs of agile as necessary predecessors. The result: a nimble organization and healthy culture that keeps pace with the ruthless, fast-paced competition of streaming music solutions.

Agile in Business: Case Studies

So far, we have discussed the concept of embracing agile elements in non-tech teams. Let’s look at a few examples of this concept in action.

The Lean Startup – Laundry Services in India

A current popular expression of these concepts can be found in the book, The Lean Startup by Eric Ries. Over the course of 300 pages, Ries walks the reader through a home-grown approach to agile adoption grounded in decades of direct and indirect (consulting) experience with entrepreneurs and startups.

Core principles of The Lean Startup include small slicing vision into minimum prototypes, testing those prototypes early and often, validating assumptions, and promoting a culture of constant adaptation and growth. These agile-adjacent methods are all implemented without any of the typical agile ceremonies or artifacts.

There are dozens of case studies in the book that demonstrate the WHYs in action. One example comes from a laundry service launched in India: Village Laundry Service (VLS). In 2009, VLS was poised to launch a low-cost modest-return laundry service in a virtually untapped market in India.

The company, however, paused to create small-scale experiments to validate product assumptions and zero-in on specific customer needs. They embraced a model of iterative testing and adaptation that allowed them to target a rollout that was specifically tailored to customer needs. This meant that, once scaled, VLS was sure that they were mass-producing a product that customers would actually buy.

National Insurance Provider – Accounting Team “Scrum”

An insurance provider engaged us to assist with an ERP implementation that would replace the general ledger that accounted for tens of billions of dollars in managed assets and revenues. In the organization, there was a Lean Center of Excellence that had been advocating for agile ceremonies across the organization for several years. However, the accounting department had not yet adopted any of these elements. Early in the project, the team decided to organize themselves into a scrum team, with all the usual ceremonies and artifacts.

Initially, the transition was difficult. The team consisted of financial analysts and operations managers, and no one had project experience (let alone a knowledge of scrum). The “scrum team” was also larger than recommended, with more than 15 people.

Over time, the team used the ceremonies to break down their activities into a series of WHYs. Daily standups helped illuminate blockers and inefficiencies, and sprint retrospectives allowed the team to reflect on what was working and what wasn’t. Before long, the team developed a rhythm to their work and were able to break out the scope into smaller slices that more efficiently made use of their resources. Additionally, they were able to quickly track and validate decisions made about the product, which allowed for quicker pivots that better met the needs of their internal stakeholders.

HR Job Posting – Introducing Small-Slicing to Recruiting

On November 20, 2019, TGG’s Tech Services Lead Matt Jamison presented to AgilePDX on the topic of adopting agile elements in non-development teams. To illustrate his ideas, he shared an example of applying agile to talent acquisition in an HR department, with regard to staffing practices. 

The Problem Statement: the struggle to find and hire talented resources presents a series of constant hurdles. Even without complications, it is difficult to sort through the tides of resumes to find individuals who have the professional and cultural acumen needed for a particular situation. 

But hiring does not occur in a vacuum, and complicating factors abound. Hiring teams struggle to match job postings to the continuously changing needs of their organization. Market factors like shifting regulations, emerging fields, and competitive innovation require constant adaptation to who or what an organization needs on their teams. On top of this, the company mission is regularly transitioning due to adaptations from corporate strategy and new products. 

When hiring for a team, there is a need for agility. Despite this, overworked recruiters are often incapable of the continuous change that would empower them to hire better, faster, and smarter. Poll HR professionals and you will likely hear the same thing, “I’m not getting the right talent. It takes too long to get talent. How do I assess the growth of employees and allow for advancement? I don’t respond quickly enough to changes in my organization and market.”

Enter the Agile WHYs: how would an HR team look to agile to address some of their struggles? Start with the problems: 

– There is too much to change and not enough time to adapt
– Changes in job descriptions require a lengthy approval process

Looking at these problems, several agile WHYs start to jump out in response:

– Vertical slicing deliverables into bite-sized stories
– Sprint structure allows for near-term pivots on vertical slices
– Empowering team members to problem solve allows for quicker creative solutions
– Iteration on pain points or strengths allows for continuous improvement

An HR team embracing these WHYs wouldn’t have to embrace a full scrum adoption to realize their benefit. They could small-slice a job description, looking at components of a specific description instead of the whole thing. They could explore ways that recruiters could update parts of job descriptions in a quicker manner without needing full bureaucratic and legal review involved with a new job post. They could collect user stories from teams with upcoming resourcing needs instead of a list of qualifications and specific experience, empowering recruiters to be more creative in finding the right fit. 

By embracing the WHYs of agile, teams can borrow the best parts of the methods and ceremonies to foster agility. And by doing so, they are living up to the core principles of agile, putting individuals and interactions before processes and tools.

---

We want to close this paper by reiterating a key point that is foundational to adopting agile in new environments: don’t do agile for agile’s sake. If either managers or direct reports fail to understand the reason why they are making a change, then that change is destined to fail. Do not embrace agile just because it’s trending in high-dollar markets. 

There are good reasons for the successful outcomes of agile—a successful adoption requires an understanding of these reasons first. After witnessing successes and failures in the market around us, we firmly believe that a team must understand the WHYs of embracing agile methods before jumping in. 

---

More about Matt Jamison:
Matt is an experienced solutions architect with a results-oriented understanding of the intersection between reality and architectural theory. He has the ability to plan, develop, and implement large-scale projects while maintaining impeccable attention to detail. With 20 years of functional information technology experience, Matt has end-to-end IT knowledge from layer 1 networking to application API interaction. An expert in mapping technology solutions to business needs, Matt is also able to conform to required regulations while maintaining IT best practices. Matt’s experience spans multiple industries, including healthcare, telecommunications, and security and software. He is an AWS Certified Solutions Architect. Outside of work, Matt enjoys the outdoors and all things bike-related.

More about Josh Bathon:
Josh is a creative problem solver with experience in project management and process improvement. Josh thrives in situations that challenge him to learn quickly and adapt to new environments. Leveraging his unique background in seminary formation, Josh brings emotional intelligence and self-knowledge to his interactions to build lasting, goal-oriented relationships. Josh has experience in healthcare IT, primary education administration, and non-profit service, environments in which he has developed a team-oriented leadership style geared toward high-performance outcomes. Josh holds a Bachelors in Philosophy and History from the University of Notre Dame. When he’s not working, Josh loves to read fiction and philosophy, as well as explore the cuisine and quirks of the Portland Area with his wife.