On the surface, Timken—a global manufacturer of bearings and power transmission products—might seem an unlikely exemplar of the type of fast-moving, responsive company designed to win in today’s marketplace. But Timken, launched 124 years ago to do business “wherever wheels and shafts turn,” has in recent years sought to incorporate the kind of agility and cross-functional collaboration typically found in startups and digital leaders.

For its HR organization, which is aiming to stay in step with the changing needs of the business, that has meant rethinking hierarchies, siloed teams, and systems while embracing multidisciplinary collaboration to develop, test, iterate, and implement new processes.

“No HR team working for an organization intending to grow could bypass that need for agility,” explains Nicole Morrett, Timken’s leader of talent, learning, diversity & inclusion, and engagement. “We have to pivot by month, by quarter, by year.”

To do that, Timken’s HR is taking inspiration from Agile, the project management approach that originated in the software development world.

Basic Agile terms and concepts for non-software leaders

Puzzled by sprints and scrum masters? Check out Agile 101: Terms and Concepts for Executives for definitions and illustrations in different business functions and departments.

Before joining Timken, Morrett had worked for years on formal Agile projects (for example, breaking work into short phases called “sprints” and emphasizing continuous collaboration and improvement) with IT functions, whether involving the development of HR systems or a broader enterprise software deployment. Her experience suggested that some aspects of the approach might benefit Timken’s HR team.

Let’s call the formal approach “capital A” Agile, to distinguish from the common, generic use of “agile” to characterize flexible business operations.

“Beyond the principles of capital A Agile, we were also thinking of the root of why Agile exists: the ability to innovate early and respond quickly in a fashion that manages risk,” Morrett explains. Taking a page or two from the capital A Agile approach – adapting and adopting what works best in the context of HR needs and leaving behind what doesn’t – has been a beneficial approach to introducing change while continuing to support the $4.5 billion company and its 19,000 employees. “We have to be able to move forward with risks worth taking,” says Morrett. “That requires being able to ‘work on the plane while it is in the air.’”

In recent years, more companies like Timken have been turning to the Agile methodology as a basis for better cross-functional collaboration in other parts of the enterprise.

It’s not a brand-new phenomenon. A 2016 Harvard Business Review article described how agile methodologies had begun spreading across a broad range of industries and functions; a McKinsey podcast from 2018 declared, “It’s a world of scrums, stories, epics, and timeboxed iterations.” But in 2024, Agile is being explored with new urgency because organizational agility becomes even more essential to business performance when the rate of change is high – and effective interdisciplinary coordination is critical to enabling such agility.

Research indicates that companies that enable cross-silo collaboration perform far better, but while many modern business leaders endorse this view, most businesses are still bad at it – as we examined in Why Cross-Functional Teamwork Is So Hard (and What To Do About It). But just how effective is capital A Agile, designed specifically for building software, in other venues? And to what extent can it solve the cross-collaboration challenges that plague organizations seeking greater agility, adaptability, alignment, and speed?

The short answer: for many organizations, it’s an excellent starting point for rethinking and reframing how things get done. Some Agile tactics—more clearly defining teams and roles, working iteratively in short bursts, being less prescriptive, gathering feedback early and often, and from a broader array of stakeholders—may be broadly applicable. But you can’t just cut and paste formal Agile methods and tenets and apply them to any enterprise function or process. It works better in some situations, like project-based collaboration, than others.

A better approach for many companies is “lower-case a” agile: adopting aspects that enable greater cross-functional collaboration, increased efficiency, or greater speed without the full embrace of the rigid structures of Agile. This more tailored approach can help create simpler, faster processes driven by stakeholder feedback. Looking at where Agile may work best outside of software development, and how some companies have tailored it to specific needs, can help others explore their Agile options and find inspiration for new ways of working.

How Agile jumped the wall

To better understand Agile’s influence beyond software development, it’s helpful to take a quick look at its origins. The current version of Agile traces its lineage back a couple of decades to the Agile Manifesto, which was drafted by a group of software practitioners seeking a better way to develop and deliver software. Seeing development projects consistently fail to be on time or on budget and, worse, disappoint users and customers, they argued that there must be a better approach than the linear, sequential method known as “waterfall” development.

Capital A Agile replaces the command-and-control approach of telling a team of developers what to do, how to do it, and when to do it – an approach that often led to added costs when the resulting software failed to meet end user needs or changing business conditions. The Agile methodology reduced these late-stage disappointments by bringing more people into an iterative development process much earlier. It was a novel approach to cross-functional teamwork.

Because it proved effective in software development, it became one of the first real examples of successful cross-functional collaboration for many companies. So why not take that approach and replicate it in other areas of the business seeking to create and support more interdisciplinary teaming?

Where Agile works (or doesn’t)

Most companies today have an existential drive to work in more flexible, responsive ways. Familiar with Agile’s effectiveness in transforming software development, they grab on to the capital A methodology and try to apply it to other parts of business: “HR is going agile” or “Sales is going agile.”

But when you transfer Agile from software development to other parts of a business, it may or may not work well as designed – because formal Agile methodology was created for an extremely specific context. To expect that it’s universally applicable is unrealistic.

• Agile approaches are more likely to work in:

  • Situations in which ongoing, contextual feedback from customers and stakeholders is required to make iterative changes to the work, as when a function is exploring changes to process
  • Processes involving internal stakeholders with the ability to share data
  • Circumstances in which there is no “right” or “required” way to do things; for example, a business may be looking to discover and solve for an unmet, as yet unidentified customer need
  • Tasks that can be broken down into smaller chunks of deliverables suitable for sprints, like a project-based workflow or product development
  • Environments and cultures that are supportive of iterative approaches and fast failure

• Agile approaches are less likely to work in:

  • Work consisting of repetitive, established processes, such as claims processing or surgery, that will not benefit from ongoing feedback
  • Processes involving external stakeholders with limited transparency
  • Circumstances in which there are inflexible processes or specific requirements, such as regulations, that would preclude creating a different approach
  • Tasks that cannot be reengineered into smaller sets of deliverables suitable for sprints
  • Environments and cultures that are less tolerant of iteration and failure or are more risk-averse

Despite its name, Agile is quite a regimented approach, as written. While it may be a way to go, it’s not always the way to go. Agile for Agile’s sake may have limited value in the rest of the enterprise, and blind conformity to its tenets may be detrimental. A better approach is to be more judicious about what aspects of capital A Agile make sense to achieve the outcomes that a team, function, or organization is seeking. Here are examples of Agile principles put to work in different companies and different functions.

1) Inspired by Agile: transformation at Timken HR

The tailored approach has delivered for Timken. For several years, the HR organization had sought to create a new continuous performance management process. It developed a skeleton version and made it available in a soft launch to see how users would like it. The goal was to get something out there while HR waited to get the company’s leadership on board. When all the variables lined up, HR wanted to quickly and iteratively develop a complete version, “not to move forward in a full Agile scrum style,” Morrett says, “but still applying some key principles.”

Morrett took a page from Agile by involving users and other key stakeholders, including HR managers, individual contributors, and some new hires, as her team began developing a full enterprise solution in earnest. “On Agile teams, the idea is to involve more people early, so you don’t have as much pushback,” says Morrett. However, those folks were not necessarily part of the core five-person project team. “We have those broader discussions early on, but the decision-making is still done by the five of us,” she explains.

Further, there weren’t scrums—an Agile term for small, self-organizing teams with frequent (often daily) meetings to review work and adjust course – per se. (See definitions and examples of Agile concepts such as scrums in our companion piece, Agile 101.) But there were weekly calls to build the vision of what the year-end process should look like.

Morrett wanted to avoid the issue she saw on Agile software development teams in other organizations, where the lines of demarcation for input and decision-making were less clear. “The tendency was to get very innovative with the tool in an attempt to make it the best possible based on what the users said they wanted, but oftentimes that would be in conflict with the overall goal of the project,” Morrett recalls. When the feedback became too broad, delays resulted.

That said, Morrett’s team used the reactions, responses, and questions of her user/stakeholder group to open their minds to issues they might not have considered. Regular check-ins on the users’ experience with successive iterations of the system also guided improvements. The team discovered, for example, that the system’s too-frequent auto-emails were rankling managers, so they reduced the number of messages.

The process is better for involving users and stakeholders early and often, says Morrett. “As we deploy it over the next few months, we hope that people feel managers are adopting a business solution versus an HR solution.” Morrett meets regularly with the company’s global business and HR leads to maintain what she calls “alignment, if not always agreement.”

2) Adapting Agile for sourcing and procurement at Barclays

Several years ago, British multinational bank Barclays made the transition to what it called “scrum procurement” to manage its multibillion dollar purchasing budget with the help of Agile ideas.

Barclays divided its 150-person procurement team into 18 sourcing pods – similar to Agile scrum teams – each of which comprised a mix of seniorities, procurement expertise, and diverse skills. Phil Thomas, managing director and group head of global sourcing at Barclays, explained to a Chartered Institute of Procurement and Supply (CIPS) publication that while he didn’t intend on a full Agile transformation, the approach did incorporate some Agile practices such as scrums and huddles.

Each pod has four or five specialists working collaboratively to deliver the full lifecycle of sourcing activities for a specific product or service category, but it’s available to take on other category sourcing if necessary to balance workloads. The pods can work on several projects at a time, with specialists owning different parts of the process.

“Normally someone would work on a deal [from] start to finish,” Thomas says. “Now we work in a portfolio [approach] and use process analysts, sourcing managers, and contract experts.”

Performance is measured by pod rather than individual, which further encourages collaboration.

The end results, Barclays reports, include:

• Reduced sourcing cycle time
• Higher sourcing throughput
• Improved collaboration
• Better project control
• More flexibility

In many industries, corporate procurement is a function that is both ripe for improvement and, at the same time, resistant to Agile concepts in unique ways.

“The sourcing process is, by definition, really cross-functional with a lot of back and forth,” says Amy Fong, a partner leading Everest Group’s sourcing and vendor management practice. “Collaboration is always a challenge for procurement, getting everyone involved early enough and then waiting for one group to respond to another.”

Speeding up that lengthy process is a key goal, she notes. “Sourcing can typically take three months up to a year, and that’s just not acceptable to stakeholders these days,” Fong says.

Many companies are attempting to make processes both simpler and less linear. That can be tricky with procurement. Sometimes there’s a good reason for the time built into the process, giving suppliers adequate time to deliver the best products or services. As Fong explains, “You’ll never get the process down to five days, but there are parts you can do in parallel.”

Because procurement involves external-facing processes, it’s not a perfect fit for Agile techniques, Fong says. “There are parts of the process that require more back and forth by intention because you’re dealing with multiple suppliers, and certain information should not be shared. It’s definitely not as transparent as, for example, an internal DevOps group would be.”

Nonetheless, as Barclays’ results demonstrate, procurement functions can uncover ways to make parts of their processes more efficient. In some cases, Fong has seen procurement organizations apply Agile roles to their existing processes. The chief procurement officer can serve as the Agile coach, leading the process of agile transformation, transitioning teams to an agile working environment, and designing and improving agile methods through coaching and facilitation. A sourcing or category manager can serve as a quasi-scrum master, tracking the overall progress of project, removing barriers, and mitigating delays.

3) Unilever’s enterprise-wide Agile ambition

Some companies have taken the ambitious approach of adapting agile tenets and approaches enterprise-wide. Unilever is a leading example.

“For years, I thought Agile was only relevant for tech startups,” Nitin Paranjpe, Unilever’s chief people and transformation officer, said in a Boston Consulting Group (BCG) article. “But when I took a closer look, the penny dropped for me. The things that Agile solves for are actually the problems of large companies.”

The $65.1 billion consumer products giant had used Agile development and project management approaches on hundreds of individual projects, crediting Agile with its ability to get a new hand sanitizer from idea to market in the United States (where it had none) in early 2020. But its enterprise-inspired-by-Agile approach looks a little different. It focuses less on implementing scrums and more on increasing customer focus, clarifying priorities, and empowering teams.

As explained by BCG, Unilever took a four-pillar approach to its agile transformation.

First, it began using objectives and key results (OKRs) to clarify its highest-level priorities across its 400 brands. Its business groups set the majority of the OKRs, which then become priorities for business and regional units and guide teams’ day-to-day work. For example, a business group may establish an OKR to double the market share for a certain product portfolio, which is then translated at different levels throughout the business; in one scenario, the EU regional team may have its own target to meet to contribute to the overall OKR.

Second, the company implemented quarterly business reviews to ensure adherence to the OKR approach and track progress.

Third, the company began grouping employees into multidisciplinary teams focused on specific OKRs with help from its existing Agile coaches. The company estimates that a third of office-based employees will work on Agile teams, according to the BCG article.

Fourth, the company integrated enterprise-level Agile coaches at the business unit and functional levels to help guide its leaders through the transition.

Unilever describes results as “promising,” though it’s too early to provide hard measurements.

A fit-for-purpose approach

Capital A Agile can be a good starting point when lower-case an agile is the goal. It offers a framework to check a function or team’s assumptions to determine whether the way they’ve always done things is actually the best way. The exercise of exploring what aspect of Agile may be transferable outside of software development can help organizations break down their projects or processes in new ways, work more cross-functionally and collaboratively across the business, seek more feedback earlier on, and move through project phases and iterations more quickly.

Ultimately, they may be able to work in more agile ways, even if not on formal Agile teams.

Read more