agile innovation case study

• Agile Education Program
• The Agile Navigator

Agile Unleashed at Scale

How john deere’s global it group implemented a holistic transformation powered by scrum@scale, scrum, devops, and a modernized technology stack, agile unleashed at scale: results at a glance, executive summary.

In 2019 John Deere’s Global IT group launched an Agile transformation with the simple but ambitious goal of improving speed to outcomes.

As with most Fortune 100 companies, Agile methodologies and practices were not new to John Deere’s Global IT group, but senior leadership wasn’t seeing the results they desired. “We had used other scaled frameworks in the past—which are perfectly strong Agile processes,” explains Josh Edgin,  Transformation Lead at John Deere, “But with PSI planning and two-month release cycles, I think you can get comfortable transforming into a mini-waterfall.” Edgin adds, “We needed to evolve.”

Senior leadership decided to launch a holistic transformation that would touch every aspect of the group’s work – from application development to core infrastructure; from customer and dealer-facing products to operations-oriented design, manufacturing and supply chain, and internal/back-end finance and human resource products.

Picking the right Agile framework is one of the most important decisions an organization can make. This is especially true when effective scaling is a core component of the overall strategy. “Leadership found the Scrum@Scale methodology to be the right fit to scale across IT and the rest of the business,” states Ganesh Jayaram, John Deere’s Vice President of Global IT. Therefore, the Scrum and Scrum@Scale frameworks, entwined with DevOps and technical upskilling became the core components of the group’s new Agile Operating Model (AOM).

Picking the right Agile consulting, training, and coaching support can be just as important as the choice of framework. Scrum Inc. is known for its expertise, deep experience, and long track record of success in both training and large and complex transformations. Additionally, Scrum Inc. offered industry-leading on-demand courses to accelerate the implementation, and a proven path to create self-sustaining Agile organizations able to successfully run their own Agile journey.

“I remember standing in front of our CEO and the Board of Directors to make this pitch,” says Jayaram, “because it was the single largest investment Global IT has made in terms of capital and expense.” But the payoff, he adds, would be significant. “We bet the farm so to speak. We promised we would do more, do it faster, and do it cheaper.”

John Deere’s CEO gave the transformation a green light.

Just two years into the effort it is a bet that has paid off.

Metrics and Results

Enterprise-level results include:

• Return on Investment: John Deere estimates its ROI from the Global IT group’s transformation to be greater than 100 percent .
• Output: Has increased by 165 percent , exceeding the initial goal of 125 percent.
• Time to Market: Has been reduced by 63 percent — leadership initially sought a 40 percent reduction.
• Engineering Ratio: When looking at the complete organizational structure of Scrum Masters, Product Owners, Agile Coaches, Engineering Managers, UX Professionals, and team members, leadership set a target of 75% with “fingers on keyboards” delivering value through engineering. This ratio now stands at 77.7 percent .
• Cost Efficiency: Leadership wanted to reduce the labor costs of the group by 20 percent . They have achieved this goal through insourcing and strategic hiring–even with the addition of Scrum and Agile roles.
• Employee NPS (eNPS): Employee Net Promoter Score, or eNPS, is a reflection of team health. The Global IT group began with a 42-point baseline. A score above 50 is considered excellent. The group now has a score of 65 , greater than the 20-point improvement targeted by leadership.

John Deere’s Global IT group has seen function/team level improvements that far exceed these results. Order Management, the pilot project for this implementation has seen team results which include:

• The number of Functions/Features Delivered per Sprint has increased by more than 10X
• The number of Deploys has improved by more than 15X

As Jayaram notes, “When you look at some of the metrics and you see a 1,000 percent improvement you can’t help but think they got the baseline wrong.”

But the baselines are right. The improvement is real.

John Deere’s Global IT group has also seen exponential results thanks to the implementation of the AOM. “We’ve delivered an order of magnitude more value and bottom-line impact to John Deere in the ERP space than in any previous year,” states Edgin. These results include:

• Time to Market: Reduced by 87 percent
• Deploys: Increased by 400 percent
• Features/Functions Delivered per Sprint: Has nearly tripled

Edgin adds that “every quality measure has improved measurably. We’re delivering things at speeds previously not thought possible. And we’re doing it with fewer people.”

Training at Scale and Creating a Self-Sufficient Agile Organization

The Wave/Phase approach has ensured both effective and efficient training across John Deere’s Global IT group. As of December 2021, roughly 24-months after its inception:

• 295 teams have successfully completed a full wave of training
• Approximately 2,500 individuals have successfully completed their training
• 50 teams were actively in wave training
• Approximately 150 teams were actively preparing to enter a wave

John Deere’s Global IT group is well on its way to becoming a self-sustaining Agile organization thanks to its work with Scrum Inc.

• Internal training capacity increased by 64 percent over a two-year span
• The number of classes led by internal trainers doubled (from 25 to 50) between 2020 and 2021

Click on the Section Titles Below to Read this I n-Depth  Case Study

1. introduction: the complex challenge to overcome.

This need can be unlocking innovation, overcoming a complex challenge, more efficient and effective prioritization, removing roadblocks, or the desire to delight customers through innovation and value delivery.

Ganesh Jayaram is John Deere’s Vice President of Global IT. He summarizes the overarching need behind this Agile transformation down to a simple but powerful four-word vision; improve speed to outcomes.

Note this is not going fast just for the sake of going fast – that can be a recipe for unhappy customers and decreased quality. Very much the opposite of Agile.

Dissect Jayaram’s vision, and you’ll find elements at the heart of Agile itself; rapid iteration, innovation, quality, value delivery, and most importantly, delighted customers. Had John Deere lost sight of these elements? Absolutely not.

As Jayaram explains, “we intended to significantly improve on delivering these outcomes.” To do this, Jayaram and his leadership team decomposed their vision of ‘improve speed to outcomes’ into three enterprise-level goals:

• Speed to Understanding: How would they know they are truly sensitive to what their customers – both internal and external – care about, want, and need?
• Speed to Decision Making: Decrease decision latency to improve the ability to capitalize on opportunities, respond to market changes, or pivot based on rapid feedback.
• Speed to Execution: Decrease time to market while maintaining or improving quality and value delivery.

Deere’s Global IT leadership knew achieving their vision and these goals would take more than incremental adjustments. Beneficial change at this level requires a holistic transformation that spans the IT group as well as the business partners.

They needed the right Agile transformation support, the ability to efficiently and effectively scale both training and operations and to build the in-house expertise to make the group’s Agile journey a self-sustaining one. As Josh Edgin, Global IT Transformation Lead at John Deere states, “We needed to evolve.”

2. Background: The Transformation's Ambitious Goals

Before this transformation, John Deere’s Global IT function operated like that of many large organizations. In broad terms, this meant that:

• The department had isolated pockets of Agile teams that implemented several different Agile frameworks in an ad hoc way
• Teams were often assigned to projects which were funded for a fixed period of time
• The exact work to be done on projects was dictated by extensive business analysis and similar plans
• Outsourcing of projects or components to third-party suppliers was commonplace
• The manager role was largely comprised of primarily directing and prioritizing work for their teams

At John Deere, process maturity was very high. Practices such as these were created in the Second Industrial Revolution and they can deliver value, especially if you have a defined, repeatable process. However, if you have a product or service that needs to evolve to meet changing market demands, these legacy leadership practices can quickly become liabilities.

• Pockets of Agile can deliver better results. But isolated Agile teams will inherently be dependent on non-Agile teams to deliver value. This limits the effectiveness and productivity gains of Agile teams specifically and the organization as a whole. The ad hoc use of different Agile frameworks, as Vice President Jayaram explains, compounds this problem by “not being something we could replicate and scale across the organization.”
• Project-oriented teams are often incentivized to deliver only what the project plan calls for – this inhibits a customer-centric mindset and the incorporation of feedback.
• Expecting teams to always stick to a predetermined plan limits their ability to innovate, creatively problem solve, or pivot to respond to changing requirements or market conditions.
• Outsourcing can create flexibility for organizations, but an over-reliance on outsourcing can slow speed to market and value delivery.
• Too many handoffs deliver little if any value. These can also significantly slow progress on any project or product which increases time to market.
• IT managers that are primarily delegators can become a form of overhead since they’re not actively producing value for customers. Their other skills can atrophy leaving them ill-equipped to help develop their team members, and overall team member engagement and talent retention can suffer.

2.1 The Transformation Goal

Improving speed to outcomes required greater employee engagement, decreased time to market, higher productivity, better prioritization, and alignment, and increase the engineering  ratio – the percentage of the organization with what Jayaram and Edgin call “fingers on keyboards” who create the products customers used.

Additionally, leadership wanted to increase the group’s in-house technical expertise, modernize its technology stack, unify around a single Agile framework that easily and efficiently scaled both across IT and the rest of the business, and reorganize its products and portfolios around Agile value streams. All while meeting or exceeding current quality standards.

Leadership wanted to go big. They wanted nothing less than a holistic Agile transformation that would improve every aspect of their business and all of the group’s 500 teams.

Next, senior leadership created the group-wide metrics they would use to measure success. These included:

• Output: Increase by 125 percent
• Time to Market: Reduce by 40 percent
• Engineering Ratio: Improve to 75 percent with “fingers on keyboards”
• Employee NPS (eNPS): 20-point improvement
• Cost Efficiency: They would reduce labor costs by 20 percent

At the time, these goals seemed ambitious to say the least. “I remember standing in front of our CEO and the Board of Directors to make this pitch,” says Jayaram, “because it was the single largest investment Global IT has made in terms of capital and expense.” But the payoff, he adds, would be significant. “We bet the farm so to speak. We promised we would do more, do it faster, and do it cheaper.”

John Deere’s CEO gave the transformation, called the Agile Operating Model (AOM), a green light.

3. Agile Operating Model: Why John Deere Chose Scrum And Scrum@Scale

Picking the right Agile framework is one of the most important decisions an organization can make. This is especially true when effective scaling is a core component of the overall strategy.

As Edgin explains, Agile was not new to John Deere’s Global IT group. “We had Agile practices. We had Agile teams. We were delivering value.”

But says Edgin, they weren’t satisfied with the results. So, a team began evaluating several different Agile methodologies. They examined what had been done at John Deere in the past and anticipated what the group’s future needs would be.

In the past, Edgin states, “We had used other scaled frameworks—which are perfectly strong Agile processes. But with PSI planning and two-month release cycles, I think you can get comfortable transforming into a mini-waterfall,” he says, “So we aligned on Scrum being the best fit for our culture and what we wanted to accomplish.”

Early on, leadership decided to implement a tight partnership where the IT delivery team(s) are closely coupled with the product organization that is the voice of the customer. When connecting multiple products together, “leadership found the Scrum@Scale methodology to be the best fit to scale across IT and the rest of the business,” says Jayaram.

The Scrum and Scrum@Scale frameworks, entwined with DevOps and technical upskilling, became integral Agile components of the group’s new AOM.

4. The Foundry: More Than A Training Facility

When it came time to name the final and arguably most important component of the AOM, the Foundry was a clear choice. It recognizes the company’s proud heritage while also symbolizing the change that would drive the Global IT group into the future.

Many organizations incorporate a “learning dojo model” when implementing an Agile transformation. These dojos and their teams are often home to Agile practices, conduct training sessions, and provide immersive coaching for newly launched Agile teams.

Training is, of course, a critical piece of any transformation. As is coaching. After all, switching from a traditional command and control approach to an Agile servant leader approach is a significant, sometimes disorienting change.

However, some corporate dojos work on what could be considered a “catch and release” strategy. They provide one or two weeks of baseline Agile training to individuals and teams, then say “get to it”. Coaching is limited and provided primarily by outside consultants.

The first problem with “catch and release” dojos is the cookie-cutter-like approach. A mass “baseline only” training strategy focus on volume — not understanding and usability.

The second problem is the over-reliance on outside consultants for team and organizational coaching. The cost-prohibited nature of outside consultants can limit the levels of coaching each team receives. This approach also equates to an organization outsourcing its Agile knowledge base and thought leadership — a critical competency in modern business.

The John Deere Foundry and Deere’s approach to embedding Agile Coaches and Scrum Masters across the organization represents the evolution of the dojo model by addressing these problems head-on.

4.1 A Relationship Built on Creating a Self-Sustaining Agile Organization

From the beginning, John Deere’s relationship with Scrum Inc. was built around creating a self-sustaining Agile organization. One where the Foundry’s own internal trainers and coaches would build all the capabilities they needed to ensure the Global IT group’s Agile transformation was a self-sustaining one.

This included not just materials needed to train new Agile teams. This relationship included sharing all the knowledge, skills, expertise, content, and tactics critical to training the coaches and trainers themselves.

The Foundry was launched by a dedicated team comprised of both John Deere’s internal trainers and coaches and their Scrum Inc. counterparts. They worked from a single backlog which prioritized knowledge sharing along with the “hands-on” work of training John Deere’s Global IT teams in Scrum.

Scrum Inc.’s consultants took leading roles during the first wave of training, while their John Deere counterparts observed and learned the content and techniques. By the third wave, John Deere’s internal trainers and coaches were taking the lead, with Scrum Inc.’s consultants there to advise and refine the program.

As time passed, a significant number of trainers and coaches inside the Foundry and across the organization showed the level of mastery needed to successfully pass Scrum Inc.’s intensive Registered Scrum Trainer and Registered Agile Coach courses. They could now credential their own students. More importantly, they demonstrated the ability to drive the Global IT group’s Agile transformation forward on their own.

This approach removes any reliance on outside contractors for key competencies.

4.2 Unified, Context-Specific Training

Implementing an Agile transformation is a complex challenge. Research continues to show that ineffective or insufficient levels of training and coaching are leading causes of failed implementations. So too are misalignment, misunderstandings, or outright misuse of the concepts and terminology important to any Agile framework.

In short, everyone needs to share a unified understanding of the new way of working for it to have any chance of working at all.

The best way to overcome the problem of a cookie-cutter approach is to ensure all training content is as context-specific as possible.

Here too the connection between the Foundry and Scrum Inc. was important.

The joint team of John Deere and Scrum Inc. staff swarmed to create Agile courses packed with customized, context-specific material that would resonate with the company’s Global IT group.

This content removed any feeling of a cookie-cutter approach and increased the usability of each lesson.

4.3 Results 

• Internal training capacity increased  by 64 percent over a two-year span
• John Deere trainers are now leading customized, context-specific courses including Scrum Master , Product Owner , Engineering Manager , Agile for Leaders , Scrum@Scale Practitioner , and Scrum@Scale Foundations

Perhaps the best measure of success is the waiting list of teams wanting to go through Agile training and coaching. Initially, hesitancy over implementing the Agile Operating Model and undergoing training was high. Initially, there wasn’t a high demand for the training, however as early adopters experienced success, demand for the training grew. Soon teams were actively seeking admission to the next planned cohort. Now, even with greatly expanded capacity, there is a waiting list.

The Foundry model has been so successful that John Deere’s Global IT group has expanded its footprint to include coaching in Mexico, Germany, and Brazil and launched a full-scale Foundry program at the company’s facility in India. In addition to the Foundry, embedded Agile coaches continuing to drive transformation locally are a key component to the model’s success.

5. How To Achieve Efficient and Effective Training at Scale

Enter the Wave/Phase training approach implemented by the Foundry with Scrum Inc.

In this model, each team includes IT engineers along with their Scrum Masters and business-focused Product Owners. A training cohort, usually comprised of 40 to 50 teams, constitutes a wave.

The waves themselves are comprised of three distinct phases:

• The Pre-Phase: Where teams and locally embedded agile coaches prepare for an immersive wave coaching experience
• The Preparation Phase: Focuses on product organization and customer journeys
• The Immersion Phase: Team launch, coaching, and full immersion into the AOM

All three phases are designed to run concurrently, which keeps the pipeline full, flowing, and ensures efficient training at scale. The transformation doesn’t end with the wave experience. Continuous improvement and ongoing transformation continue well beyond the Immersion Phase, led by embedded agile leaders in partnership with The Foundry.

The quality and context-specific nature of the training itself, along with the “left-seat-right-seat” nature of the coaching, ensures the learning is effective.

5.1 The Pre-Phase

Embedded Agile coaches are continuously transforming teams in their organizations even before they enter a wave. One goal of the Pre-Phase is to ensure readiness of teams looking to enter a wave. Acceptance criteria include:

• Proper organization design review to ensure teams are set up to succeed with the correct roles
• A draft plan for their product structure (explained in more detail in section 6 of this case study)
• The Scrum Roles of Product Owner, Engineering Manager, and Scrum Master are filled

Ryan Trotter is a principal Agile coach with more than 25 years of experience in various capacities at John Deere. Trotter says experience shows that not meeting one or more criteria “causes deeper conversations and could result in some mitigations or delaying until they’re ready.”

5.2 The Preparation Phase

The benefits of an Agile mindset and processes can be significantly limited by legacy structures.

Therefore, product organization is the primary focus of the preparation phase.

“We want to create a much stronger connection between the customer, and the Product Owner and team” explains Heidi Bernhardt who has been a senior leader of the Agile Operating Model since its inception. Bernhardt has been with John Deere for more than two decades now. She says individuals in the product and portfolio side of the house learn to “think in a different way.”

Participants in the preparation phase learn how to create customer journey maps and conduct real-world customer interviews to ensure their feedback loops are both informative and rapid — key drivers of success for any Scrum team and organization explains Bernhardt, “They’re talking with the customer every Sprint, asking what their needs are and what they anticipate in the future.”

They also learn how to manage and prioritize backlogs and how to do long-term planning in an Agile way.

Scrum Role training is a critical component of the preparation phase. Product Owners and Scrum Masters attend both Registered Scrum Master and Registered Product Owner courses.

Team members and others who interact regularly with the team take Scrum Startup for Teams , a digital, on-demand learning course offered by Scrum Inc. “Scrum Startup for Teams provides a really good base level of understanding,” says Ryan Trotter, “People can take it at their own pace and they can go back and review it whenever they want. It really hit a sweet spot for our software engineers.”

By the end of 2021 Scrum Startup for Teams had helped train roughly 2,500 people in the Global IT group and nearly the same number of individuals throughout the rest of John Deere — including those who aren’t on Scrum Teams but who work closely with them.

5.3 The Immersion Phase

The 10-week long immersion phase is where the Agile mindset and the AOM take flight. Where the Scrum and Scrum@Scale frameworks are fully implemented and the teams turn the concepts they’ve learned in the prior phases into their new way of working.

For John Deere’s Global IT group, immersion is not a theoretical exercise. It is not downtime. It is on-the-job training in a new way of working that meets each team at their current maturity level.

The first week of immersion is the only time teams aren’t dedicated to their usual duties.

During this time, says Trotter, coaches and trainers are reinforcing concepts, answering questions, and the teams are working through a team canvas. “This is where the team members identify their purpose, their product, and agree on how they’ll work together.”

Teams are fully focused on delivering value and their real-world product over the next nine weeks.

The Product Owner sets the team’s priorities, refines the backlog, and shares the customer feedback they’ve gathered. The Scrum Master helps the team continuously improve and remove or make impediments visible. Scrum Masters collaborates with an embedded Agile Coach that continues to champion transformation. Team members are delivering value. John Deere’s technical coach for the team is the Engineering Manager, a role that has transformed from the original team leader.

Those in the immersion phase receive intensive coaching, but they are also empowered to innovate or creatively problem solve on their own. The goal is for the coaches to help make agility and learning through experimentation a part of each team’s DNA.

The transition from students to practitioners becomes more apparent towards the end of immersion. Coaches take more of a back seat in the process explains Trotter. “We don’t want to create a false dependency. We want the teams to take ownership of their own Agile journey, to know the Foundry is here when needed but to be confident that they’ve got this and can run with it so they can continuously improve on their own.”

5.4 Measuring Wave Training Effectiveness

Measuring the effectiveness of any large-scale Agile training program requires more than just counting the number of completed courses or credentials received. The instructors and coaches must be able to see the Agile mindset has also taken hold and the implementation is making a positive impact on the organization. They also need the ability to see where problems are arising so they can provide additional coaching, training, and other resources where needed.

John Deere’s internal coaches created their Ten Immersion Principles (TIPS) as a way of measuring team health once they leave the immersion phase. Foundry coaches and trainers can then focus their efforts to create a continuous learning backlog that the team owns.

The TIPS are:

• Value Flows Through the System Super Fast: The team can deliver new products or features to customers very quickly. Any impediments or dependencies hindering delivery are quickly identified and addressed
• Amplify Feedback Loops: Rapid feedback from customers is a reality
• Continuous Learning Organization: The team is taking ownership of their learning paths and Agile journey
• Deliver Value in Small Increments: The team delivers value to customers in small pieces in order to gather feedback, test hypotheses, and pivot if needed
• Customer Centricity: The team is focused on those actually using the product and not just the stakeholders interested in the value the product should deliver
• Continuous Improvement: The team is always looking for ways to improve product and process
• Big and Visible: The team make progress, impediments, and all needed information transparent and easy to find
• Team is Predictable: The team tracks productivity metrics and estimates backlog items so that the anticipated date of delivery for products or features can be known
• Data-Driven Decisions: Feedback and real data, not the loudest voice or squeaky wheel — is used to make decisions
• Culture of Experimentation: The team is willing to take calculated risks and are able to learn from failure

5.5 Results

The positive business impact this training has had is outlined in section 8. Metrics and Results of this case study.

6. Agile Product and Portfolio Management: Why It's Important And How To Do It

Erin Wyffels keeps an old whiteboard in her office as a reminder of the moment she and her team solved a particularly complex problem.

Wyffels leads the product excellence area of the Foundry, supporting John Deere’s product leaders in product ownership and the dynamic portfolio process. She has a long history with traditional project management, inside and outside of IT. Over the past two years, she has grown her expertise in Agile product and portfolio management.

John Deere’s Global IT group manages a catalog of more than 400 digital products across 500 teams. These support every business capability in the broader company — from finance and marketing to manufacturing and infrastructure and operations.

Most large organizations are built on legacy systems. Left unchanged, these systems can limit the effectiveness of an Agile transformation. Wyffels says the prior structure of projects and portfolios within John Deere’s Global IT group was just such a system. “Our old taxonomy would in no way work with Agile.” So, she was picked to help change it for the better.

6.1 Why the Product and Portfolio Structure Needed to Change 

Before implementing the AOM, portfolio management was an annual affair. One that Wyffels says, “left everyone unhappy.”

Stakeholders and senior leadership would come with a list of desired projects. Financial analysts, IT department managers, and portfolio managers would then hash out funding for these projects. Teams would then be assigned to the resourced projects. All pretty standard stuff in the corporate world.

There are, however, several problems with this approach.

Take the focus on projects. Traditional project management is a very effective approach for defined processes. By definition, a project has a start date and an end date. A set amount of work is to be done at a predetermined cost.

The weakness in traditional project management becomes apparent when you have a product or service that will evolve and emerge over time. There are just too many unknowns for the traditional approach to work effectively.

Then there’s the time it takes to make decisions based on customer feedback. As Wyffels points out, the annual nature of the pre-AOM process meant, “The best information and data you could get would be a quarter old.” Agility requires far more rapid feedback loops.

Throw in a taxonomy built more around project type than the value delivered and employees who were moved to projects instead of allowed to own a product end-to-end, and John Deere’s Global IT group had a system that was optimized based on constraints but didn’t support where the company was headed next. They were ready for a system that promoted total product ownership including value, investment, and quality and move to the next level of product maturity.

6.2 Customer Perspective and Value Streams

The need to adopt Agile product and portfolio management processes became apparent early in the AOM’s implementation.

Amy Willard is a Group Engineering Manager currently leading the AOM Foundry. She says this also becomes apparent for individual teams taking part in the immersion phase of wave training. “We see changes in their product structure evolving. They have that aha moment and realize the structure we had before wasn’t quite right.”

The new, Agile structure focuses on three critical components — customer perspective, value streams, and a product mindset.

• Customer Perspective: Willard says the value delivered to customer personas is now used to more logically group products and product families. This Agile taxonomy helps to reduce time to market and boost innovation by fostering greater coordination and collaboration between teams.
• Value Streams: Dependencies, handoffs, and removing bottlenecks are also considered when creating product groups and portfolios. Willard notes, “We’ve had a lot of success with developing value stream maps across products,” also from a customer journey perspective.
• Product Mindset: Projects are defined by their scope, cost, and duration. Products are different, they evolve based on market feedback to continually deliver value to customers.  The difference may sound small, but Willard says it represents a “major shift” in mindset for the Global IT group.

The group has developed a curriculum for people in product roles in each transformation wave, with coaching support available to each person. The same content has been made available for all roles through a self-learning option, which is great for non-product roles or people that take a new position after their group’s wave is complete. Additionally, the communities being established for product roles and collaboration across people in the roles are the final building blocks to continued maturity after the transformation waves are done.

6.3 Highlighted Result: Better Value-Based Investments

The implementation of Agile product and portfolio management has yielded numerous positive results for John Deere’s Global IT group. These structural changes were critical drivers of the success noted in the Metrics and Results section of this case study.

This shift has also increased the ability of the group’s senior leadership to act like venture capitalists and invest resources into areas and products with the most potential value to both the organization and customers.

All products are now segmented into one of three categories based on actual value delivery and market feedback. These categories are:

• Grow: High-value products or opportunities worth a higher level of investment
• Sustain: Products we want to continue investing in, but not to differentiate
• Monitor: The capability is required to run a successful business, but the investment level may be reduced

There are some products that may have problems that need to be addressed immediately, or the investment levels are decreasing in certain areas of the product due to rationalization efforts.  Those products are flagged with Fix or Exit so the MetaScrum can have prioritization conversations more easily.

The heightened levels of business intelligence and customer feedback the AOM has fostered allow leadership to make better decisions about investments faster. It also reduces the cost of pivoting when market conditions change.

Strong products, as well as prioritization and alignment at every level of the organization are what will make the portfolio process most effective at John Deere.

7. Agile Culture Unleashed

In-depth:  .

John Deere has a long history of finding innovative solutions to common problems. Today, they’re still focused on driving customer efficiency, productivity, and value in sustainable ways.

As the company states , “We run so life can leap forward.”

That alone is enough to make the company iconic. For John Deere, that’s just the start.

People matter at John Deere. So too do concepts like purpose, autonomy, and mastery made famous by author Daniel Pink in his book Drive . “It’s no secret that there is a war for talent right now,” acknowledges Global IT Transformation Lead Josh Edgin, “and the market is only getting more competitive.” John Deere’s Global IT group is not immune to that competition. However, it has an advantage over other organizations — a thriving Agile culture.

Psychological safety, empowerment, risk-taking, are the foundations of the AOM.  At John Deere’s Global IT group,being Agile isn’t defined by holding Scrum events, it’s about implementing Scrum the way it was intended by Scrum co-creator Jeff Sutherland.

Work-life balance is important. The environment is one of collaboration and respect. The group also has a common sense based remote work policy and a number of hubs for when collocation is imperative.

All this doesn’t mean everything is perfect at John Deere’s Global IT group. Leadership is the first to tell you they can and will do even better. This itself is a powerful statement — this is a place where continuous improvement is everyone’s goal, not something management demands of delivery teams.

“We’re a company that is walking the talk,” says Global IT Vice President Ganesh Jayaram, “We’re making investments both in terms of our team members and technology.” Here are just three of the important ways John Deere’s Global IT group is indeed “walking the talk.”

7.1 Transformation Portal 

Big and visible. That is the goal of the group’s transformation portal. Everything relating to the AOM implementation can be found here.

Resources, wave schedules, thought leadership, and shared learnings are all available in this in-depth dashboard. Far more than you often see in other organizations. So too are metrics for individual teams and the group as a whole.

“People want purpose,” says Edgin, “they want to solve hard problems. They want to know the work they do matters.”  This portal allows individuals to better understand their roles and they work together.

7.2 Agile Career Paths

Log into John Deere’s AOM transformation portal and you’ll find a section with dedicated self-learning and career advancement paths. As Amy Willard explains, “We have a path for every persona and community led CoPs, supported by the Foundry.” This includes everything from User Experience Practitioner to Scrum Master and Product Owner.

Having clearly defined career paths and self-learning opportunities is an important step. It not only empowers continuous improvement, but it also shows professional agilists that they’re valued, their skills are important, and they have a bright future at the organization which does not dictate they must choose between agility and career advancement.

7.3 Prioritizing Team and Organizational eNPS Scores

Through the AOM John Deere was focused on creating a great place to work. Leadership believed that healthy teams would drive creativity, productivity, and sustainability.

John Deere’s Global IT group regularly measures this through both team and organizational Employee Net Promoter Scores, or eNPS. By asking employees if they would recommend their team to others, leaders can gain a better understanding of the health and engagement of the team.

Edgin explains the importance of these metrics this way, “When you create a culture where you have awesome employees with the right mindset and great technical skills you want them to stay here because this is where they want to be.”

The Global IT group began with a 42-point baseline. A score above 50 is considered excellent. The group now has a score of 65, greater than the 20-point improvement targeted by leadership.

Individual teams show similar results across the board.

8. Metrics and Results

Truly successful Agile transformations don’t have a finish line. That’s why they call it a journey of continuous improvement.

Still, just two years into this implementation, John Deere’s Global IT group is clearly well down that path. The results are as indisputable as they are impressive.

“When you look at a product area and you see a 1,000 percent improvement can’t help but think they got the baseline wrong,” says Global IT Vice President Ganesh Jayaram.

But, digging deeper, the improvement is real.

Take the productivity gains seen from the teams with Order Management. Jayaram says these teams were chosen for the AOM’s pilot project because it was “the most complicated, had the most dependencies, and had tentacles throughout the organization.” He believed that if Scrum, Scrum@Scale, and the AOM worked for Order Management, other teams couldn’t question if it would work for them.

Metrics show just how successful the pilot was.

Both results are exponentially greater than the 125 percent increase target set for the transformation. While the Order Management results are leading the way, results from other business capability areas inside the Global IT group are closely following.

Take the ERP-heavy environment of Manufacturing Operations. Here, Edgin notes, thanks to the Agile transformation and the modernization of the technology stack, “this year we’ve delivered an order of magnitude more value and bottom-line impact to John Deere in the ERP space than in any previous year.”

He adds that “Every quality measure has improved. We’re delivering things at speeds previously not thought possible. And we’re doing it with fewer people.” Other Manufacturing Operations results include:

• Deploys: increased by 400 percent
• Features/Functions Delivered per Sprint:  Has nearly tripled

8.1 Global IT Group Overall Results

Across the board, Deere’s Global IT Agile transformation has met or exceeded every initial goal set by senior leadership. Even when you combine results from both more mature teams and those that have just left the Foundry.

The targets that leadership set were to be reached within six months after completing immersion, but John Deere is seeing continued progress led by the business capability areas to achieve even higher results with the ongoing guidance of embedded change leaders such as Scrum Masters and business capability Agile coaches.

• Time to Market: Has been reduced by 63 percent — leadership initially sought a 40 percent reduction.
• Cost Efficiency: Leadership wanted to reduce the labor costs of the group by 20 percent . They have achieved this goal through insourcing and strategic hiring–even with the addition of Scrum and Agile roles.

8.2 Return on Investment and Impact on the Bottom Line

Agile transformations are an investment, in people, culture, productivity, innovation, and value delivery. Like any investment, transformations must deliver a positive return to be judged a success.

Deere’s ROI on the Global IT group’s transformation is estimated to be greater than 100 percent.

Successful Agile transformations also make a material impact on their company’s bottom line. Financially, 2021 was a banner year for John Deere. The company generated nearly $6 billion in annual net income — far more than its previous record.  So, it takes a lot to materially impact the company’s bottom line.

Both Global IT Transformation Lead Josh Edgin and Global IT Vice President Ganesh Jayaram believe the AOM has indeed helped move the financial needle at Deere.

“The metrics we track show very clearly the answer is yes,” says Jayaram.

Edgin states, “We’re helping the company achieve our smart industrial aspirations by improving how we serve our customers and boosting productivity.” He adds that the AOM allows the group to “innovate and deliver high quality, secure solutions at a much faster pace to meet and exceed our customer needs.”

9. Agile in Action: Supply Chain Solutions Amid Disruptions

A global leader with more than 25 brands,  John Deere  relies on a complex supply chain and efficient logistics to ensure production and delivery go as planned.

More than 10,000 parts are needed to assemble just one of John Deere’s  award-winning X9 combines  — twice the number of components needed to build a new car.

Modern combines, just like modern farming, also require far more technology than you likely think.

Sensors, antennas, and motherboards are now just as critical as tires, treads, and tines. Of course, John Deere makes far more than combines. Its iconic logo appears on everything from tillers and tractors to marine engines, motor graders, and the John Deere Gator utility vehicle. In all, the company manufactures more than 100 distinct lines of equipment.

Each product relies on efficient and effective supply chain management — from procurement and sourcing to cost control, shipping, customs, and final delivery.

Overall, John Deere depends on a complex network of thousands of suppliers from around the globe to build industry-leading John Deere products.

Coordinating and collaborating with that network through digital solutions largely falls to the company’s Supply Chain Solutions teams and Karen Powers, the Digital Product Manager for Supply Chain Management and Worldwide Logistics at John Deere.

“We have responsibility for every shipment around the world,” she explains, “ from any supplier to any factory, to any component operation in between, and for the end shipment of the completed good to the dealer.” To accomplish all of this, Powers’ team also works with aspects of the company’s global trade including imports, exports, customs, documentation, and duties.

It’s a mammoth undertaking even in the best of times. And 2020 and 2021 were hardly the best of times.

But John Deere’s Supply Chain Solutions teams were more than up to the task. They successfully used Scrum as a team framework to increase throughput and Scrum@Scale as an organizational framework to optimize alignment and value delivery. Together they helped Supply Chain Solutions navigate the challenges caused by a global pandemic and major supply chain disruptions.

John Deere didn’t just survive these complex times, the company thrived. At the end of November 2021, the company announced record profits.

Jay Strief, the Group Engineering Manager of Supply Chain Solutions, connects this success in part to managing through supply chain issues and puts it in personal terms. “The awesome story here is the change in the culture; innovation, risk-taking, and many clear examples of teams stepping out of their comfort zone to deliver new value.” All of this, he adds, “was made possible through our digital transformation.“

9.1 Why Supply Chain Solutions Went Agile

Powers has been a leader in the information technology space at John Deere for most of her two-decade career.

She helmed the company’s Business Process Integration organization and an ERP implementation for the company’s Construction & Forestry Division. Powers has also led John Deere’s global analytics organization and a variety of technical teams within finance and manufacturing. She is a master of the “classic” ways of working.

When asked if there’s anything Powers misses about those pre-Agile days she quickly answers “no,” before adding, “looking back at the challenges we had to overcome in the last 18 months, I can’t fathom trying to do that without being this Agile.”

Traditional supply chain management tactics had long served John Deere well. After all, it’s impossible to grow into a Fortune 100 company with a large global footprint without efficiently coordinating your network of suppliers and deliveries.

But, as a company, John Deere understands that good enough today may not work tomorrow. Powers and her teams believed the traditional approach wouldn’t be fast enough or flexible enough to keep up with the rate of innovation and business demands for digital solutions from the global supply chain organization.

Powers says procurement of digital solutions could take months to materialize – or longer. The needs of the business line making the request often changed during that time. What was delivered was what they originally asked for but not always what they now knew they needed. It was clear that John Deere needed to adapt to continue to support customers with growing technology needs and increasing expectations for efficiency.

Supply Chain Solutions needed to move faster and more efficiently to help John Deere continue to be an industry leader. So, they started to wonder, “How do we eliminate as many handoffs as possible? How do we streamline this process? How do we better interact with the customer or internal partners?” And Powers asked herself, “How do we ensure we have the right skills and the right talent to be able to respond faster?”

Innovation is one of John Deere’s core values and the company prides itself on creative problem solving. This is part of the DNA of the company and its culture. When Powers and her team learned about the Agile Operating Model (AOM) — a transformation strategy that had been introduced to modernize the John Deere Global IT group — and the collaboration with Scrum Inc. they pushed to be included in the second wave of the transformation.

In early 2020, while still in the immersion phase of their training, Supply Chain Solutions was called on to support the Global Supply Management organization dealing with the volatility, uncertainty, complexity, and ambiguity (V.U.C.A.) that has now become the norm for supply chains worldwide.   

9.2 Overcoming V.U.C.A.: COVID-19 and Supply Chain Disruptions

Designated as an essential business — John Deere has continued operating and building products that help build and maintain critical infrastructure and feed the planet — throughout the pandemic.

The challenge of keeping all of John Deere’s assembly lines running would be immense. But as Powers notes, “John Deere always rises to the challenge.”

At this point, John Deere’s Supply Chain Solution teams had effectively implemented both  Scrum  and  Scrum@Scale . Powers says both frameworks helped Supply Chain Solutions live up to its name.

No longer slowed by the overly burdensome and bureaucratic approach, the teams quickly pivoted from a primarily strategic focus to one that balanced both the tactical and strategic needs required during the pandemic.

Working in two-week Sprints allowed the teams to replan and reprioritize faster. They pivoted to overcome new pain points or the constantly changing conditions on the ground. John Deere’s Supply Chain Solutions teams have always had strong and reliable analytics and could see potential bottlenecks in their network. When paired with Scrum and Scrum@Scale, these teams now had the flexibility to act to counter the bottlenecks before they choked off critical parts.

Perhaps the most important change, however, came from the stronger alignment and team empowerment that both Scrum and Scrum@Scale helped build.

In the old ways of working, Supply Chain Solutions teams would often be told to undertake a predetermined solution by buyers and supply base managers, limiting the opportunity for Supply Chain Solution team members to share their expertise.

The Agile mindset Scrum and Scrum@Scale bring means those who do the work, and know it best, are free to figure out the most effective way to get it done. “To me, that was the big game-changer,” explains Powers, “because you have that collective brainpower, the folks who know the data and know the ins and outs that can provide things the business didn’t even dream of.”

Take the example of the shortage of materials brought on by the pandemic. Within their ferrous components commodity group, the supply chain analytics and sourcing teams took a new approach to manage cost and risk. John Deere leveraged its bill of materials to generate greater visibility into everything it purchased throughout its supply chain. John Deere used a tier taxonomy to indicate the difference between a completed component (Tier 1) and the pieces needed to make it (Tier 2). Heightened visibility into these different tiers allowed the company to creatively overcome bottlenecks before problems arose. Thus, better managing cost and risk.

“While the initial scope started as a single commodity, additional opportunities quickly came into view as the analytics group developed comprehensive views of our total spend by category,” says Powers. “The evolution of the tiered spend project was a great illustration of Agile in action. The iterative development and ongoing connection between category managers and analytics team members ensured that the end result was useful for a broad group of internal teams.”

The team’s solution to 2021’s worldwide microchip shortage was even more creative.

Normally, John Deere does not buy microchips directly. Instead, it buys completed boards that contain those chips from suppliers. Still, explains Powers, Supply Chain Solutions knew the shortage could detrimentally affect their businesses because “if the suppliers can’t get the chips, they can’t make the boards and we can’t put them into machines.”

So, Supply Chain Solutions asked their network how they could help suppliers secure the microchips directly. They assigned a few team members to create automation scripts that scoured the internet for microchips that would meet their specific needs and when they would be available. This new system helped supplement their suppliers.

All this, Powers explains, came with just one caveat for their suppliers, “all the chips John Deere helped secure would be sold back to us on a completed board.”

Again, John Deere’s lines kept running. That’s something other major manufacturers could not say. “Obviously we’re facing the same challenges other companies are,” explains Powers, “the difference is our ability to step out and do things we normally don’t do to help our suppliers. This, in turn, helps us secure what we need.”

Same team, new operating model and a new mindset, and the “ability to successfully operate in any situation.” That is what the Agile Operating Model, Scrum, and Scrum@Scale delivered for John Deere’s Global IT organization.

Strief puts it this way: “The digitalization of our supply chain business is not just about new technology, it is transformational in terms of new business value we are delivering. Along the way, we have delivered higher job satisfaction for our software engineers and continue to invest in developing cutting-edge skills in our people.”  

9.3 Structured to Deliver Strategic and Tactical Goals

As we know, 2020 and 2021 were some of the most challenging years supply chain professionals had faced in the modern era. Just delivering tactical goals could be a major accomplishment given the level of V.U.C.A. the function faced.

The ingenuity and dedication of John Deere’s Supply Chain Solutions team members, and their use of Scrum and Scrum@Scale, meant they could deliver both the tactical and strategic.

Along with their Scrum training, Supply Chain Solutions Agile journey began with two significant structural changes which helped the teams deliver beneficial outcomes.

As Powers explains, the first such change evolved how the unit was led. “We took what use to be a single management position and broke it out into two roles with different, more focused accountabilities.”

One role, the business digital product lead, focuses on the business problems the unit was helping to solve as well as examine ways technology can help drive those desired outcomes. This is Powers’ role.

The second role, held by Strief, focuses on ensuring teams have the right capabilities with digital skills, technical acumen, and depth of experience to innovate and deliver successfully and rapidly.

This new leadership structure ensures both Powers and Strief are laser-focused on their specific areas of expertise. They have clear accountabilities, know what each is responsible for, and allow for cleaner lines of communication and minimal bureaucratic hurdles. Powers believes that this split structure, “is what really makes this model work.”

The second significant structural change involved the teams themselves.

“In the past, teams were structured around an application or specific technology,” says Powers, “so a shift from a strategic project to a tactical need could slow that strategic project down significantly.”

Powers says, “We started really looking at our applications and processes,” in new ways. They identified what was obsolete as well as what could be streamlined or grouped together. Supply Chain Solutions then completely revamped their product taxonomy around these newly identified value streams and restructured their teams accordingly.

Besides being more efficient, Powers notes this new product structure also created, “a stronger sense of empowerment and ownership,” throughout the team — from the product owner to the team members. “That’s their baby and their pride and joy.”

So, they get to really take that to the next level and know they had a real hand in making a positive impact,” versus just checking off a list of requirements and requests.

The teams also changed how they worked.

In Scrum, teams break large work into smaller increments. This, says Powers, along with a well-prioritized backlog meant “the teams were able to move from the tactical to the strategic without losing momentum.” The net result of these changes in structure and process, combined with John Deere’s strong analytics, is clear; John Deere’s lines kept running — through the pandemic, supply bottlenecks, and shortages. At the same time, the Supply Chain Solutions teams were able to deliver multiple award-winning strategic initiatives that helped the company control or recoup costs and boost efficiency. These included:

• Modernizing the ‘Cost Central’ internal application that is a hub for material cost management throughout the company. The upgrades included increased its ease of use, visibility of data like expected cost, and an overall improvement in user experience and engagement.
• A strategic initiative that leveraged analytics and the increased visibility spurred by John Deere’s Agile transformation for digital products that  allowed the company to recoup some $20 million in duty drawbacks .
• A strategic initiative that combined machine learning and analytics to increase leverage buying power and cost control by creating visibility into parts with similar dimensions, components, performance, and material characteristics but different part numbers.

9.4 Additional Results and Metrics

John Deere’s leadership began their Agile transformation by setting ambitious goals. Each represents a level of targeted improvement any company would love to achieve.

Throw in the unprecedented level of complexity and V.U.C.A. that have been the hallmark of supply chains throughout 2020 and 2021 and you might expect that John Deere’s Supply Chain Solutions teams would, at best, come close to achieving them.

Instead, just six months after the end of the immersion phase of their training, Supply Chain Solutions has smashed through those ambitious goals and has achieved far more than anticipated. The data collected by John Deere on five specific areas tell the story best:

• Cycle Time:  Before John Deere’s Agile transformation, the time it took for Supply Chain Solutions to go from idea to delivery was 54 days. Now it takes just 11 days.  This represents a 79 percent improvement , far more than the 40 percent targeted by leadership.
• Time to Market:  Leadership wanted to decrease this by 40 percent.  Supply Chain Solutions has decreased it by 66 percent , from a baseline of 89 days to 30.
• Functions/Features Delivered per Sprint:  Supply Chain Solutions was delivering nine functions per sprint before their Agile transformation. Leadership wanted that number to increase by 125 percent. Six months after their immersion phase ended, Supply Chain Solutions is now delivering 49 functions per sprint,  an improvement of 448 percent .
• Deploys:  Here leadership targeted a 125 percent increase over the baseline of 10. Instead, Supply Chain Solutions has increased that to 67, a 567 percent improvement .
• Cost Efficiency:  Hiring the right people, with the right skills for the right roles allowed Supply Chain Solutions to eliminate ‘middlemen’ and costly handoffs. This allowed the teams to deliver the above results while  reducing overall costs by 20 percent .
• Team eNPS: Employee Net Promoter Score, or eNPS, is an effective way to measure team happiness and engagement. A score above 50 is considered excellent so leadership set a target score of 50+ for this metric.  Supply Chain Solutions’ current eNPS score is 60 .

To Powers, that last data point personifies their Agile transformation. “Having fun at work and getting things done are not mutually exclusive,” she says, “we went through this journey and people started having fun, and we’re seeing the difference in the results.”

9.5 Conclusion 

At the start of their Agile journey, many questioned if it would work in the structured and intertwined environment. “Lots of people doubted that Agile would work here. That you could do an Agile transformation in Supply Chain Solutions.”

Powers freely admits that she was one of those doubters.

Then, she had her “a-ha” moment.

“Suddenly I saw how it absolutely applies to everything you do,” no matter how complex or intertwined. She admits that “It may take a little blind faith to start your Agile journey,” before adding,” the pieces will make sense. The teams will deliver more, you’ll accomplish more, and everybody will love what they’re doing.” That, she says, is the game-changer. For Supply Chain Solutions, Agile allows them to adapt while the game itself keeps changing.

10. Future of Scrum, Scrum@Scale, and the Agile Operating Model at John Deere

The success of the AOM built on Scrum and Scrum@Scale as well as DevOps, Organization Design and a modernized technology stack is undeniable.

The group’s Scrum Teams are happier, more empowered, and more engaged. As Amy Willard notes, “We can deliver functionality that our customers love faster than ever before.” Rework is down. Quality is up.

“The verdict is in,” says Josh Edgin – The AOM was clearly “the right thing to do.”

Successful implementations are known to spread organically throughout an organization. Well beyond the group that launched the transformation. Edgin says this has already begun at John Deere.

“One of our Agile coaches was asked to go down to the factory floor and work with one of the factory teams. They had tremendous success.”

Global IT Vice President Ganesh Jayaram sees “The fact that Agile has made it into the vernacular of the broader company,” as one of his favorite signs of success.

Research and development, manufacturing, human resources, are all areas where he believes the AOM can help drive beneficial outcomes. “You can transform any function,” says Jayaram, “You have a backlog, you prioritize, you become customer-centric.” That, he says, would be the AOM’s biggest win.

As a company, John Deere’s higher purpose is clear: We run so life can leap forward. The Global IT group is positioned to help achieve that purpose for decades to come.

Update: On May 31st, 2022, Ganesh Jayaram was appointed the Chief Information Officer at John Deere. 

How John Deere’s Global IT Group Implemented a Holistic Transformation Powered by Scrum@Scale, Scrum, DevOps, and a Modernized Technology Stack

Better Results. Starting Now.

From Fortune 100 companies to the newest start-ups, Scrum Inc. enables companies to transform into self-sustaining Agile enterprises.  How can we help you? Schedule a consultation by filling out the form below or call us at 617-225-4326.

• SUGGESTED TOPICS
• The Magazine
• Newsletters
• Managing Yourself
• Managing Teams
• Work-life Balance
• The Big Idea
• Data & Visuals
• Reading Lists
• Case Selections
• HBR Learning
• Topic Feeds
• Account Settings
• Email Preferences

How Planview Became Its Own Case Study in Agile Transformation

Sponsor content from Planview.

Transformation looks different from organization to organization, but there is one common truth for all of us: it is a journey.

At Planview, we’ve been leaders in project portfolio management (PPM) solutions for more than 30 years, but it became clear that our market was evolving, and our customers were changing. We saw an opportunity to grow dramatically, but we knew it required a transformation of our own to make it a reality. We became our own case study in Agile transformation, using an inspect and adapt approach that would ultimately help us better understand our customers’ journey.

Agile novices often misunderstand the methodology and Manifesto when they discover Agile. At Planview, we certainly had our own misconceptions. Our software development teams had been using Agile methodologies for over a decade, so how much more Agile could we get?

But our customers and the market were starting to evolve beyond our traditional portfolio management product lines, and we needed to adapt in order to deliver the products and solutions they required. As a company, we needed not only to advance our strategy but also to change at an operational level.

After considering our organic and inorganic growth options, we took our first step toward agility with the acquisition of LeanKit in December 2017. LeanKit was (and still is) a highly regarded market leader with a great enterprise Kanban product. We were confident that this acquisition would boost our Agile credibility in the market, and our sales teams would sell LeanKit and the value of “Agile” just like they were selling our existing products. Certainly, this Agile DNA and product infusion would catalyze our Agile transformation as an organization.

For almost a year, we operated as though transformation would just happen. We had sporadic successes but not the change we had hoped for – or the one we needed.

At the end of 2018, we took our second step to change our corporate priorities from the top. We added a company-wide goal to rewire our organization and business through a new Agile Growth Initiative. The objectives were simple:

• Change the people
• Change the culture
• Change the mindset

Our rewiring was about change, but with a continuous improvement and continuous learning approach. We were committed to bringing along everyone who was up for the journey; it didn’t mean firing everyone. What it meant was committing to:

• Infusing agility into the organization by increasing Agile DNA throughout
• Admitting we could not do it alone and bringing in outside coaching support
• Embracing Agile practices and ceremonies from leadership to the teams
• Reorganizing people and teams to focus on customer value
• Empowering everyone to have a voice and do their best work

Unlike most organizations, we started our Agile Growth Initiative in marketing, not product or IT. Although the product teams could be improved, they had already been Agile for a decade. And product was not where the biggest opportunity existed (or so we thought); it was in the go-to-market and marketing departments where we were feeling the challenges of change. So we hired Agile-first marketers and an Agile coach with a marketing background.

With these few new team members onboard, we facilitated a low-prep, nearly ad hoc Agile discovery session. We brought together sales, marketing, and product leaders and asked them to list their priorities. No one had the same ones. This was not surprising. Everyone in the business was running as fast and as hard as they could, but we were not moving forward at the pace we wanted. Scaling across functions was our core challenge.

Next, we asked leaders to list their top three priorities. Those three business priorities aligned with our product and solutions goals, resulting in an experiment. We created three cross-functional Agile teams as part of our first Go-to-Market (GTM) Agile Release Train (ART). Three weeks later, we held our first Program Increment (PI) Planning event. We planned together across functions (as a value stream) for the first time in company history, using our leaders’ top three priorities and the Agile Growth Initiative as our North Star. That first PI Planning event was ugly – truly brutal in every possible way – but we learned a lot. Putting 50+ people from different business functions together for three days forced some hard conversations that ultimately resulted in reorganizations and the realignment of people and funds.

Out of that first PI Planning event, we quickly realized that the GTM ART needed sharper outcomes and OKRs (Objectives and Key Results) to work toward. Not only did the GTM ART need outcomes, but as a business, we needed to have everyone aligned with the same goal – a much clearer focus on delivering value to our customers.

We took a hard look at what provided value to the customer. It wasn’t individual products, but it was solutions – multiple products that, when combined, solved business problems in truly unique ways. By asking our GTM teams to be solution (versus product) oriented, a laser focus was placed on our product teams to enable end-to-end solutions to deliver customer value in new ways. With a similar beginning as our GTM ART, we didn’t overthink; we got our product leaders in a room, hashed out enough details to get started, and collectively got on strategy.

Along our journey (with marketing, product, and sales), we established and committed to Agile ceremonies and cadences. We created Lean Portfolio Management meetings, Scrum Master Centers of Practice, Agile Centers of Practice, Voice of Customer meetings, Delivery Steering, Demos, and Retrospectives. Our commitment to these ceremonies allows us to continuously improve and evolve, and they are a critical piece of our transformation journey.

Throughout this entire experience, we learned that people are resilient. If you provide the “why” and empower them, they will figure out how to deliver their best work. And through this transformation journey, we feel we have. Recently, our efforts were recognized by a leading analyst, Gartner. Planview was recognized as a Leader in the Gartner 2020 Enterprise Agile Planning Tools Magic Quadrant, and we believe our transformation is the reason why. Not bad for a 30-year-old PPM company.

Download the Gartner 2020 Enterprise Agile Planning Tools Magic Quadrant to learn more about Planview.

Product Management

Product Development

Product Capability

• Client Stories
• Agile Delivery

Agile at Scale: Insights From 42 Real-World Case Studies

Even though most large teams are already on an agile journey, many are still looking for how to make agile work at scale. There is no shortage of opinions available, including my own, but I wanted to get deeper than just opinion and look at what the independent research says.

One of the more thorough and comprehensive research papers I found was an aggregation of 42 real-world studies into making agile at scale work. The paper is Challenges and success factors for large-scale agile transformations: A systematic literature review from 2016 authored by Kim Dikert, Maria Paasivaara and Casper Lassenius from MIT and the Aalto University in Finland. 

Agile has reached the plateau of productivity where teams need to focus on incremental improvements to how they run agile. So, the insights from a paper like this provide an interesting lens to diagnose problems and make those incremental improvements.

In this post, you will get an overview of the insights from the paper:

• 35 challenges organised into 9 Challenge Areas
• 29 success factors organised into 9 Success Factor Areas

What Insights Were the Strongest

The list of challenges and success factors is 64 items long and worth going through in detail but to save you some time, here is a brief overview of the factors that the researchers deemed the strongest. 

The Challenge Areas that came through strongest: 

• Agile being difficult to implement (48% of studies), 
• Integrating non-development functions (43%),
• Change resistance (38%) and Requirements engineering challenges (38%). 

The Success Factor Areas that came through the strongest:

• Choosing and customising the agile approach (50%), 
• Management support (40%),
• Mindset and Alignment (40%),
• Training and coaching (38%).

Challenge Areas for Agile at Scale

There are a number of challenges that you, your team and your organisation will face in making agile work at scale. Many of the challenges identified by the research will likely resonate with you. 

This list can be helpful in debugging and articulating the problem you are facing. The Challenge Areas are:

• Change resistance
• Lack of investment
• Agile being difficult to implement
• Coordination challenges in multi-team environments
• Different approaches emerge in a multi-team environment
• Hierarchical management and organisational boundaries
• Requirements engineering challenges
• Quality assurance challenges
• Integrating non-development functions in the transformation

Each of these is expanded out below into more specific challenges.

1. Change Resistance

People are inherently resistant to change. Here are some of the specific challenges around resistance to change when it comes to agile at scale:

• General resistance to change
• Scepticism towards the new way of working
• Top-down mandate creates resistance
• Management unwilling to change

2. Lack of Investment

Making agile work requires some investments. A lack of investment in some specific areas is a challenge to making agile at scale work:

• Lack of coaching
• Lack of training
• Too high workload
• Old commitments kept
• Challenges in rearranging physical spaces

3. Agile Being Difficult to Implement

There are some difficulties specific to agile itself:

• Misunderstanding agile concepts
• Lack of guidance from the literature
• Agile customised poorly
• Reverting to the old way of working
• Excessive enthusiasm

4. Coordination Challenges in Multi-team Environments

There are some challenges specific to coordinating across multiple teams:

• Interfacing between teams is difficult
• Autonomous team model is challenging
• Global distribution challenges
• Achieving technical consistency

5. Different Approaches Emerge in a Multi-Team Environment

When you’re doing agile at scale, different approaches emerge which present these challenges:

• Interpretation of agile differs between teams
• Using old and new approaches side by side

6. Hierarchical Management and Organisational Boundaries

The organisation’s structure presents some challenges:

• Middle managers role in agile unclear
• Management is in waterfall mode
• Keeping the old bureaucracy
• Internal silos kept

7. Requirements Engineering Challenges

At scale, requirements in agile present some challenges:

• High-level requirements management largely missing in agile
• Requirement refinement challenging
• Creating and estimating user stories hard
• The gap between long and short term planning

8. Quality Assurance Challenges

Making agile work at scale means facing some challenges around quality:

• Accommodating non-functional testing
• Lack of automated testing
• Requirements ambiguity affects QA

9. Integrating Non-Development Functions in the Transformation

Once agile starts to move beyond the development team, which is inevitable at scale, then there are some challenges in involving other parts of the organisation:

• Other functions unwilling to change
• Challenges in adjusting to incremental delivery pace
• Challenges in adjusting product launch activities
• Rewarding model, not teamwork centric

Success Factor Areas for Agile at Scale

The research identified 29 factors that can help make agile work better at scale and grouped them into these top-level areas:

• Management support
• Commitment to change
• Choosing and customising the agile approach
• Training and coaching
• Engaging people
• Communication and transparency
• Mindset and Alignment
• Team autonomy
• Requirements management

1. Management Support

Management support is a key part of agile succeeding at scale. The individual factors are:

• Ensure management support.
• Make management support visible
• Educate management on agile

2. Commitment to Change

Agile needs a commitment to change, specifically:

• Communicate that change is non-negotiable
• Show strong commitment

3. Leadership

Leaders can play a role in success. The factors at play here are:

• Recognise the importance of change leaders
• Engage change leaders without the baggage of the past

4. Choosing and Customising the Agile Approach

There are some specifics to how you customise agile that can set you up for success:

• Customise the agile approach carefully
• Conform to a single approach
• Map to the old way of working to ease adaptation
• Keep it simple

5. Piloting

A pilot can help agile succeed, specifically:

• Start with a pilot to gain acceptance
• Gather insights from a pilot

6. Training and Coaching

There are two key success factors when it comes to upskilling your people and teams for agile at scale:

• Provide training on agile methods
• Coach teams as they learn by doing

7. Engaging People

People play a key role in making agile work at scale. The specific factors around engaging people in the journey are:

• Start with agile supporters
• Include persons with previous agile experience 
• Engage everyone

8. Communication and Transparency

There are some success factors for communicating:

• Communicate the change intensively
• Make the change transparent
• Create and communicate positive experiences in the beginning

9. Mindset and Alignment

The success factors for agile around mindset and alignment are:

• Concentrate on agile values
• Arrange social events
• Cherish agile communities
• Align the organisation

10. Team Autonomy

Team autonomy has two factors that enable success with agile:

• Allow teams to self-organize
• Allow grassroots level empowerment

11. Requirements Management

There are also two factors when managing requirements that can help enable agile at scale: 

• Recognise the importance of the product owner role
• Invest in learning to refine the requirements

More on Agile:

• Simple View of Common Elements of Agile at Scale
• Video: Agile is Dead, McKinsey Just Killed It

Scott Middleton CEO & Founder

Scott has been involved in the launch and growth of 61+ products and has published over 120 articles and videos that have been viewed over 120,000 times. Terem’s product development and strategy arm, builds and takes clients tech products to market, while the joint venture arm focuses on building tech spinouts in partnership with market leaders.

Twitter: @scottmiddleton LinkedIn: linkedin.com/in/scottmiddleton

Get articles like this sent to your inbox and build better products

2021 Theses Doctoral

Agile Innovation Team Learning: A Multiple Case Study of Agile Software Development Teams

Sleeva, Sheryl Lynn

Innovation is essential for growth, yet can be difficult to achieve due to the associated cost and risk. As such, organizations earnestly seek to adopt practices that positively impact innovation outcomes and improve innovation team effectiveness. Existing research has shown that team learning is an important enabler of innovation and that Agile software development practices have distinct advantages over traditional methods. However, little is understood about the learning dynamics of Agile teams, particularly in an innovation context where teams are focused on creating new product and technology solutions. This qualitative multiple case study explored the perceptions of software development teams at two leading organizations in the HealthTech and InsureTech industries, in order to gain a deeper understanding of and expand what is known about how Agile teams learn and how they leverage learning to innovate. Participating teams were engaged in innovation work and used Agile methods to co-create solutions with customers. The study used multiple data collection methods, incorporated cross-team/cross-case analyses, and featured an integrated theoretical framework based on three team learning models: Dechant, Marsick & Kasl (1993), Edmondson (1999), and Decuyper, Dochy & Van den Bossche (2010). Research results revealed that Agile teams learn informally, incidentally, and synergistically through eight dynamic, learning-rich, practice-driven experiences and that specific team learning behaviors and team innovative work behaviors that foster innovation are quite prevalent on Agile teams. Results also demonstrated that Agile values, principles, and practices shape and support team learning by creating a team-centered learning culture which facilitates collective thinking and action. This study sets forth a new understanding of Agile practice-driven experiences as learning-centered work and demonstrates how large-scale Agile transformation helped to facilitate the reskilling and upskilling of experienced adult learners. It also emphasizes the importance of strategically leveraging Agile team learning at both the team and organizational levels and provides specific recommendations for research and practice. Empirical insights from this study can prove valuable for leaders and organizations employing Agile methods, as well as researchers and educators engaged in the advancement of innovation practice, workplace learning and technology workforce education.

• Adult education
• Information technology
• Entrepreneurship
• Team learning approach in education
• Educational innovations--Evaluation
• Education--Effect of technological innovations on

More About This Work

• DOI Copy DOI to clipboard

In-Depth: The Evidence-Based Business Case For Agile

• Twitter for Christiaan Verwijs
• LinkedIn for Christiaan Verwijs

What is the business case for Agile teams? Is it  really that  important that they are autonomous, able to release frequently, interact closely with stakeholders and spend all that time on continuous improvement? Or is all that just hype? Or maybe even counterproductive?

Yes, we believe all these things are important. And so does probably everyone else in our community. But what is the evidence we have for this? What proof do we have that we aren’t just selling a modern equivalent of snake oil? We think we do well to  base our beliefs about Agile more on evidence . This allows us to test our beliefs and also makes our case stronger in case they are supported.

This post is our attempt to bring an evidence-based perspective to the business case of Agile teams. We will share results from scientific studies that we located through  Google Scholar . And we share results from our own analyses based on actual data from stakeholders and Scrum teams that we collected through the  Scrum Team Survey .

This post is part of our  “in-depth” series . Each post discusses scientific research that is relevant to our work with Scrum and Agile teams. We hope to contribute to  more evidence-based conversations  in our community and a stronger reliance on robust research over personal opinions.

A working definition of Agile and Stakeholders

Before we begin, we need to define some of the terms we will use throughout this post. The first term is  Stakeholder . Throughout this post, we define them as “all users, customers, and other people or groups who have a clear stake in the outcomes of what this team produces, and invest money, time or both in making sure that happens”. So this excludes people who have an opinion about the product but don’t stand to lose  anything  when the team fails.

The second term I’d like to define is  Agile  or  agility . What do we actually mean when we talk about an “Agile team”? In its broadest sense, we mean that these teams practice the principles of the  Agile Manifesto . But this is still rather vague. We could say that these teams practice Agile methodologies, like Scrum or XP, and are therefore Agile. But adherence to a framework or prescribed process does  not  guarantee agility. In fact, we’ve written the  Zombie Scrum Survival Guide  specifically to shine a light onto all those teams who think they have checked all the boxes of the Scrum framework, and are still not moving.

“Adherence to a framework or prescribed process does  not  guarantee agility.”

I prefer a process-based definition of agility. This definition answers the question: “What kind of processes typically happen in Agile teams that distinguish them from non-Agile teams?”. We worked with Prof. Daniel Russo of the University of Aalborg to answer this question with data from almost 2.000 Scrum teams.  In a scientific study , we identified five  core processes  — or factors— that happen in and around Agile teams at varying levels of quality:

• Teams work to be as  responsive  as possible through automation, refinement, and a high(er) release frequency.
• Teams show concern for the  needs of their stakeholders  by collaborating with them closely and making sure that what is valuable to them is represented in their work and goals.
• Teams engage in  continuous improvement  to improve where they can through frequent reflection, shared learning, and creating a psychologically safe environment.
• Teams expand and use their  autonomy  to manage their work and bring their skills together in the most effective ways.
• In the immediate environment of Scrum teams,  management supports  what teams do and helps them where possible.

Although we used Scrum teams for our investigation, these processes are generic enough to apply to Agile teams in general. We collected the data through our  Scrum Team Survey . This tool uses  a validated and scale-based questionnaire  to allow teams to diagnose and improve their process in an evidence-based way. You can use the free version for individual teams.

For this post, we used a sample of 1.963 Scrum teams and 5.273 team members. The sample was cleaned of fake and careless responses and corrected for social desirability where relevant. Our sample includes teams from all sectors, sizes, and regions.

Finding #1: Teams Vary Widely In Their Actual Agility

In our sample of 1.963 Scrum teams, we observed a wide range of scores on the five core processes of agility. We calculated an overall agility score for teams and categorized them into three buckets — low, moderate, and high — for easier interpretation. The histogram below shows the differences visually:

There are two caveats to this histogram. First, the cutoffs for low, moderate, and high agility are fairly arbitrary. In reality, agility is obviously a continuum that teams traverse. Second, there is some circularity because we calculate the overall agility of a team as an aggregate of the five core processes. So it is not surprising that the scores improve as teams become more Agile.

However, the histogram illustrates nicely the  size  of this increase, which is both significant for all differences (p<.001)  and  highly substantial. It also illustrates well how all processes improve, and not just one or two. They seem to be connected. The results also affirm that calling yourself a Scrum team — as the teams in this sample mostly did — is no guarantee of actual agility. At the same time, we can clearly see that many Scrum teams  are  Agile.

“It is clear from these results that identifying yourself as an Agile or Scrum team is no guarantee of actual agility.”

So we know now have a better sense of the differences between the quality of the core processes at different “levels” of agility. However, the key question is whether this actually makes a difference in important business outcomes. Are more Agile teams indeed better at producing important business outcomes than less Agile teams?

“Are more Agile teams indeed better at producing important business outcomes than fewer Agile teams?”

Finding #2: Agile Teams Have More Satisfied Stakeholders

Ultimately, we believe that a strong business case lies with how effectively Agile teams can serve the needs of stakeholders, like users, customers, and other people with a clear stake. There is clearly a strong economic incentive for organizations to keep stakeholders happy, as they are the people who pay for, or use, their products.

But do Agile teams have more satisfied stakeholders than less Agile teams? Fortunately, the  Scrum Team Survey  allows teams to ask their stakeholders to evaluate their outcomes. We ask stakeholders to evaluate this on four dimensions: quality, responsiveness, release frequency, and team value. For this analysis, we use the evaluations of 857 stakeholders for 241 teams. 49% of these represented users, 28% customers, and 22% internal stakeholders.

We can statistically test the hypothesis that teams are increasingly able to satisfy their stakeholders as their Agility increases. For this, we used a simple statistical technique called multiple regression analysis. We entered the overall stakeholder satisfaction as the predicted value, and the five core processes as predictors. The regression model was significant (p <.001) and explained 29.2% of the observed variance in stakeholder satisfaction. This may not seem  that  high, but values above 20% are considered “very strong” in the social sciences. The scatterplot shown below shows the distribution of teams based on stakeholder satisfaction (vertical) and Agility (horizontal). Each dot represents a team:

A scatterplot and the results from a regression analysis may not be intuitive for many readers, especially those not familiar with statistics. So we also created a histogram by plotting the least Agile teams against the most Agile teams. It is a bit simplistic, but it illustrates the differences more dramatically.

There is one caveat to these results. The scatterplot suggests that teams are more likely to invite stakeholders when they are already quite Agile. This makes sense; non-Agile teams may interact less with their stakeholders and thus see fewer opportunities to invite them to evaluate the outcomes. But this means we lack data from teams that score very low on agility. However, it is likely that the difference would be even  stronger  if such stakeholders were included.

The bottom line is clear though. Agile teams have more satisfied stakeholders than less Agile teams. This effect is also very strong. So high autonomy, high responsiveness, high continuous improvement, high stakeholder concern,  and  high management support  clearly  go hand-in-hand with higher stakeholder satisfaction. Simply put; if organizations want more satisfied stakeholders, investing in the five processes of agility is a very clear evidence-based recommendation.

“The bottom line of the results is clear though. Agile teams have more satisfied stakeholders than non-Agile teams.”

Finding #3: Agile Teams Have Higher Morale

The second part of our business case can be made by looking at how agility affects team members. Employees are the “human capital” of modern-day organizations. Happy employees allow companies to save money on absenteeism, sick leave, and the hiring and onboarding of new employees to replace others who leave the company.

So it is helpful to look at the morale of teams. Team morale, or ‘esprit de corps’, reflects how motivating and purposeful the work feels to a team ( Manning, 1991 ). Many meta-analyses — statistical aggregations of datasets from many other empirical studies — have shown strong benefits of high morale and its corollaries, like job satisfaction. It reduces turnover and absenteeism among employees ( Hacket & Guion, 1989 ). It also increases performance ( Judge et. al., 2001 ) and proactive behavior ( LePine, Erez & Johnson, 2002 ).

“So there is a clear economic incentive for companies to encourage high morale in teams.”

But is morale higher in Agile teams than in less-Agile teams? To answer this question, we analyzed data from 1.976 teams and 5.273 team members from the  Scrum Team Survey .

So with this data, we ran another linear multiple regression analysis with team morale as the predicted value, and the five core factors as predictors. The resulting model was significant (p <.001) and explained 44.6% of the observed variance in team morale. This is a strong result when we consider that values above 20% are already considered “very strong” in the social sciences. The scatterplot is shown below. Each dot represents a team. The line reflects the optimal regression line. It is clearly visible that as the agility of a team increases (vertical), team morale also increases (horizontal).

We also created a histogram to plot the morale of the most Agile teams against that of the least Agile teams in our database, which is more visually clear:

So what do these numbers mean in practice? Generally speaking, morale will be  much  higher in Agile teams compared to less Agile teams. The morale in the highest-scoring teams (on agility) is almost twice as high as in the lowest-scoring teams. So high autonomy, high responsiveness, high continuous improvement, high stakeholder concern,  and  high management support  clearly  go hand-in-hand with high team morale.

“Generally speaking, morale will be much higher in Agile teams compared to non-Agile teams.”

Intermission: A Note On Causality

Careful readers may have wondered: “But wait! Correlation doesn’t imply causation”. The observable fact that team morale and stakeholder satisfaction are higher in Agile teams does not necessarily mean that agility is the cause. And this is true. It is possible that the effect is actually the reverse; high morale or high stakeholder satisfaction drives teams to become more Agile. Or both bias teams to evaluate their processes in a more positive light than when morale or stakeholder satisfaction is lower. It is also possible that other variables explain both results. For example, an organization with a very flat hierarchical structure  may  both enable high agility as well as high morale or high stakeholder satisfaction.

Unfortunately, causality is very hard to establish with certainty. This requires highly controlled experiments where only the level of agility is manipulated in a team. But how can one feasibly do that? Another approach is to track many organizations over time as they adopt Agile methodologies, while also measuring anything else that could influence their results other than agility itself. It would be wonderful to have such data! However, the sheer effort involved is so gargantuan that this is close to impossible. Fortunately, we don’t need to put the bar  that  high. While correlation doesn’t imply causation, it can certainly make a case for it. Especially when we have strong corroborating evidence from other sources. Our data clearly shows that agility  is  associated with team morale and stakeholder satisfaction. So if you measure that one is going up, the others will probably go up too. Thus, it is probably easier for organizations to create environments for teams that encourage their Agility (e.g. high autonomy, responsiveness, etc) than it is to directly change the morale of team members or even the satisfaction of stakeholders.

But let's take a look at potential corroborating evidence. What do scientific studies have to say?

Finding #4: Scientific Studies Corroborate That Agility Generates Better Business Outcomes

We defined agility in terms of five processes. Agile teams are  responsive , know who their  stakeholders  are and what they need, have  high autonomy , and  improve continuously . They are also  supported by management . What do scientific studies have to say about the business outcomes of Agile methodologies, as well as the factors we just mentioned? So we went to Google Scholar and  searched for review articles .

Cardozo et. al. (2010)  reviewed 28 scientific studies that investigated how Scrum is associated with overall business outcomes. A strength of such a review is that it allows for the identification of patterns across many studies. The authors identified five core outcomes of Scrum: 1) higher productivity in teams, 2) higher customer satisfaction, 3) higher quality, 4) increased motivation in teams and 5) a general reduction in costs. While this study covers even more business outcomes, the second and fourth points match our findings.

A critical part of Agile methods is that new iterations of a product are released more frequently than in more traditional approaches. Several empirical studies have indeed found that teams with a frequent delivery strategy are more likely to deliver successful project outcomes and satisfy stakeholders than teams that do not ( Chow & Cao, 2008 ,  Jørgensen, 2016 ). This also matches our findings for stakeholder satisfaction.

But a high delivery strategy is of little value if what goes out to stakeholders doesn’t match their needs, or doesn’t reach the right people. So teams need to develop a good understanding of who their stakeholders are and what they need.  Van Kelle et. al. (2015)  collected data from 141 team members, Scrum Masters, and Product Owners from 40 projects. They found that the ability of teams to develop a shared sense of value contributed significantly and strongly to project success. They also found that the overall agility of teams increased the chance of project success.  Hoda, Stuart & Marshall  (2011) interviewed 30 Agile practitioners over a period of 3 years. They found that teams that collaborate closely with customers are more successful. However, they also observed that customers are rarely as involved as would be expected from Agile methodologies. This supports our finding that stakeholder satisfaction goes up as teams become more involved with their stakeholders (stakeholder concern).

“The ability of teams to develop a shared sense of value contributed significantly and strongly to project success.”

While high responsiveness and high concern for the needs of stakeholders are arguably the two pillars that distinguish Agile teams from non-Agile teams, these pillars need a good foundation. This is where team autonomy and continuous improvement come into play. Both are important characteristics of Agile teams because it allows them to remain effective in the face of complex, unpredictable work. Many studies have identified high autonomy as an important prerequisite for Agile teams ( Moe, Dingsøyr & Dybå, 2010 ;  Donmez & Gudela, 2013 ;  Tripp & Armstrong, 2018 ;  Melo et. al. 2013 ).  Lee & Xia (2010)  surveyed 505 Agile projects and found that high autonomy allowed teams to respond more quickly to challenges. They also note that this is particularly relevant to complex challenges, which is typically the case for the product innovation that happens in Agile teams. As for continuous improvement, this is generally more a climate in teams than a process. It is marked by high safety, shared learning, high-quality Sprint Retrospectives, and ambitious quality standards.  Hoda & Noble (2017)  identified learning processes as essential for teams to become Agile. So while autonomy and continuous improvement may not  directly  result in business outcomes, they need to be present in order for Agile teams to generate outcomes that satisfy stakeholders, and through a process that is also satisfying to team members.

“While autonomy and continuous improvement may not  directly  result in business outcomes, they need to be present in order for Agile teams to generate outcomes that satisfy stakeholders, and through a process that is also satisfying to team members.”

Finally, this brings us to the role that management plays. Because their support is consistently identified by scientists as the most critical success factor to make all the above possible ( Van Waardenburg & Van Vliet, 2013 ;  de Souza Bemerjo et. al., 2014 ;  Young & Jordan, 2008 ;  Russo, 2021 ). The shift that management has to go through is described by  Manz et. al. (1987)  as “leading others to lead (themselves)”. The authority to make work-related decisions shifts from external managers to the teams themselves. So rather than taking the lead, managers have to take a more supporting role and ask teams where they need their help. Second, management has to understand the point of Agile methodologies like Scrum and support teams by removing any obstacles they experience.

Click to enlarge

There are many other factors that can be considered. But the five processes we identified as characteristics of Agile teams provide a good, evidence-based starting point to make Agile teams more effective, and generate better business outcomes. Together with Prof. Daniel Russo We investigated a sample of 4.940 team members, aggregated into 1.978 Scrum teams, and found that these processes — or factors — together explain a very large amount of how effective Scrum teams (75.6%) are, and 34.9% of team morale and 57.9% of stakeholder satisfaction ( Verwijs & Russo, 2022 ).

What About Other Business Outcomes?

Obviously, team morale and stakeholder satisfaction are just two business outcomes for which economic arguments can be made. But more outcomes can be considered, like business longevity, the ability to deliver value within budget, and so on. We may cover these in future posts, as this one has already become way too long. And if happier team members and happier stakeholders aren’t already convincing enough, good results on those other outcomes aren’t probably going to change minds either :).

Implications For Practitioners

So what does all this mean in practice?

• An important lesson we’ve had to learn is that you can’t sell Agile or Scrum based on frameworks or ideals. Ultimately, the role of (top) management is to keep their business healthy and economically sustainable. Thus, the best way to convince them is to show how Scrum or Agile helps in that regard. This business case should provide some good talking points.
• Generally speaking, it is a good idea to track important business outcomes as metrics. For example; the number of sales, the number of unhappy customers, absenteeism, etc. This provides you with an opportunity to take an evidence-based approach to improvements. You can also measure such metrics alongside an ongoing Agile adoption, and see how Agile is improving certain metrics (or not).
• You can use the  Scrum Team Survey  to diagnose your Scrum or Agile team for free. We also give you tons of evidence-based feedback. The  DIY Workshop: Diagnose Your Scrum Teams With The Scrum Team Survey  is a great starting point.
• Our Do-It-Yourself Workshops are a great way to start improving without the need for external facilitators. The  DIY Workshop: Discover The Needs Of Your Stakeholders With UX Fishbowl  or  Experiment: Deepen Your Understanding Of Scrum With Real-Life Cases  are great starting points. The  DIY Workshop: Build Understanding Between Scrum Teams And Management  is also very useful if management support is the biggest issue. Find many more  here .
• We offer a number of physical kits that are designed to start conversations with and between teams and the larger organization. We have the  Scrum Team Starter Kit , the  Unleash Scrum In Your Organization Kit , and the  Zombie Scrum First Aid Kit . Each comes with creative exercises that we developed in our work with Scrum and Agile teams.

Our goal with this post was to make a stronger, evidence-based business case for Agile and Scrum. Taken together, we have strong evidence to support the belief that Agile teams deliver more value to their stakeholders than less Agile teams. They also have much higher team morale. Any company worth its salt would see the economic value in both of these outcomes. Happy stakeholders generate more revenue, spread positive word-of-mouth, and are more likely to stay. Similarly, happy team members are more productive and more likely to stay for the long term. If companies seriously invest in Agile, and in particular in the five factors we covered in this post, they are  very  likely to see better results.

Is this an indisputable fact? No. But the evidence to support it is very strong indeed, and growing every day.

This post took over 46 hours to research and write . Find more  evidence-based posts here .  We thank all the authors of the referenced papers and studies for their work.

Cardozo, E. S., Araújo Neto, J. B. F., Barza, A., França, A. C. C., & da Silva, F. Q. (2010, April). SCRUM and productivity in software projects: a systematic literature review. In  14th International Conference on Evaluation and Assessment in Software Engineering (EASE)  (pp. 1–4).

Chow, T., & Cao, D. B. (2008). A survey study of critical success factors in agile software projects.  Journal of systems and software ,  81 (6), 961–971.

Dönmez, D., & Grote, G. (2013, June). The practice of not knowing for sure: How agile teams manage uncertainties. In  International Conference on Agile Software Development  (pp. 61–75). Springer, Berlin, Heidelberg.

Jørgensen, M. (2016). A survey on the characteristics of projects with success in delivering client benefits.  Information and Software Technology ,  78 , 83–94.

LePine, J. A., Erez, A., & Johnson, D. E. (2002). The nature and dimensionality of organizational citizenship behavior: a critical review and meta-analysis.  Journal of applied psychology ,  87 (1), 52.

Lee, G., & Xia, W. (2010). Toward agile: an integrated analysis of quantitative and qualitative field data on software development agility.  MIS quarterly ,  34 (1), 87–114.

Melo, C. D. O., Cruzes, D. S., Kon, F., & Conradi, R. (2013). Interpretative case studies on agile team productivity and management.  Information and Software Technology ,  55 (2), 412–427.

Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project.  Information and software technology ,  52 (5), 480–491.

Hacket, R. D. (1989). Work attitudes and employee absenteeism: A synthesis of the literature.  Journal of occupational psychology ,  62 (3), 235–248.

Hoda, R., & Noble, J. (2017, May). Becoming agile: a grounded theory of agile transitions in practice. In  2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE)  (pp. 141–151). IEEE.

Hoda, R., Noble, J., & Marshall, S. (2011). The impact of inadequate customer collaboration on self-organizing Agile teams.  Information and software technology ,  53 (5), 521–534.

Judge, T. A., Thoresen, C. J., Bono, J. E., & Patton, G. K. (2001). The job satisfaction–job performance relationship: A qualitative and quantitative review.  Psychological bulletin ,  127 (3), 376.

Tripp, J., & Armstrong, D. J. (2018). Agile methodologies: organizational adoption motives, tailoring, and performance.  Journal of Computer Information Systems ,  58 (2), 170–179.

What did you think about this post?

Share with your network.

• Share this page via email
• Share this page on Facebook
• Share this page on Twitter
• Share this page on LinkedIn

View the discussion thread.

Agile Case Studies

• Post author: Devendra Kumar
• Post published:
• Post comments: 0 Comments
• Analyze case studies that showcase the successful implementation of Agile methodologies and frameworks.
• Understand how organizations have embraced Agile practices to improve project outcomes, adapt to change, and deliver value.

Agile methodologies and frameworks have gained widespread adoption across various industries due to their ability to improve project outcomes, adapt to change, and deliver value.

Below, we’ll analyze case studies that showcase successful implementations of Agile practices in different organizations.

Case Study 1: Spotify - Scaling Agile with the "Spotify Model"

Challenge: Spotify, a music streaming platform, faced the challenge of scaling its Agile practices as the company grew rapidly. They needed a framework to maintain innovation, collaboration, and product development speed.

Solution – The “Spotify Model”:

Squads, Tribes, and Chapters: Spotify organized teams into “Squads” responsible for specific product features. Squads were grouped into “Tribes” aligned with broader business goals. “Chapters” provided a platform for skill development and sharing expertise.

2. Autonomous Teams: Squads were given autonomy to make decisions about their work, allowing them to adapt quickly to changing requirements and market demands.

3. Continuous Improvement: Regular retrospectives allowed teams to identify areas for improvement and make necessary adjustments to their processes.

• The “Spotify Model” enabled rapid growth and innovation while maintaining a strong Agile culture.
• Teams were more responsive to user feedback and market changes.
• The model inspired other organizations to adopt similar Agile scaling approaches.

Case Study 2: Scrum at Microsoft - Visual Studio Team Services (VSTS)

Challenge: Microsoft’s Visual Studio Team Services (VSTS) team needed to improve collaboration, increase transparency, and accelerate the delivery of their software development tools.

Solution – Scrum Implementation:

Scrum Framework: The VSTS team adopted the Scrum framework to manage their work. They organized development into fixed-length iterations (Sprints) and held daily stand-up meetings.

2. Backlog Refinement: The team maintained a prioritized backlog of user stories and regularly refined it based on feedback and changing requirements.

3. Transparency: They used tools like Kanban boards and burndown charts to provide real-time visibility into project progress for both team members and stakeholders.

• Improved collaboration among cross-functional teams.
• Enhanced predictability and transparency of project timelines.
• Faster delivery of features and updates to customers.

Case Study 3: Agile in Healthcare - Cerner Corporation

Challenge: Cerner Corporation, a healthcare technology company, aimed to improve the development and deployment of Electronic Health Records (EHR) systems for healthcare providers. They needed to respond to evolving healthcare regulations and client needs more effectively.

Solution – Agile Transformation:

Cross-Functional Teams: Cerner organized cross-functional teams responsible for different aspects of EHR development, such as patient records and billing.

2. User-Centered Design: They emphasized user-centered design principles, involving clinicians and healthcare professionals in the development process to ensure usability.

3. Frequent Releases: Cerner adopted Agile practices like Scrum and Kanban to deliver software updates more frequently, allowing healthcare providers to benefit from the latest features and regulatory compliance.

• Faster adaptation to changing healthcare regulations.
• Improved EHR usability and user satisfaction.
• Reduced time-to-market for critical healthcare software updates.

These case studies illustrate how organizations across various domains have embraced Agile methodologies and frameworks to improve project outcomes, respond to change, and deliver value to customers and stakeholders. By focusing on collaboration, transparency, user-centered design, and iterative development, these organizations have successfully navigated complex challenges and achieved greater flexibility and innovation in their projects.

Next: 6. Ethical Dilemmas and Decision Making

Please Share This Share this content

• Opens in a new window

Devendra Kumar

You might also like, project team management, week 3 – apply search engine optimization (seo) – shuffle q/a 2, leave a reply cancel reply.

Save my name, email, and website in this browser for the next time I comment.

Emerging field or passing fashion? A case study of Agile-Stage-Gate model in innovation processes

Revista de Gestão

ISSN : 2177-8736

Article publication date: 20 March 2023

Issue publication date: 13 October 2023

Agile methods are increasingly being applied in the contexts of innovation beyond traditional information technology (IT) and physical product development projects, such as when process improvements are being implemented. Nevertheless, this phenomenon is still recent and little addressed in the literature, with few descriptions of empirical cases. This study aims to address this gap.

Design/methodology/approach

This multiple case study aims to present and discuss the application of Agile practices embedded in large companies’ innovation value chains, focusing on improvements of business processes. The following research question is pursued: How are large companies applying elements of Agile methods to their innovation processes when implementing incremental improvements in their operational processes? Based on the idea that the Agile-Stage-Gate model is an alternative to this challenge, this study investigates the application of this hybrid model in two large Brazilian companies by presenting their idiosyncrasies, lessons learned, adaptations, challenges and benefits.

Overall, it was observed that the experience with the application of the Agile-Stage-Gate model is positive for these companies, with better customer engagement, easier project control and increased productivity of the project team.

Originality/value

For those aiming to implement the Agile-Stage-Gate model, this paper identifies the main adaptations made in order to combine the purist approaches and critical success factors for its implementation.

• Agile-Stage-Gate
• Innovation process
• Operational process improvements
• Process improvement methods
• Business processes improvements

Rehder, A. , Souza, J.V. , Marx, R. and Salerno, M.S. (2023), "Emerging field or passing fashion? A case study of Agile-Stage-Gate model in innovation processes", Revista de Gestão , Vol. 30 No. 4, pp. 362-386. https://doi.org/10.1108/REGE-08-2021-0149

Emerald Publishing Limited

Copyright © 2023, Adriano Rehder, João Valsecchi Souza, Roberto Marx and Mario Sergio Salerno

Published in Revista de Gestão . Published by Emerald Publishing Limited. This article is published under the Creative Commons Attribution (CC BY 4.0) licence. Anyone may reproduce, distribute, translate and create derivative works of this article (for both commercial and non-commercial purposes), subject to full attribution to the original publication and authors. The full terms of this licence may be seen at http://creativecommons.org/licences/by/4.0/legalcode

1. Introduction

Based on the idea that the application of the so-called Agile-Stage-Gate hybrid model has been an increasing alternative used by companies in their innovation processes ( Cooper, 2021 ), we used this approach as a basis for discussing how to apply Agile practices in the specific context of the development of business process innovations. The Agile-Stage-Gate model is a hybrid one for the product development process combining values and tools of the Agile project management approach with the traditional Stage-Gate (SG) innovation process ( Cooper, 2016 ). Because both models work with seemingly contradictory assumptions and conceptions, it has been agreed to consider the Agile-Stage-Gate model as a hybrid one.

The objective of the Agile-Stage-Gate model is to contribute to improving the performance of the product development processes. The justification for better performance is precisely in the combination of flexibility, speed and productivity, all attributes often associated with the Agile approach, with focus, structure and control, which are characteristics of the Stage-Gate model ( Cooper, 2016 ; Cooper & Sommer, 2018 ; Sommer, Hedegaard, Dukovska-popovska, & Steger-Jensen, 2015 ).

The discussion on Agile methods had its origin in the software industry ( Cooper, 2016 ). Several specialists, each one with a specific trajectory in software development models (e.g. Scrum, Extreme Programming), gathered themselves and condensed the common values and principles of their methodologies ( Dyba & Dingsøyr, 2008 ). The result of these interactions is expressed in the Manifesto for Agile Software Development, a document comprising a mindset with values and principles of Agile project management ( Beck et al. , 2001 ).

Serrador and Pinto (2015) identified the existence of a positive relationship between the application of these approaches and a project’s successful outcome. Complementarily, Bianchi, Marzi, and Guerini (2018) investigated the combination of Agile and traditional practices in software development projects and concluded that, specifically for the software industry, the pure Agile approach is always more effective than the traditional (e.g. Stage-Gate) and hybrid (e.g. Agile-Stage-Gate) ones.

In the wake of the successful implementation of these methods in the software industry, the traditional manufacturing industries have also started experiments by incorporating these principles and applying Agile practices to their product development processes ( Conforto, Salum, Amaral, Silva, & Almeida, 2014 ; Sommer, Dukovska-popovska, & Steger-jensen, 2014 ). Large European IT companies which produce and trade hardware and software products started the hybridization of the methods by applying Agile practices to their traditional Stage-Gate processes. It was found that the hybrid model could offer good results, such as improvement of internal communication, more efficient planning and better customer feedback ( Karlström & Runeson, 2005 ).

Sommer et al. (2014) observed an increased performance of R&D processes in German manufacturing companies after they applied such a hybrid combination. The authors highlighted the following benefits from applying this method: gain of flexibility in the process, more efficient communication among the teams, a gain of productivity in the process, including during task prioritization and improvement in the team’s motivation. Cooper (2021) also highlighted the gain of speed in the execution of innovation management processes with the application of the Agile-Stage-Gate model.

In this way, several authors sought to study practical cases in which the Agile-Stage-Gate model was applied beyond the development of software. In fact, studies on large industries with more than 1,000 employees ( Brock, den Ouden, Langerak, & Podoynitsyna, 2020 ; Cooper & Sommer, 2018 ; Salvato & Laplume, 2020 ; Sommer et al. , 2015 ) as well as on small ones with up to 100 employees and medium ones with up to 1,000 employees ( Conforto & Amaral, 2016 ; Edwards, Cooper, Vedsmand, & Nardelli, 2019 ; Hirisatja, Surachaikulwattana, & Lohwongwatana, 2021 ) have been performed to assess the Agile-Stage-Gate model in the context of physical product development. Despite the increasing number of studies investigating the application of Agile methods to physical product development processes, this phenomenon continues being predominantly addressed in the scope of software development projects ( Conforto et al. , 2014 ; Ovesen, 2012 ; Serrador & Pinto, 2015 ). This is justified primarily due to the fact that physical products are difficult to be prototyped, tested and rapidly adjusted as they often depend on the structural adequacy of production lines and machinery used throughout the project management, which restricts the range of the studies with this focus ( Cooper, 2016 ). As stated by Cooper and Sommer (2018) , the hybrid model for physical product manufacturers is still a novelty and companies are learning how to use it in practice. According to the authors’ best knowledge, however, no study on the application of the Agile-Stage-Gate model to improve business processes, here understood as a chain of coordinated activities to produce a product or a final service (Zarifian, 1994 as cited in Salerno, 1999 ), was found in the literature.

As a result, the benefits of applying the Agile-Stage-Gate model to innovation development not related to IT are backed in a few cases reported in the literature ( Granato, Fischer, & van Trijp, 2022 ) and always from the perspective of producing final physical products rather than implementing business process improvements. In view of this, more evidence are necessary to evaluate the characteristics of the hybrid model, its benefits and its drawbacks, especially in the context of the implementation of business process improvements.

Therefore, the present study raises the following research question: how are large companies applying the elements of Agile methods to their development of business process improvements? One seeks to investigate which advantages and disadvantages are perceived with the application of the Agile-Stage-Gate model and which adaptations were made in order to conciliate the contradictions inherent to the pure models of project management.

By means of a study of multiple cases, this work sheds light on the application of the Agile-Stage-Gate model in large-sized companies which generate and implement business process improvements to enhance its operational efficiency. We expect to contribute to improving the understanding and spread of the knowledge acquired with empirical experiences in adopting hybrid processes of innovation development, thus collaborating with meeting the still open gap in the emerging literature on the advantages and disadvantages of using Agile methods in the context of innovation projects development not related to software development, as well as with improving the current application of Agile-Stage-Gate model in companies by contributing to managerial practice.

2. Theoretical background

2.1 stage-gate model.

The Stage-Gate model is similar to the classical innovation management models reported in the literature (see Clark & Wheelwright, 1992 ; Goffin & Mitchell, 2005 ; Hansen & Birkinshaw, 2007 ) and covers a process of product development. This model is notoriously one of the most applied to product development processes by companies. This development emerges from a sequence of activities (stages) preceded by a decision point (gate), which defines whether an idea/project follows in the wake of the development, is cancelled or frozen ( Cooper, 1994 ).

This is a model which organizes the collection of information about a given project and systematically seeks validations as a way to reduce the risks as the product development project progresses. Figure 1 shows an illustrative view of the Stage-Gate process.

From the point of view of the organizational processes, the Stage-Gate model presupposes the existence of scale and standardization throughout the development of innovation ideas and projects. Therefore, these processes are more oriented toward the development of incremental innovations as this type of innovation requires a reduction of costs or improvement of the characteristics of the existing products and services.

In this sense, this model is more applicable in the context of little or no uncertainty, in which it is possible to obtain quantifiable knowledge on a possible future incident impacting the development of an idea or project, thus being more aligned with the notion of risk management rather than of uncertainty management ( Knight, 2014 ).

In effect, these models do not help define an approach to be applied in the context of more radical innovation ( Silva, Bagno, & Salerno, 2014 ), since different situations can impose a break in the pre-defined sequence of activities due, essentially, to their high level of uncertainties.

Similarly, Salerno, Gomes, Silva, Bagno, and Freitas (2015) criticized the One-Size-Fits-All approach of these innovation models. The authors define eight different types of variations in the innovation process depending on the contingencies of each project. Of these eight models, three have interruptions in the activity flow and a process break resulting from the emergence of market or technology uncertainties, which demand a different management approach and cannot be addressed only in the procedural framework.

Despite these limitations, generic models of innovation processes in general and the Stage-Gate model, in particular, continue being widely cited in the literature and used in the industry for the management of incremental innovation projects. Therefore, new variations of this model, such as adaptation and incorporation of Agile methodologies, are a relevant object of study for discussion on the best ways of managing product development.

2.2 Agile methodologies and scrum

2.2.1 agile methodologies.

There are several alternative methodologies for code development and project management in the software industry questioning the efficacy of the traditional project management methods in generating value for customers. The high cost of controlling changes throughout the project development has been the issue addressed by these methodologies ( Highsmith & Cockburn, 2001 ).

Agile methodologies are differentiated from the traditional project management approaches, such as cascade management, in that they emphasize characteristics like continuous design, flexible scope, freezing of design specifications as late as possible, openness to uncertainties, interaction with customers and a different team organization. In addition, Agile methodologies are interactive and incremental as they seek to avoid standard approaches emphasizing anticipated design, freezing of specifications, fixed project scope and low interaction with the customer ( Serrador & Pinto, 2015 ).

Boehm and Turner (2003) highlighted and contrasted the most specific aspects of the Agile and classical/plan-oriented methodologies, as can be seen in Table 1 .

The objective of this comparison is to show that there are preconditions in a project context indicating which management approach can be the most adequate. For example, if the project context is dynamic (i.e. many needs for changes), having less people in the team and an environment in which the culture of freedom and informality is valued, then the project management method is likely to be a more effective option with the Agile approach than with the traditional one. According to the authors who compared these approaches, a previous evaluation of the project context and its characteristics would be, therefore, a useful exercise for the selection of the most adequate approach.

Individuals and interactions over processes and tools;

Working software over comprehensive documentation;

Customer collaboration over contract negotiation;

Responding to changes over following a plan.

To some extent, this set of values determines a relationship of priority between them as, for example, interactions with individuals facilitate the sharing of information and rapid response to changes when necessary. In the same way, it is possible to infer that working software increments allow to measure production speed and accelerate feedback about it. Collaboration with the customer encompasses the idea that all share the same final objective. In turn, the close participation of the customer makes responses to changes easier and speeds up the feedback about the work done. In this sense, it is important to accept that changes will occur, meaning that efforts with planning should be calibrated for a shorter horizon in order to avoid spending time planning deliveries which may become eventually obsolete.

Agile methodologies, however, are subject to several criticisms. Among them, one can cite: Agile development brings nothing significantly new as it had already been practised in the software industry in the 1960s (Merisalo-Rantanen et al. , 2005 as cited in Dyba & Dingsøyr, 2008 ); lack of focus on architecture planning leads to non-optimized design decisions (Stephens & Rosenberg, 2003 as cited in Dyba & Dingsøyr, 2008 ); there is scarce scientific support for the assertions by the Agile community (Mcbreen, 2003 as cited in Dyba & Dingsøyr, 2008 ); and Agile methods work in the contexts of small project teams, whereas in the contexts of larger projects, other approaches are more appropriate (Cohen et al. , 2004 as cited in Dyba & Dingsøyr, 2008 ).

Nevertheless, perhaps the main criticism of the Agile methods is that the term “Agile” has been often used for exclusively marketing purposes and in a prescriptive way rather than for enabling the implementation of a really flexible and adaptive approach according to the context to which they are applied ( Fernandez & Fernandez, 2008 ).

Even recognizing that Agile methods are not applicable to all types of projects, some authors admit that such practices are valued for managing projects characterized by high complexity, high volatility or unclear objectives and solutions ( Fernandez & Fernandez, 2008 ). Consequently, these conditions for contexts of software development projects allow authors like Bianchi et al. (2018) to conclude that a pure Agile approach is always more effective for software companies than plan-oriented (Stage-Gate) or even hybrid (Agile-Stage-Gate) ones.

One can observe, therefore, vast evidence of the successful application of Agile methods to project management in the software industry. However, in addition to this, there are only a few studies exploring the use of Agile project methods by industries not related to IT ( Conforto et al. , 2014 ; Cooper & Sommer, 2018 ).

2.2.2 Scrum

Scrum, on the other hand, is an Agile methodology with a focus on project management, especially those of difficult future planning. It is a framework aimed to help people cope with complex project problems by means of iterative and incremental approaches in order to optimize predictability and risk control. Scrum has a set of practices which make all the project’s aspects visible to the team, thus allowing all its members to know how the project is evolving and, if necessary, to make corrections ( Schwaber, 2004 ; Schwaber & Sutherland, 2017 ).

Sprint Planning;

Daily Scrum;

Sprint Review;

Sprint Retrospective

Product Owner (PO);

Scrum Master (SM);

Development Team (Dev Team).

Product Backlog;

Scrum Board/Kanban Board;

Burndown Chart.

2.3 Hybrid Agile-Stage-Gate model

Lastly, in the hybrid Agile-Stage-Gate model, the elements of the Stage-Gate approach are associated with the principles of Agile methodology in order to combine the benefits of flexibility and adaptation toward changes, associated with the use of Agile methodologies, and the standard, structured and scalable process of Stage-Gate-related innovation development ( Cooper, 2016 ; Cooper & Sommer, 2018 ; Sommer et al. , 2015 ).

Karlström and Runeson (2005) , seeking to understand how large IT companies could incorporate Agile software development practices in their already established Stage-Gate processes, achieved an important insight by conducting a case study of three IT companies. Agile methods contribute to the Stage-Gate model by proving more granular planning and control of daily activity. In other words, both methodologies are combined into different levels of control, that is, at the aggregate/macro level one uses the Stage-Gate model and at the granular/micro level one uses Agile practices to replace technical models of project processes.

Sommer et al. (2015) investigated how manufacturing companies use this hybrid model and they developed a generic process framework representing graphically the combination of these methodologies. Figure 2 illustrates the generic phases of the hybrid model.

The Agile-Stage-Gate model embeds the Agile practices in its Stage-Gate macro phases for micro-planning by replacing the traditional tools and approaches of project management such as Gantt charts, critical path analysis, among others. And the Stage-Gate approach, at the macro level, provides means to coordinate several teams with different functions with the company’s senior management ( Bianchi et al. , 2018 ; Cooper, 2016 ; Edwards et al. , 2019 ).

There are studies conceptualizing the Agile-Stage-Gate model differently. Granato et al. (2022) present a variation in the model by defining a method for the systematic identification of conceptual divergences between the product development technical staff and potential customers. This method, which combines Stage-Gate techniques and Agile iterative approaches, contributes to identify and treat such divergences before the final phase of the innovation production.

Žužek, Kušar, Rihar, and Berlec (2020) added the theme of concurrent engineering literature to the discussion on Agile-Stage-Gate. Instead of working in sequential steps at the macro management level (Stage-Gate), one works with a degree of superposition of steps.

However, for the purposes of the present analysis, we worked on the general idea of the Agile-Stage-Gate model presented by Karlström and Runeson (2005) , which is graphically represented in the study by Sommer et al. (2015) , as shown in Figure 2 .

Still, with regard to the Agile-Stage-Gate model for contexts not related to software development, there are authors addressing the hybrid model from the perspective of its implementation. Zasa, Patrucco, and Pellizzoni (2020) , interviewing Agile coaches with experience in implementing Agile methods in traditional companies, and Albuquerque, Torres, and Berssaneti (2020) , studying Agile practices in the construction industry, observed that there is an important cultural factor which must be overcome in order to implement a hybrid model, namely, lack of knowledge and leadership resistance to the Agile approach. The same difficulty is found in case studies on the Agile-Stage-Gate model ( Cooper & Sommer, 2018 ; Salvato & Laplume, 2020 ; Sommer et al. , 2015 ). Silvério, Trabasso, and Pereira Pessôa (2020) also highlight that leadership is important for the implementation of lean practices in productive processes.

Improvement of time-to-market ( Cooper, 2016 ; Cooper & Sommer, 2018 ; Edwards et al. , 2019 ; Salvato & Laplume, 2020 );

Increase in the team’s productivity ( Brock et al. , 2020 ; Cooper, 2016 ; Cooper & Sommer, 2018 ; Salvato & Laplume, 2020 ; Sommer et al. , 2015 );

Quicker response to market changes ( Brock et al. , 2020 ; Cooper, 2016 ; Cooper & Sommer, 2018 ; Salvato & Laplume, 2020 ; Sommer et al. , 2015 );

Higher motivation of the team ( Cooper, 2016 ; Cooper & Sommer, 2018 ; Edwards et al. , 2019 ; Salvato & Laplume, 2020 ; Sommer et al. , 2015 );

Better internal communication ( Cooper, 2016 ; Edwards et al. , 2019 ; Salvato & Laplume, 2020 ; Sommer et al. , 2015 );

Better capture of customer feedback ( Cooper, 2016 ; Edwards et al. , 2019 ; Salvato & Laplume, 2020 );

Better synchronization between projects ( Edwards et al. , 2019 ; Salvato & Laplume, 2020 );

Higher levels of innovation ( Salvato & Laplume, 2020 ).

Difficulty to allocate fully dedicated resources ( Cooper, 2016 ; Edwards et al. , 2019 ; Sommer et al. , 2015 );

Costs with fully dedicated resources/structure and resources for synchronization of projects ( Salvato & Laplume, 2020 );

Lack of Agile culture in the organization/resistance ( Cooper & Sommer, 2018 ; Salvato & Laplume, 2020 ; Sommer et al. , 2015 );

Method for evaluation of allocated resources ( Sommer et al. , 2015 );

Difficult to keep the team physically close together ( Edwards et al. , 2019 );

Evolution of the product design with flexible backlog (time, in the process, for freezing the design specifications) because adjustments of specifications are more complex for physical products than for software, as the latter requires re-writing codes only ( Brock et al. , 2020 ; Edwards et al. , 2019 ; Salvato & Laplume, 2020 );

Materiality of the product in the sprint, since physical products are not easily dismembered into independent parts and their production is more complex (requiring materials and manufacturing infra-structure) than the development of software ( Cooper & Sommer, 2018 );

Keeping the frequency of Daily Scrum meetings ( Cooper, 2016 ; Edwards et al. , 2019 );

Redundancy of synchronization tools and reports of projects (no Agile-Stage-Gate is applied, but Agile methods are added to Stage-Gate) ( Salvato & Laplume, 2020 ).

Adjustments to agreements on results in the sprint. For physical products, it is more complex (compared to software) to prepare their delivery at the end of the sprint, meaning that partial deliveries should be agreed based on plans or concepts of prototypes ( Cooper, 2016 ; Edwards et al. , 2019 );

Functions of facilitators in spreading the Agile mindset within the company to make implementation easier ( Cooper & Sommer, 2018 ; Salvato & Laplume, 2020 );

Variations in the sprint length for adequacy of the delivery of a physical product ( Edwards et al. , 2019 ).

It is worth mentioning that, supposedly, it is possible to apply Agile practices to all steps of the Stage-Gate process, according to the framework shown in Figure 2 . According to the case studies evaluating how manufacturing companies apply the Agile-Stage-Gate approach, totalizing 23 cases, the majority used Agile methods in all Stage-Gate steps. Table 2 lists the relation of cases by Agile application to the steps of the Stage-Gate process, as found in the literature.

3. Methodology

3.1 definition of the research method.

To observe empirically the relationship between the above-mentioned concepts, we adopted a qualitative approach based on a multiple-case study.

Voss, Tsikriktsis, and Frohlich (2002) state that a case study, as a research method, should be used when a phenomenon needs to be studied in its actual environment so that all the complexities involved can be clearly understood, mainly in the context of operation management.

McCutcheon and Meredith (1993) show that a case study considers observation, deep examination and evaluation of one or more external objects, with the researcher having little control of the events surrounding them. However, its application to operation management presents restrictions because the lack of control of variables can limit the observation of the results. In this sense, because the case study method follows a bottom-up approach for building knowledge from real and particular situations, there is the risk of producing narrow or very little generalizable theories ( Eisenhardt, 1989 ).

Taking into consideration that the application of hybrid models, which combine the principles of the Stage-Gate approach with those of Agile methodologies, is still little widespread in the real environment where it is practised, the case study is shown to be adequate as it allows deep analysis of the contexts where it is possible to observe its use as well as of the theoretical implications from the selected cases.

3.2 Presentation of cases

For the squad to work, it has to be inserted in a Stage-Gate context for managing improvements/innovations in the company; and

The scope of the squad’s work should be aimed at implementing business process innovations which are not related exclusively to software development.

As the phenomenon investigated is little widespread, according to the author’s knowledge, the selection of companies followed an information-oriented approach. That is, the companies were selected based on the expected information provided by them ( Flyvbjerg, 2006 ). In this way, from the authors’ previous experience, two companies well-known to meet the selection criteria were added: a financing multinational company and a telecommunication multinational company. Table 3 summarizes the companies’ characteristics and presents a brief context on how the hybrid model is used in each one for implementing innovation processes.

3.3 Data analysis and collection

The main data used in the present study were collected by semi-structured interviews with professionals directly involved in the Agile-Stage-Gate process. There were two moments of interaction with each interviewee. The first interaction occurred during an interview aimed at better knowing in detail how the Scrum method was applied to projects for the improvement of business processes. These interviews lasted 2–3 h, on average. Next, a summary of the content was emailed to the interviewees so that they could validate the information given. The interviews were recorded if the interviewee allowed.

The interview was divided into two phases. Initially, data on the interviewee’s professional profile (i.e. function, responsibilities, among others), context and motivators for using Scrum to improve projects for processes/products and squad on which the interviewee acted were collected (i.e. name, scope, duration, among others).

The second phase was guided by a script of questions divided into three scopes. Initially, it was sought to understand the steps of the Stage-Gate process to identify, select, develop and implement improvements. Next, the particularities of the Scrum method applied were investigated, including similarities and adaptations in relation to the Scrum described in the literature and steps in which it occurred during the Stage-Gate process on a macro level. Lastly, questions were asked in order to capture the interviewee’s critical view on the use of Scrum and hybrid Agile-Stage-Gate methods.

The full script of questions can be obtained from Supplementary Material 1 , whereas the interviewee’s profile and general characteristics of the squads can be found in Supplementary Material 2 .

After conducting the interviews, the content of the records was transcribed, tabulated and codified ( Nowell, Norris, White, & Moules, 2017 ). In Supplementary Material 3 , one can find a non-exhaustive example of how the data collected were codified. The scope of the answers given by the interviewees and the themes present in the interview script are in the first level of codification, whereas the answers given by each interviewee and the application of codification are in the other levels.

After the codification exercise, the codified content of the interviews was critically read for identification of repetitions, convergence and divergence between the cases before being compared to the concepts addressed in the literature on Scrum and Agile-Stage-Gate.

4. Results and discussion

4.1 results of the financing company, 4.1.1 stage-gate characteristics.

In the financing company, there is no formal improvement implementation process in the conventional Stage-Gate format. Notwithstanding, there is one for generating, selecting, developing and implementing incremental improvements. This process exists despite not being necessarily formalized and whose practices vary depending on the internal customer’s demands.

Generation and Selection of Ideas

The annual strategic planning by the executive board sets objectives and broad goals for each surperintendency – the internal customer for the Agile-Stage-Gate Squads. The superintendents, in turn, refine their objectives and assign quantitative goals to them (Objectives and Key Results – OKRs). The superintendents’ evaluation of their OKRs determines the priority order for the annual objectives, which then become an ordered list of projects to be carried out.

Moreover, there is an additional source of ideas for business process innovation. The superintendency responsible for customer experience has assessment tools (i.e. Net Promoter Score) which constantly measure the user’s experience. Negative variations in these indicators generate improvement proposals.

Scope Refinement

With the list of prioritized projects in hand, the superintendents articulate with the internal project office the formation of the squad by passing an initial version of the work scope to be followed in the year.

Development and Tests

Implementation

Implementations vary with the type of delivery, but they are performed under the Scrum method. There are cases in which sprints are used to carry out training for internal customers, even including temporary monitoring of the operation under the new improved processes. There are also cases in which implementation is limited to presenting and delivering documents.

4.1.2 Agile characteristics

About the stages, it is observed that the agile practices performed in this company under the Scrum method occur in the phases of development/tests and implementation.

With regard to the sprints, they last from 2 to 4 weeks depending on the squad. The number of weeks is defined at the beginning of each sprint and can be adjusted, such as the addition of further weeks when one realizes that the number of weeks planned will not be enough for the due delivery.

Concerning the ceremonies, all squads perform planning, daily and review. Some squads sometimes do not perform retrospectives. As for the artifacts, the squads manage the backlog by using agile project management software as well as a burndown chart. Some squads, complementarily, rely on traditional tools for project management (e.g. Gantt chart) as a means to plan and control activities on the micro level. However, this application occurs in the final sprints, that is, when one has less complexity and more visibility of the expected activities. There are squads using the Kanban board in physical and digital forms, or even both, simultaneously.

Regarding the team, no squad has more than nine members. Overall, all have a product owner (PO) from the internal customer area and a SM from the project office, but a few have a fully dedicated PO. The Dev Team consists of one solution architect (with an IT profile), who accounts for the activities of automation programming, and process engineers and process analysts. These professionals belong to the project office. Still, the Dev Team is completed by internal customer analysts as well as by analysts from other areas (e.g. legal, sales or product). Most of the squads have full-time teams despite the fact that a few have them physically close.

Documentation exists when the deliverable refers to the process of re-design. When automation functionally is involved in the delivery, documentation is scarce.

4.1.3 Interviewee’s critical view of the hybrid model

Concerning the advantages, the most relevant ones refer to Scrum, namely: (1) engagement of the internal customer with the project, since he or she is physically close; (2) visual management (Kanban board), which facilitates visualizing the progression of the activities; and (3) perception of having more recurrent deliveries. The development delivery time was not reduced, but the practice to create recurring deliveries (even intermediary ones) at a shorter time generates a favourable perception by the internal customer area.

As to the disadvantages of Scrum, on the other hand, it is worth highlighting the following: (1) difficulty regarding the squad’s dependence on other internal areas (e.g. IT, sales and channels) which do not have dedicated resources. Conflicts and potential delays occur when the squad depends on others out of it; (2) lack of documentation for IT deliveries; and (3) feeling of concern among the Dev team members who do not belong to the project office regarding the assessment of their performance. In general, these people like being involved in the squad dynamics, but whenever the squad enters the final phase they become worried for fear of having their performance affected as they spend a relatively long time far from the direct supervision of their original managers in the organization’s structure.

Concerning the Stage-Gate itself, the following was highlighted: the steps of generating and selecting improvement projects could be refined in terms of strategic alignment. There is a feeling that the list of projects generated from the internal customers would not be optimized in terms of value creation, and that the squad’s scope would be aimed at the PO’s personal corporate objectives rather than covering broader initiatives of higher added value for the internal customer area and the organization as a whole.

As for whether the organization could use the pure Agile method only, both interviewees did not believe so. The organization is not prepared to work with the Agile model because it is very hierarchical, which makes the decision-making process slower. Notwithstanding, it was emphasized that there are opportunities to improve the Stage-Gate steps.

As for the adaptations made in the model, the following are highlighted: (1) members of ad hoc teams from other areas of the bank are temporarily incorporated, but fully dedicated, to the Dev Team for some sprints (e.g. legal and business areas giving resources for temporary participation in the squad). Another adaptation is (2) articulation and validation of deliveries to internal customers’ middle management by performing two sprint review ceremonies. In practice, one with internal customer middle management and the other with the senior management.

The dynamics of Stage-Gate and of the eight squads vary a lot and its success is strongly dependent on the influence of the internal customer on his or her superiors and on his/her engagement with the squad. When the internal customer has influence and is engaged, the squad has a fully dedicated team as a result, meaning that the Dev Team can stay physically close, conduct projects with higher added value, make Scrum ceremonies with more rigour and have fewer conflicts in the relations of dependence on other areas of the company. If there is no engagement and influence, the perception is that the squad performance decreases considerably regarding these requirements.

4.2 Results of the telecommunication company

4.2.1 stage-gate characteristics.

The annual strategic planning by the vice-presidency sets objectives and key results (OKRs). These objectives are unfolded into purposes of improvement projects, which then become squads. Therefore, the decision of selecting priority projects is taken at the executive board level.

Once the themes as well as POs and SMs of each squad are defined, they initiate an investigation phase (inception) in the internal customer departments. Information is raised, workshops performed and people interviewed to obtain more details of the scope and backlog defined for each theme worked on by the squad. These activities do not follow the Scrum method.

Implementations vary with the type of delivery, but they are performed under the Scrum method. For simple deliveries, review ceremonies are enough, whereas, for deliveries with significant changes in processes, training is planned and performed often with external support from Agile coaches. This training is given to the internal customer area whose processes are being improved as well as to HR business partners, representatives responsible for maintaining the improved process in the internal customer areas. Once the squad is terminated, the resources given are returned to their original functional areas.

4.2.2 Agile characteristics

The application of Agile practices, represented in this company by the Scrum method, occurs in the stages of development and implementation of the incremental innovation process.

The sprints vary from 3 to 4 weeks, being subject to changes (i.e. addition of further weeks) if there is a delay in the delivery.

As for the ceremonies, the four ones prescribed in the Scrum method are applied. Artifacts, backlog and burndown are recorded, controlled and shared through Agile software. Kanban board is physical and occupies a significant part of the Squad room’s walls. No traditional project management practices or tools are used.

All the teams have up to nine members, with the majority of the resources being provided by the HR sub-areas and others being hired or re-allocated from functional areas external to the HR vice-presidency.

There are squads with a scope of process improvements only, with no IT technical profile. The Dev Team’s members are HR analysts specialized in performing some functional processes to be improved. Each squad has its own room, where they work together. Two squads have a fully dedicated team, whereas two others work three days a week for the squad and two days for their original functional areas.

In addition to Dev Team, PO and SM, the squads also count on an executive sponsor and a supporting manager specialist in the process being re-designed, both on a consultant basis. These roles are aimed at supporting the hybrid model by minimizing resistance and acting on the communication between the squad and the top leadership of the company. Lastly, there still exists a supporting structure of Agile coaches external to the squads who give support by providing methodologies for ceremonies conduction, organization of external visits to the squads and, essentially, organization of weekly meetings among squad leaders and internal customer area managers for progress reporting, projects synchronization and expectations alignment.

As to documentation, improved process guides are presented, but without detailing IT aspects of the delivery.

4.2.3 Interviewee’s critical view of the hybrid model

The telecommunication company’s model is not only new, but also was born without a former reference model. A clear feeling of overall motivation regarding the new model in the HR area was observed during the data collection, both in the team and frequent visitors from other areas interested in knowing the hybrid model. Nevertheless, due to the recent history and lack of references for comparison, an assessment of the positive/negative issues was not considered viable in face of the previous experiences. Despite this, an evolution of the model since its establishment was reported, in addition to challenges inherent to the process, both interrelated.

Evolution and challenges refer to the form of obtaining resources for the squad. In the beginning, the personnel allocated to the squad were defined by the executive board in the macro phase of the generation and selection of ideas. The executive directors, when defining the themes for the squads, also already determined the name of the members without consulting managers and coordinators of the areas from which the resources were being allocated. This ended up creating conflicts with low- and medium-level managers, who had their resources suppressed due to the re-allocation of members from their original positions to work in the squads.

In view of this impasse, the executive directors now determine only PO and SM under the current model. Therefore, PO and SM are the ones meeting with the internal customer's manager and negotiating the re-allocation of members of the team to work in the squad. The challenge is to engage this manager to allow the re-allocation of members, but it was highlighted that the decrease in conflicts regarding the prior model allows more harmonious management dynamics, thus generating more benefits for all parties involved.

4.3 Discussion

Both companies are applying Agile methods (Scrum) in association with a Stage-Gate innovation process, although it may not be fully formalized or standardized yet. Concerning the Stage-Gate level, one can observe that, in both cases, there is a protagonism of the top leadership in the initial stages and gates of the process. The top leadership is highly involved in the prioritization of projects and negotiation of resources for squad formation. At the Scrum level, both companies apply the four ceremonies (i.e. sprint planning, daily scrum, sprint review and sprint retrospective), use the three artifacts (i.e. product backlog, Kanban board and burndown chart), in addition to having three roles (i.e. product owner, scrum master and dev team), very consistent to what is recommended in the Scrum literature.

Nevertheless, differently from the generic Agile-Stage-Gate model by Sommer et al. (2015) and from the majority of the cases studied in which Scrum is applied to all stages of the innovation process, in the companies here analyzed the Scrum model was applied to the final stages only (i.e. development/tests and implementation). Activities related to the generation and validation of the hypotheses of ideas, including data collection to enrich and refine the ideas, data collection to develop a viability analysis of the ideas and even prototyping of ideas, which could be performed by applying the Agile iterative model, do not use the Scrum principles. These are precisely the front-end steps of innovation presenting more uncertainties, which could benefit from the application of the iterative, incremental and adaptable method typical of the Agile approach.

A possible explanation of such a finding is the size and high hierarchy of the companies analyzed, according to data collected from the financing company, for instance. Cultural aspects can also have some degree of influence on this aspect since the resistance to Agile practices is frequently cited as one of the main challenges to their implementation ( Albuquerque et al. , 2020 ; Cooper & Sommer, 2018 ; Salvato & Laplume, 2020 ; Sommer et al. , 2015 ; Zasa et al. , 2020 ).

Adequacy of the amount of weeks in the sprint due to the possible delays. The original model recommends a fixed number of weeks for each sprint to exclude the risk of delay ( Schwaber, 2004 ). This adaptation was found in cases of Agile-Stage-Gate studied by Edwards et al. (2019)

The creation of the squad sponsor role (formal role in the telecommunication company and informal one in the financing company) at the executive level, facilitating the negotiation of the squad for external resources acquisition. The new role is aimed to reduce resistance and foster communication between the squad and top management. The original Scum model does not predict such a role ( Schwaber, 2004 ), but one can find references to these facilitators in the cases studied by Cooper and Sommer (2018) and Salvato and Laplume (2020)

The use of traditional methods (e.g. Gantt chart) to help planning and control activities. The original model does not recommend the sequential approach of comprehensive planning followed by execution ( Schwaber, 2004 ; Schwaber & Sutherland, 2017 )

Squads with partially dedicated and not physically close teams, adjusting themselves to business contingencies. The original model recommends fully dedicated and physically close teams in order to facilitate the conveying of information and adaptation to changes ( Cockburn & Highsmith, 2001 ; Schwaber, 2004 ), but one can observe that full dedication and physical proximity are two adherence challenges to the Scrum model which the Agile-Stage-Gate for physical products cases presents ( Cooper, 2016 ; Edwards et al. , 2019 ; Sommer et al. , 2015 )

The flexibility to enrich the composition of the squad with ad hoc teams participating with full dedication, but for some sprints only and

Two versions of the sprint review were executed. The first was the review to middle management of internal customer areas, for alignment and validation of deliveries; the second was the final/official review to internal customer's senior management. This made the approval process more complex but lowered the risk of falling short of internal clients’ expectations.

The literature on Agile-Stage-Gate for physical products points to the great difficulty not found in the cases studied: the issue of the product materiality. Differently from software, physical products have physical components which need to be purchased and/or produced and assembled; it is difficult to divide a physical product into incremental, independent and functional parts as one divides the lines of codes from software. Therefore, the delivery of an increment of the functional product after a sprint becomes much more sophisticated when intangible products are not involved. In this sense, the companies implementing the Agile-Stage-Gate model for physical product innovation had to adapt to it by working on incremental deliveries with prototypes, concepts and presentations ( Brock et al. , 2020 ; Edwards et al. , 2019 ; Salvato & Laplume, 2020 ).

As for business process improvements, however, the final deliveries are represented by procedures guidelines, training, presentations, dashboards, etc. These are artifacts which do not depend on physical components and can be sub-divided into independent and functional parts, as it occurs in cases of software development, the reason why the issue of incremental product materiality has not been highlighted in the cases studied.

Nevertheless, other attention points were mapped in the cases studied. Delivery delays potentially increase when the squad has a knowledge dependence on external resources. One can also highlight the issue of squad motivation and resource assessment since these resources are allocated from other functional areas to work for the squad under a temporary regimen. These resources play their roles for a period of time away from the direct orientation of the evaluating manager, which may create conflicts and tension regarding performance assessments compared to those colleagues who stayed in their original area.

Also, there is a criticism of the prioritization of projects defined by the top management as an initial orientation to the product backlog, which states that criteria for selecting projects would not be optimized. This supposed sub-selection of projects may be a by-product of the way the Agile-Stage-Gate model was implemented, in which more flexible, decentralized and participative Agile practices are not used in the initial steps of the innovation chain. These aspects, despite being contextual, can be didactic for managers who are investigating the viability of implementing hybrid models for business process innovation.

Even so, it is worth emphasizing that the hybrid model is well accepted by the companies analyzed. There is a perception regarding an intrinsic value to the Agile method in terms of aggregating productivity to the improvement development processes ( Brock et al. , 2020 ; Cooper, 2016 ; Cooper & Sommer, 2018 ; Salvato & Laplume, 2020 ; Sommer et al. , 2015 ), better engaging with customers ( Cooper, 2016 ; Edwards et al. , 2019 ; Salvato & Laplume, 2020 ), facilitating project management with visual tools ( Cooper, 2016 ; Edwards et al. , 2019 ; Salvato & Laplume, 2020 ; Sommer et al. , 2015 ) and creating a positive environment resulting from frequent deliveries with this model.

These findings also diverge from a recurrent criticism, consolidated in the study by Fernandez and Fernandez (2008) , which indicates that Agile methods have been poorly supported and being seen as project management panaceas or without value.

5. Conclusions

Agile methods are increasingly being applied to contexts not restricted to IT projects. Nevertheless, this phenomenon is still recent and there are a few empirical cases in the literature showing particularities of the application of the Agile-Stage-Gate hybrid model to the development of physical products ( Cooper & Sommer, 2018 ; Granato et al. , 2022 ), and, according to the authors’ best knowledge, no case presented and discussed on this application to business process improvements.

Therefore, the present study sought to understand how large companies are applying elements of the Agile method to their business process improvement methods, including which adaptations were made to conciliate the contradictions of both pure models and which advantages and disadvantages are perceived in this hybrid model.

In view of the cases analyzed, it was possible to understand that the application of the Agile-Stage-Gate method to business process improvements has a strong protagonism of the company’s top leadership in the initial stages of the innovation process, as there is centralization of the actions and no use of Agile practices, and the use of Scrum in the final stages, of development, tests and implementation. This evidence contrasts with those found by the majority of the case studies on the application of the Agile-Stage-Gate method to physical products, that is, the use of Scrum as a micro-planning tool for all stages of the innovation process.

The cases studies here also showed a series of adaptations to the classical Scrum model, which were made to adjust it to the context and necessities of the company and its innovation management processes as follows: flexibility in the number of weeks in a sprint, creation of new roles, sponsors and supporters of the squad, adequacy of dedications and localizations of the teams depending on the contingencies, application of classical project management practices associated with Scrum artifacts (i.e. use of Gantt chart), incorporation of fully dedicated ad hoc resources in the squad and limited to some sprints and conduction of two review meetings for testing the presentation of solutions before the final review. Most of these adaptations were also found in the literature on the application of the Agile-Stage-Gate method to physical product innovations.

Therefore, from the theoretical point of view, this study contributes to a better understanding of how Agile practices can be incorporated into contexts beyond the IT initiative or physical product development projects, thus supporting the systematization of a discussion which has already been faced by organizations. In this sense, our study reinforces the idea that some adaptive practices of Scrum are highlighted and, to some extent, are repeated in different contexts of the Agile-Stage-Gate application. These practices can guide managers to better adjust their implementation projects of hybrid models in their companies.

Concerning the advantages and disadvantages of the model, it was possible to observe benefits predicted in the literature on Agile-Stage-Gate application, such as better productivity, engagement of the customer and internal communication, in the companies analyzed. Challenges, such as the acquisition of resources, their performance assessment and full allocation to the squad were also found in the literature, indicating that some Agile premisses are difficult to be addressed in the Agile-Stage-Gate implementation context.

In this sense, some success factors were found and deserve the attention of managers interested in planning and implementing the Agile-Stage-Gate method in their companies, such as the importance of the Sponsor’s role in ensuring “traction” to the squad’s work. This makes it easy for the team to have more access to external resources or more quickly, besides reducing the resistance to the Agile mind-set within the company. Associated with this, there is the importance of promoting engagement of internal customer areas with which one negotiates the transfer of resources to the squad; and not underestimating the production of documentation on IT aspects of process improvements deliveries, which tend to be overlooked and poorly elaborated in this type of model.

Despite these challenges, the overall evaluation is that the hybrid model brings advantages to the traditional innovation development processes in the companies analyzed. This model allowed a greater involvement of the project team with the internal customer through facilitated management by visual tools and permanent sensation of productivity, thus demonstrating to be a promising field for further complementary investigations.

Lastly, by recognizing that the experiences from the application of the Agile-Stage-Gate model for innovation processes are still recent and little widespread in organizations, it is recommended that future case studies should diversify the size and localization of the companies being investigated. In addition, using more information sources to complement the interviews and incorporating a longitudinal study of these experiences so that the aspects suggested in the study can be examined in other contexts and more deeply addressed are also recommended.

Stage-gate model

Planning levels: agile-stage-gate at level 1 and scrum at level 2

Aspects of the agile and plan-oriented methodologies

Source(s): The own author

Albuquerque , F. , Torres , A. S. , & Berssaneti , F. T. ( 2020 ). Lean product development and agile project management in the construction industry . Revista de Gestao , 27 ( 2 ), 135 – 151 . doi: 10.1108/REGE-01-2019-0021 .

Beck , K. , Beedle , M. , Bennekum , A. V. , Cockburn , A. , Cunningham , W. , Fowler , M. , … Thomas , D. ( 2001 ). Manifesto for agile software development . Agile Alliance . Available from: https://agilemanifesto.org/

Bianchi , M. , Marzi , G. , & Guerini , M. ( 2018 ). Agile, stage-gate and their combination: Exploring how they relate to performance in software development . Journal of Business Research , 110 ( March 2020 ), 538 – 553 . doi: 10.1016/j.jbusres.2018.05.003 .

Boehm , B. , & Turner , R. ( 2003 ). Balancing agility and discipline_ A guide for the perplexed . Boston : Addison-Wesley Professional .

Brock , K. , den Ouden , E. , Langerak , F. , & Podoynitsyna , K. ( 2020 ). Front end transfers of digital innovations in a hybrid agile-stage-gate ® setting . Journal of Product Innovation Management , 37 ( 6 ), 506 – 527 . doi: 10.1111/JPIM.12556 .

Clark , K. B. , & Wheelwright , S. C. ( 1992 ). Structuring the development funnel . In Revolutionizing product development: Quantum leaps in speed, efficiency, and quality (pp.  111 – 132 ). Free Press .

Cockburn , A. , & Highsmith , J. ( 2001 ). Agile software development: The people factor . Computer , 34 ( 11 ), 131 – 133 . doi: 10.1109/2.963450 .

Conforto , E. C. , & Amaral , D. C. ( 2016 ). Agile project management and stage-gate model—a hybrid framework for technology-based companies . Journal of Engineering and Technology Management - JET-M , 40 , 1 – 14 . doi: 10.1016/j.jengtecman.2016.02.003 .

Conforto , E. C. , Salum , F. , Amaral , D. C. , Silva , S. L. da , & Almeida , L. F. M. de. ( 2014 ). Can agile project management be adopted by industries other than software development? Project Management Journal , 45 ( 3 ), 21 – 34 . doi: 10.1002/pmj .

Cooper , R. G. ( 1994 ). Perspective third-generation new product processes . Journal of Product Innovation Management , 11 ( 1 ), 3 – 14 . doi: 10.1016/0737-6782(94)90115-5 .

Cooper , R. G. ( 2016 ). Agile – stage-gate hybrids the next stage for product development . Research-Technology Management , 59 ( 1 ), 21 – 29 . doi: 10.1080/08956308.2016.1117317 .

Cooper , R. G. ( 2021 ). Accelerating innovation: Some lessons from the pandemic . Journal of Product Innovation Management , 38 ( 2 ), 221 – 232 . doi: 10.1111/jpim.12565 .

Cooper , R. G. , & Sommer , A. F. ( 2018 ). Agile – stage-gate for manufacturers changing the way new products are developed . Research-Technology Management , 61 ( 2 ), 17 – 26 . doi: 10.1080/08956308.2018.1421380 .

Dyba , T. , & Dingsøyr , T. ( 2008 ). Empirical studies of agile software development : A systematic review . Information and Software Technology , 50 ( 9-10 ), 833 – 859 . doi: 10.1016/j.infsof.2008.01.006 .

Edwards , K. , Cooper , R. G. , Vedsmand , T. , & Nardelli , G. ( 2019 ). Evaluating the agile-stage-gate hybrid model: Experiences from three SME manufacturing firms . International Journal of Innovation and Technology Management , 16 ( 8 ), 1 – 31 . doi: 10.1142/S0219877019500482 .

Eisenhardt , K. M. ( 1989 ). Building theories from case study research published by : Academy of management stable . The Academy of Management Review , 14 ( 4 ), 532 – 550 . doi: 10.2307/258557 .

Fernandez , D. J. , & Fernandez , J. D. ( 2008 ). Agile project management — agilism versus traditional approaches . Journal of Computer Information Systems , ISSN, 49 ( 2 ), 10 – 17 . doi: 10.1080/08874417.2009.11646044 .

Flyvbjerg , B. ( 2006 ). Five misunderstandings about case-study research . Qualitative Inquiry , 12 ( 2 ), 219 – 245 . doi: 10.1177/1077800405284363 .

Goffin , K. , & Mitchell , R. ( 2005 ). Innovation management: Strategy and implementation using the pentathlon framework . London : Palgrave Macmillan .

Granato , G. , Fischer , A. R. H. , & van Trijp , H. C. M. ( 2022 ). Misalignments between users and designers as source of inspiration: A novel hybrid method for physical new product development . Technovation , 111 ( September 2021 ), 102391 . doi: 10.1016/j.technovation.2021.102391 .

Hansen , M. , & Birkinshaw , J. ( 2007 ). The innovation value chain . Harvard Business Review , 85 ( 6 ), 121 – 130 .

Highsmith , J. , & Cockburn , A. ( 2001 ). Agile software development: The business of innovation . Computer , 34 ( 9 ), 120 – 127 . doi: 10.1109/2.947100 .

Hirisatja , T. , Surachaikulwattana , P. , & Lohwongwatana , B. ( 2021 ). The adoption of the agile-stage-gate model under contextual conditions of startups . Academy of Strategic Management Journal , 20 ( 5 ), 1 – 10 . ISSN: 1939-6104-20-S5-085 .

Karlström , D. , & Runeson , P. ( 2005 ). Combining agile methods with stage-gate project management . IEEE Software , 22 ( 3 ), 43 – 49 . doi: 10.1109/MS.2005.59 .

Knight , F. ( 2014 ). Risk, uncertainty and profit . Connecticut : Martino Fine Books .

McCutcheon , D. , & Meredith , J. ( 1993 ). Conducting case study research in operations management . Journal of Operations Management , 11 ( 1 ), 239 – 256 . doi: 10.1016/0272-6963(93)90002-7 .

Nowell , L. S. , Norris , J. M. , White , D. E. , & Moules , N. J. ( 2017 ). Thematic analysis: Striving to meet the trustworthiness criteria . International Journal of Qualitative Methods , 16 ( 1 ), 1 – 13 . doi: 10.1177/1609406917733847 .

Ovesen , N. ( 2012 ). The challenges of becoming agile. Imprementing and conducting scrum in integrated product development . Aalborg : Department of Architecture and Design, Aalborg University .

Salerno , M. S. ( 1999 ). Projeto de organizações integradas e flexíveis: Processos, grupos e gestão democrática via espaços de comunicação-negociação . São Paulo : Atlas .

Salerno , M. S. , Gomes , L. A. , Silva , D. , Bagno , R. B. , & Freitas , S. ( 2015 ). Innovation processes : Which process for which project . Technovation , 35 , 59 – 70 . doi: 10.1016/j.technovation.2014.07.012 .

Salvato , J. J. , & Laplume , A. O. ( 2020 ). Agile stage-gate management (ASGM) for physical products . R&D Management , 50 ( 5 ), 631 – 647 . doi: 10.1111/radm.12426 .

Schwaber , K. ( 2004 ). Agile project management with scrum . Redmond : Microsoft Press .

Schwaber , K. , & Sutherland , J. ( 2017 ). The scrum guide the definitive guide to scrum: The rules of the game . ScrumGuides Org . Available from: https://scrumguides.org/scrum-guide.html

Serrador , P. , & Pinto , J. K. ( 2015 ). Does agile work? — a quantitative analysis of agile project success . International Journal of Project Management , 33 ( 5 ), 1040 – 1051 . doi: 10.1016/j.ijproman.2015.01.006 .

Silva , D. O. D. , Bagno , R. , & Salerno , M. S. ( 2014 ). Modelos para a gestão da inovação: Revisão e análise da literatura . Production , 24 ( 2 ), 477 – 490 . doi: 10.1590/S0103-65132013005000059 .

Silvério , L. , Trabasso , L. G. , & Pereira Pessôa , M. V. ( 2020 ). A roadmap for a leanness company to emerge as a true lean organization . Concurrent Engineering Research and Applications , 28 ( 1 ), 3 – 19 . doi: 10.1177/1063293X19888259 .

Sommer , A. F. , Dukovska-popovska , I. , & Steger-jensen , K. ( 2014 ). IFIP international conference on advances in production management systems (APMS) . Agile Product Development Governance – On Governing the Emerging Scrum/Stage-Gate Hybrids (pp.  184 – 191 ). doi: 10.1007/978-3-662-44739-0_23 .

Sommer , A. F. , Hedegaard , C. , Dukovska-popovska , I. , & Steger-Jensen , K. ( 2015 ). Improved product development performance through agile/stage-gate hybrids : The next- generation stage-gate process . Research-Technology Management , 58 ( 1 ), 34 – 45 . doi: 10.5437/08956308X5801236 .

Voss , C. , Tsikriktsis , N. , & Frohlich , M. ( 2002 ). Case research in operations management . International Journal of Operations and Production Management , 22 ( 2 ), 195 – 219 . doi: 10.1108/01443570210414329 .

Zasa , F. P. , Patrucco , A. , & Pellizzoni , E. ( 2020 ). Managing the hybrid organization: How can agile and traditional project management coexist? Research Technology Management , 64 ( 1 ), 54 – 63 . doi: 10.1080/08956308.2021.1843331 .

Žužek , T. , Kušar , J. , Rihar , L. , & Berlec , T. ( 2020 ). Agile-concurrent hybrid: A framework for concurrent product development using scrum . Concurrent Engineering Research and Applications , 28 ( 4 ), 255 – 264 . doi: 10.1177/1063293X20958541 .

Corresponding author

Related articles, we’re listening — tell us what you think, something didn’t work….

Report bugs here

All feedback is valuable

Please share your general feedback

Join us on our journey

Platform update page.

Visit emeraldpublishing.com/platformupdate to discover the latest news and updates

Questions & More Information

Answers to the most commonly asked questions here

For enquiries call:

+1-469-442-0620

Agile Case Studies: Examples Across Various Industires

Home Blog Agile Agile Case Studies: Examples Across Various Industires

Agile methodologies have gained significant popularity in project management and product development. Various industries have successfully applied Agile principles, showcasing experiences, challenges, and benefits. Case studies demonstrate Agile's versatility in software development, manufacturing, and service sectors. These real-world examples offer practical insights into Agile implementation, challenges faced, and strategies to overcome them. Agile case studies provide valuable inspiration for implementing these methodologies in any project, regardless of the organization's size or industry.

Who Uses Agile Methodology?

Agile methodology is used by a wide variety of organizations, including:

• Software development companies use Agile to improve collaboration, increase flexibility, and deliver high-quality software incrementally.
• IT departments use agile to manage and execute projects efficiently, respond to changing requirements, and deliver value to stakeholders in a timely manner.
• Startups use agile to quickly adapt to market changes and iterate on product development based on customer feedback.
• Marketing and advertising agencies use agile to enhance campaign management, creative development, and customer engagement strategies.
• Product development teams use agile to iterate, test, and refine their designs and manufacturing processes.
• Project management teams use agile to enhance project execution, facilitate collaboration, and manage complex projects with changing requirements.
• Retail companies use agile to develop new marketing campaigns and improve their website and e-commerce platform.

Agile Case Study Examples

1. moving towards agile: managing loxon solutions.

Following is an Agile case study in banking:

Loxon Solutions, a Hungarian technology startup in the banking software industry, faced several challenges in its journey towards becoming an agile organization. As the company experienced rapid growth, it struggled with its hiring strategy, organizational development, and successful implementation of agile practices. 

How was it solved:

Loxon Solutions implemented a structured recruitment process with targeted job postings and rigorous interviews to attract skilled candidates. They restructured the company into cross-functional teams, promoting better collaboration. Agile management training and coaching were provided to all employees, with online courses playing a crucial role. Agile teams with trained Scrum Masters and Product Owners were established, and agile ceremonies like daily stand-ups were introduced to enhance collaboration and transparency.

2. Contributions of Entrepreneurial Orientation in the Use of Agile Methods in Project Management

This Agile project management case study aims to analyze the degree of contribution of entrepreneurial orientation (EO) in the use of agile methods (AM) in project management. The study focuses on understanding how EO influences the adoption and effectiveness of agile methods within organizations. Through a detailed case study, we explore the relationship between entrepreneurial orientation and Agile methods, shedding light on the impact of entrepreneurial behaviors on project management practices.

A technology consulting firm faced multiple challenges in project management efficiency and responsiveness to changing client requirements. This specific problem was identified because of the limited use of Agile methods in project management, which hindered the company's ability to adapt quickly and deliver optimal outcomes.

Entrepreneurial orientation (EO) is a multidimensional construct that describes the extent to which an organization engages in entrepreneurial behaviors. The technology firm acknowledged the significance of entrepreneurial orientation in promoting agility and innovation in project management. 

The five dimensions of Entreprenurial orientation were applied across the organization.

• Cultivating Innovativeness: The technology consulting firm encouraged a culture of innovativeness and proactiveness, urging project teams to think creatively, identify opportunities, and take proactive measures. 
• Proactiveness: Employees were empowered to generate new ideas, challenge traditional approaches, and explore alternative solutions to project challenges. This helped them to stay ahead of the competition and to deliver the best possible results for their customers.
• Encouraging Risk-Taking: The organization promoted a supportive environment that encouraged calculated risk-taking and autonomy among project teams. Employees were given the freedom to make decisions and take ownership of their projects, fostering a sense of responsibility and accountability.
• Autonomy: Agile teams were given the autonomy to make decisions and take risks. This helped them to be more innovative and to deliver better results.
• Nurturing Competitive Aggressiveness: The technology firm instilled a competitive aggressiveness in project teams, motivating them to strive for excellence and deliver superior results.

3. Improving Team Performance and Engagement

How do you ensure your team performs efficiently without compromising on quality? Agile is a way of working that focuses on value to the customer and continuous improvement. Integrating Agile in your work will not only make the team efficient but will also ensure quality work. Below is a case study that finds how agile practices can help teams perform better.

The problem addressed in this case study is the need to understand the relationship between the Agile way of working and improving team performance and engagement. We see that teams often face challenges in their daily work. It could be a slow turnover due to bad time management, compromised quality due to lack of resources, or in general lack of collaboration. In the case study below, we will understand how adopting agile practices makes teams work collaboratively, improve quality and have a customer-focused approach to work.

How it was Solved:

A number of factors mediated the relationship between agile working and team performance and engagement. 

• Create a culture of trust and transparency. Agile teams need to be able to trust each other and share information openly. This will help to create a sense of collaboration and ownership. This in turn can lead to increased performance and engagement. 
• Foster communication and collaboration. Effective communication within the team and with stakeholders helps everyone be on the same page.
• Empower team members. Agile teams need to be empowered to make decisions and to take risks. 
• Provide regular feedback. Team members need to receive regular feedback on their performance. This helps them to identify areas where they need improvement. 
• Celebrate successes. By celebrating successes, both big and small, team members are motivated. This in turn creates a positive work environment. 
• Provide training and development opportunities. help the team to stay up to date on the latest trends and to improve their skills. 
• Encourage continuous improvement: Promoting a culture of continuous improvement helps the team to stay ahead of the competition and to deliver better results for their customers. 

It was concluded that agile ways of working can have a positive impact on employee engagement and team performance. Teams that used agile methods were more likely to report high levels of performance and engagement.

4. $65 Million Electric Utility Project Completed Ahead of Schedule and Under Budget

Xcel Energy faced a significant challenge in meeting the Reliability Need required by the Southwest Power Pool in New Mexico. The company had committed to constructing a new 34-mile, 345-kilovolt transmission line within a strict budget of $65 million and a specific timeline. Additionally, the project had to adhere to Bureau of Land Management (BLM) environmental requirements. These constraints posed a challenge to Xcel Energy in terms of project management and resource allocation.

A PM Solutions consultant with project management and utility industry experience was deployed to Xcel Energy.

The PM Solutions consultant deployed to Xcel adapted to the organization's structure and processes, integrating into the Project Management functional organization. He utilized years of project management and utility industry experience to provide valuable insights and guidance.

• Collaborative and social skills were used to address roadblocks and mitigate risks.
• Focused on identifying and addressing roadblocks and risks to ensure timely project delivery.
• Vendor, design, and construction meetings were organized to facilitate communication and collaboration.
• Monitored and expedited long-lead equipment deliveries to maintain project schedule.
• Design and Construction milestones and commitments were closely monitored through field visits.
• Actively tracked estimates, actual costs, and change orders to control project budget.
• Assisted functional areas in meeting their commitments and resolving challenges.

The project was completed eleven days ahead of schedule and approximately $4 million under budget. The management team recognized the project as a success since it went as planned, meeting all technical and quality requirements. 

5. Lean product development and agile project management in the construction industry

The construction industry, specifically during the design stage, has not widely embraced Lean Project Delivery (LPD) and Agile Project Management (APM) practices. This limited adoption delays the industry's progress in enhancing efficiency, productivity, and collaboration in design.

• Integrated project delivery and collaborative contracts: Collaborative contracts were implemented to incentivize teamwork and shared project goals, effectively breaking down silos and fostering a collaborative culture within the organization.
• Lean principles in design processes: Incorporating Lean principles into design processes was encouraged to promote lean thinking and identify non-value-adding activities, bottlenecks, and process inefficiencies. 
• Agile methodologies and cross-functional teams: Agile methodologies and cross-functional teams were adopted to facilitate iterative and adaptive design processes. 
• Digital tools and technologies: The organization embraced digital tools and technologies, such as collaborative project management software, Building Information Modeling (BIM), and cloud-based platforms. 
• A culture of innovation and learning: A culture of innovation and learning was promoted through training and workshops on Lean Project Delivery (LPD) and Agile Project Management (APM) methodologies. Incorporating Agile management training, such as KnowledgeHut Agile Training online , further enhanced the team's ability to implement LPD and APM effectively. 
• Clear project goals and metrics: Clear project goals and key performance indicators (KPIs) were established, aligning with LPD and APM principles. Regular monitoring and measurement of progress against these metrics helped identify areas for improvement and drive accountability.
• Industry best practices and case studies: industry best practices and case studies were explored, and guidance was sought from experts to gain valuable insights into effective strategies and techniques for implementation.

6. Ambidexterity in Agile Software Development (ASD) Projects

An organization in the software development industry aims to enhance their understanding of the tensions between exploitation (continuity) and exploration (change) within Agile software development (ASD) project teams. They seek to identify and implement ambidextrous strategies to effectively balance these two aspects.

How it was solved:

• Recognizing tensions: Teams were encouraged to understand and acknowledge the inherent tensions between exploitation and exploration in Agile projects.
• Fostering a culture of ambidexterity: The organization created a culture that values both stability and innovation, emphasizing the importance of balancing the two.
• Balancing resource allocation: Resources were allocated between exploitation and exploration activities, ensuring a fair distribution to support both aspects effectively.
• Supporting knowledge sharing: Team members were encouraged to share their expertise and lessons learned from both exploitation and exploration, fostering a culture of continuous learning.
• Promoting cross-functional collaboration: Collaboration between team members involved in both aspects was facilitated, allowing for cross-pollination of ideas and insights.
• Establishing feedback mechanisms: Feedback loops were implemented to evaluate the impact of exploitation and exploration efforts, enabling teams to make data-driven decisions and improvements.
• Developing flexible processes: Agile practices that supported both stability and innovation, such as iterative development and adaptive planning, were adopted to ensure flexibility and responsiveness.
• Providing leadership support: Leaders promoted and provided necessary resources for the adoption of agile practices, demonstrating their commitment to ambidexterity.
• Encouraging experimentation: An environment that encouraged risk-taking and the exploration of new ideas was fostered, allowing teams to innovate and try new approaches.
• Continuous improvement: Regular assessments and adaptations of agile practices were conducted based on feedback and evolving project needs, enabling teams to continuously improve their ambidextrous strategies.

7. Problem and Solutions for PM Governance Combined with Agile Tools in Financial Services Programs

Problem: The consumer finance company faced challenges due to changing state and federal regulatory compliance requirements, resulting in the need to reinvent their custom-built storefront and home office systems. The IT and PMO teams were not equipped to handle the complexities of developing new systems, leading to schedule overruns, turnover of staff and technologies, and the need to restart projects multiple times.

How it was Solved: 

To address these challenges, the company implemented several solutions with the help of PM Solutions:

• Back to Basics Approach: A senior-level program manager was brought in to conduct a full project review and establish stakeholder ownership and project governance. This helped refocus the teams on the project's objectives and establish a clear direction.
• Agile Techniques and Sprints: The company gradually introduced agile techniques, starting with a series of sprints to develop "proof of concept" components of the system. Agile methodologies allowed for more flexibility and quicker iterations, enabling faster progress.
• Expanded Use of JIRA: The company utilized Atlassian's JIRA system, which was already in place for operational maintenance, to support the new development project. PM Solutions expanded the use of JIRA by creating workflows and tools specifically tailored to the agile approach, improving timeliness and success rates for delivered work.
• Kanban Approach: A Kanban approach was introduced to help pace the work and track deliveries. This visual management technique enabled project management to monitor progress, manage workloads effectively, and report updates to stakeholders.
• Organizational Change Management: PM Solutions assisted the company in developing an organizational change management system. This system emphasized early management review of requirements and authorizations before work was assigned. By involving company leadership in prioritization and resource utilization decisions, the workload for the IT department was reduced, and focus was placed on essential tasks and priorities.

8. Insurance Company Cuts Cycle Time by 20% and Saves Nearly $5 Million Using Agile Project Management Practices

In this Agile Scrum case study, the insurance company successfully implemented Agile Scrum methodology for their software development projects, resulting in significant improvements in project delivery and overall team performance.

The insurance company faced challenges with long project cycles, slow decision-making processes, and lack of flexibility in adapting to changing customer demands. These issues resulted in higher costs, delayed project deliveries, and lower customer satisfaction levels.

• Implementation of Agile Practices: To address these challenges, the company decided to transition from traditional project management approaches to Agile methodologies. The key steps in implementing Agile practices were as follows:
• Executive Sponsorship: The company's leadership recognized the need for change and provided full support for the Agile transformation initiative. They appointed Agile champions and empowered them to drive the adoption of Agile practices across the organization.
• Training and Skill Development: Agile training programs were conducted to equip employees with the necessary knowledge and skills. Training covered various Agile frameworks, such as Scrum and Kanban, and focused on enhancing collaboration, adaptive planning, and iterative development.
• Agile Team Formation: Cross-functional Agile teams were formed, consisting of individuals with diverse skill sets necessary to deliver projects end-to-end. These teams were self-organizing and empowered to make decisions, fostering a sense of ownership and accountability.
• Agile Project Management Tools: The company implemented Agile project management tools and platforms to facilitate communication, collaboration, and transparency. These tools enabled real-time tracking of project progress, backlog management, and seamless coordination among team members.

9. Agile and Generic Work Values of British vs Indian IT Workers

Problem: 

In this Agile transformation case study, the problem identified is the lack of effective communication and alignment within an IT firm unit during the transformation towards an agile work culture. The employees from different cultural backgrounds had different perceptions and understanding of what it means to be agile, leading to clashes in behaviors and limited team communication. This situation undermined morale, trust, and the sense of working well together.

The study suggests that the cultural background of IT employees and managers, influenced by different national values and norms, can impact the adoption and interpretation of agile work values.

• Leadership: Leaders role-modeled the full agile mindset, along with cross-cultural skills. They demonstrated teamwork, justice, equality, transparency, end-user orientation, helpful leadership, and effective communication. 
• Culture: Managers recognized and appreciated the cultural diversity within the organization. Cultural awareness and sensitivity training were provided to help employees and managers understand and appreciate the diverse cultural backgrounds within the organization.
• Agile values: The importance of agile work values was emphasized, including shared responsibility, continuous learning and improvement, self-organizing teamwork, fast fact-based decision-making, empowered employees, and embracing change. Managers actively promoted and reinforced these values in their leading and coaching efforts to cultivate an agile mindset among employees.
• Transformation: A shift was made from a centralized accountability model to a culture of shared responsibility. Participation in planning work projects was encouraged, and employees were empowered to choose their own tasks within the context of the team's objectives.
• Roadmap: An agile transformation roadmap was developed and implemented, covering specific actions and milestones to accelerate the adoption of agile ways of working. 
• Senior management received necessary support, training, and additional management consultancy to drive the agile transformation effectively.

Benefits of Case Studies for Professionals

Case studies provide several benefits for professionals in various fields: 

• Real-world Application: Agile methodology examples and case studies offer insights into real-life situations, allowing professionals to see how theoretical concepts and principles are applied in practice.
• Learning from Success and Failure: Agile transformation case studies often present both successful and failed projects or initiatives. By examining these cases, professionals can learn from the successes and avoid the mistakes made in the failures.
• Problem-solving and Decision-making Skills: Case studies present complex problems or challenges that professionals need to analyze and solve. By working through these cases, professionals develop critical thinking, problem-solving, and decision-making skills. 
• Building Expertise: By studying cases that are relevant to their area of expertise, professionals can enhance their knowledge and become subject matter experts. 
• Professional Development: Analyzing and discussing case studies with peers or mentors promotes professional development.
• Practical Application of Concepts: Teams can test their understanding of concepts, methodologies, and best practices by analyzing and proposing solutions for the challenges presented in the cases. 
• Continuous Learning and Adaptation: By studying these cases, professionals can stay updated on industry trends, best practices, and emerging technologies. 

Examine the top trending  Agile Category Courses

In conclusion, agile methodology case studies are valuable tools for professionals in various fields. The real-world examples and insights into specific problems and solutions, allow professionals to learn from others' experiences and apply those learning their own work. Case studies offer a deeper understanding of complex situations, highlighting the challenges faced, the strategies employed, and the outcomes achieved.

The benefits of case studies for professionals are numerous. They offer an opportunity to analyze and evaluate different approaches, methodologies, and best practices. Case studies also help professionals develop critical thinking skills, problem-solving abilities, and decision-making capabilities through practical scenarios and dilemmas to navigate.

Overall, agile case study examples offer professionals the opportunity to gain practical wisdom and enhance their professional development. Studying real-life examples helps professionals acquire valuable insights, expand their knowledge base, and improve their problem-solving abilities.

Frequently Asked Questions (FAQs)

Three examples of Agile methodologies are:

Scrum: Scrum is one of the most widely used Agile frameworks. It emphasizes iterative and incremental development, with a focus on delivering value to the customer in short, time-boxed iterations called sprints. 

Kanban: Kanban is a visual Agile framework that aims to optimize workflow efficiency and promote continuous delivery.

Lean: Lean is a philosophy and Agile approach focused on maximizing value while minimizing waste. 

• People over process: Agile values the people involved in software development, and emphasizes communication and collaboration.
• Working software over documentation: Agile prioritizes delivering working software over extensive documentation.
• Customer collaboration over contract negotiation: Agile values close collaboration with customers and stakeholders throughout the development process.
• Responding to change over following a plan: Agile recognizes that change is inevitable, and encourages flexibility and adaptability.

The six phases in Agile are:

• Initiation: Define the project and assemble the team.
• Planning: Create a plan for how to achieve the project's goals.
• Development: Build the product or service in short sprints.
• Testing: Ensure the product or service meets requirements.
• Deployment: Release the product or service to the customer.
• Maintenance: Support the product or service with bug fixes, new features, and improvements.

Lindy Quick

Lindy Quick, SPCT, is a dynamic Transformation Architect and Senior Business Agility Consultant with a proven track record of success in driving agile transformations. With expertise in multiple agile frameworks, including SAFe, Scrum, and Kanban, Lindy has led impactful transformations across diverse industries such as manufacturing, defense, insurance/financial, and federal government. Lindy's exceptional communication, leadership, and problem-solving skills have earned her a reputation as a trusted advisor. Currently associated with KnowledgeHut and upGrad, Lindy fosters Lean-Agile principles and mindset through coaching, training, and successful execution of transformations. With a passion for effective value delivery, Lindy is a sought-after expert in the field.

Avail your free 1:1 mentorship session.

Something went wrong

Upcoming Agile Management Batches & Dates

The impact of agility: How to shape your organization to compete

Infographic: Getting agile transformations right

Agility is on everyone’s lips— online searches for “agile transformation” yield around 100 million hits, and the stories of well-known pioneers circulate widely. But is this just hype, or are there real benefits to be gained? Is agility just noise from the IT department, or an opportunity that merits serious attention from the top team? And if pursuing agility yields benefits, what is the recipe for success?

To find the answers, we conducted a McKinsey Global Survey that reached 2,190 respondents across industries and geographies. 1 The online survey was in the field from October 20 to October 30, 2020, and garnered responses from 1,978 participants of McKinsey’s Online Executive Panel, representing the full range of regions, industries, company sizes, functional specialties, and tenures, as well as 212 McKinsey client participants across industries and geographies. A majority of respondents are C-level executives or senior managers working at organizations with more than 5,000 employees. We wanted to go beyond the fluff, so we asked respondents what, if anything, their companies did in practice to advance agility, and what hard numbers they achieved regarding business impact.

Their organizations fell into two broad groups: the first group consisted of organizations with no agile transformation efforts in process; the second group consisted of organizations on the move, pursuing, or having recently completed an agile transformation beyond a few individual teams (see sidebar “Organizations are on the move”). Two-thirds of those pursuing a transformation, however, said that their organizations were just treading water, taking no decisive action, and consequently achieving little or no business impact.

Organizations are on the move

As part of our research, we set out to find where different organizations are regarding changing their operating model. In our 2017 global survey , we saw that organizations had started to move toward agile—a trend that has continued. Organizations have found it possible to change their operating model despite the COVID-19 pandemic  and the rise of remote working. In addition to the 12 percent of organizations that consider themselves born agile, 44 percent have either completed an agile transformation or are now in the midst of their journey (Exhibit A). Thirty-six percent have scaled agility beyond the team level, with 22 percent having scaled agility to multiple units. It is still a smaller set of trailblazers—10 percent—that have transformed their entire organization, with an additional 4 percent that have changed their entire organization except for their operations.

Telecom and financial services (including banking  and insurance ) continue to lead the way (Exhibit B), reporting both a large share of transformations and high speed of turbulence in the industry. Indeed, these sectors are experiencing significant shifts through, for example, digitalization and new entrants, and are responding by radically changing their operating models. But agility does not end there: a majority of consumer , retail, pharma, and healthcare companies are also undertaking or have recently completed an agile transformation—driven by factors such as changing consumer channel preferences and increased need for speed. Within high tech, many consider themselves to be born agile (16 percent of respondents), while another 45 percent consider themselves transforming.

In addition to the usual suspects, we saw some new arrivals in 2021. Respondents from the oil and gas sector  now consider their industry to be among the most disrupted—perhaps driven by the increased role of sustainability and the energy transition—and they are now starting to adopt agility at scale. Another sector that has shifted place since 2017 is advanced industry  (including, for example, electronics, aerospace, automotive, machinery, and semiconductors). Four years ago, it was considered the most stable and slow-moving sector, but the pace of change is picking up. This is evident in advanced-industry subsectors, such as automotive, where trends like electrification, the increasing role of software , and changing ownership models have opened the door for new entrants and call for incumbents to speed up. Other trends such as digitalization, advanced analytics, and new manufacturing methods are also affecting the broader sector—which could mean advanced industry will be the next big sector to go agile.

Agility is also starting to gain ground in the remaining sectors. Interesting cases can be found in the public sector, for example, with the British Field Army  shifting to agile. Similar early cases, experimentation, and success stories can be found across industries.

There is also a proliferation of different terms, frameworks, and concepts related to agility and new ways of working. When looking at what companies are actually deploying, cross-functional teams is the most widely applied agile concept (used by 74 percent), while application of self-managing teams (used by 49 percent), and application of lean (used by 44 percent), are also common (Exhibit C). Scrum and chapters are also being used at scale. 1 A chapter is a functional group, for example of data scientists or account managers, that come together to ensure consistency across teams, build capabilities, set the long-term direction for the domain, and drive people development. At the other end of the list, the least used methods are scaled agility frameworks (used by 21 percent), flow-to-work pools (used by 9 percent), and holacracy, sociocracy, and teal paradigms (used by less than 3 percent).

Of those respondents with no plans to transform, 52 percent stated that other priorities are higher on their agenda, 49 percent cited unfamiliarity with the concept of agile, 29 percent believed they lack the resources, and 19 percent were concerned that their organization would resist such changes (Exhibit D).

Within this second group, we identified a select set of organizations (represented by 10 percent of the entire sample) that were driving highly successful agile transformations. They were embracing agility at scale to create and capture value instead of treating agile as team-level experiments in discrete departments. This means reimagining the entire organization as a network of high-performing teams, each going after clear, end-to-end business-oriented outcomes, and possessing all of the skills needed to deliver, such as a bank boosting the performance of customer journeys; a retailer analyzing turns and earns of product categories; a mining company reviewing production- and safety-process steps; an oil and gas company planning wells; a machinery player undertaking full product management, from R&D to go-to-market; or a teleoperator simplifying products. The teams are essentially interconnected mini businesses, obsessed with creating value rather than just delivering functional tasks.

However, agility at scale goes beyond adding more agile teams and team-level practices. The broader operating model, the connective tissue between and across the teams, also needs to be transformed. The organizations driving highly successful agile transformations made sure to do that by building an effective, stable backbone . This means optimizing the full operating model across strategy, structures, processes, people, and technology  by going after flat and fluid structures built around high-performing cross-functional teams, instituting more frequent prioritization and resource-allocation processes, building a culture that enables psychological safety, and decoupling technology stacks.

Enterprise agility is thus a paradigm shift away from multilayered reporting structures, rigid annual budgeting, compliance-oriented culture, separation of business and technology, and other traits dominating organizations for the past hundred years. If this is true, and not just hype, a discontinuity of this magnitude should provide an opportunity for organizations to turn their operating models into a competitive advantage—as did early adopters of lean in the 1990s.

While individual case studies and agile success stories have been plentiful, having quantifiable results and a larger sample allowed us to go beyond anecdotes for the first time. Two major findings emerged.

1. Agility results in a step change in performance and makes it possible to overtake born-agile organizations. Highly successful agile transformations typically delivered around 30 percent gains in efficiency, customer satisfaction, employee engagement, and operational performance; made the organization five to ten times faster; and turbocharged innovation. While conventional wisdom sometimes sees these targets as contradictory (for example, efficiency at the cost of employee engagement), our results show otherwise. The respondents, on average, reported gains across four dimensions of performance, out of seven included in the survey.

This step change also showed up as a competitive advantage. Organizations that achieved a highly successful agile transformation had a three times higher chance of becoming a top-quartile performer among peers than those who had not transformed. And they also overtook the born-agile organizations: they not only had a higher chance of becoming a top-quartile performer, but also had a greater chance of achieving a more mature operating model across all dimensions.

2. Instead of waiting for agility to happen bottom-up, organization leaders need to take charge. Our survey asked respondents in detail what actions they took before and during their agile transformations. Our analysis then compared the close to 300 highly successful transformations with the 580 less successful ones to distill what they did differently. Four elements stood out in our logistic regression model, and together these formed a recipe that raises the chance of success from an average of 30 percent to 75 percent:

• Ensure the top team gets it. Before you start, spend sufficient time up front to ensure the top team masters the concepts and can lead the change.
• Be intentional and go after value. Be clear on how agile creates value and have the top team lead the organization to pursue it in a structured manner instead of relying on bottom-up piloting and waiting for agility at scale to emerge.
• Go beyond agile teams to build connective tissue. In the scope of your transformation, rewire the entire operating model (strategy, structure, process, people, and tech) to make sure it supports and connects rather than holds back the team.
• Maintain a high speed and use front-runners. Complete the main phase of the agile transformation in less than 18 months to preserve momentum and avoid exhausting the organization; go even faster in selected front-runner areas to demonstrate commitment and early results.

Done right, agility enables a step change in performance and puts you in a position to surpass even born-agile organizations

Highly successful agile transformations delivered significant performance improvement.

The essence of an agile transformation is reimagining the organization as a network of high-performing teams, supported by an effective, stable backbone of strategy, structure, processes, people, and technology. Imagine working on such a team—having the right people working together, all with different capabilities, enables organizations to move with unprecedented speed. This can increase customer satisfaction and boost operational performance. It can also provide a safe place to experiment with the authority and funds to do so, helping organizations drive more innovation . Employees will feel more engaged and enthused by a clear and common purpose, the autonomy to make decisions, and an ability to develop mastery in their craft. On the organization level, agile emphasizes prioritization and reduces overhead roles, which leads to more efficiency .

Defining success

In our sample, we identified 838 transforming organizations among the 2,190 respondents. And among those 838, we classified 264 organizations (31 percent) as “highly successful.” To determine whether a transformation achieved this level, we set two criteria. First, the organization had to consider the transformation a success (such as leading to improved and sustained performance); and second, we cross-checked their assessment with the degree of performance improvement they had achieved across the categories set out in Exhibit 1. The respondents had to achieve an average impact between “significant” and “major” across their objectives to be considered highly successful in their transformation (for example, for productivity we defined significant as achieving 20 to 40 percent gains in efficiency and major as achieving over 40 percent gains in efficiency to enable comparison).

All well enough in theory—but does it work in practice? Pioneers in the field have proved that significant impact is possible, and we have documented many such examples . With this research we wanted to provide hard facts, so we asked each organization that underwent a transformation about the quantifiable improvements they achieved. Exhibit 1 shows that highly successful agile transformations achieved a step change in performance and greater impact across multiple dimensions than the less successful transformations (see sidebar “Defining success” for details on the methodology used).

What does a highly successful transformation look like in practice?

Consider Spark, an incumbent telecom operator in New Zealand that completed the first phase of its agile transformation in 2018. The operator sought to raise customer centricity, employee engagement, and speed while improving efficiency. The company cut customer complaints by 30 to 40 percent, reached a market-leading customer Net Promoter Score (NPS), received an employee NPS score in excess of 70, and launched new services faster. This led to an increased market share and sector-leading returns. The company now operates more like a digital services provider than a traditional telecom.

We find similar stories across sectors, from slower organizations starting to work with the speed of a born agile to digital native organizations to successful organizations moving up a gear. These gains in speed, customer centricity, operations, innovation, employee engagement, and productivity manifest themselves on the bottom line: 65 percent of highly successful transformations reported they had also achieved significant impact on their financial performance.

Some think that focusing on one issue naturally comes at the expense of others, for example, restructuring to cut costs (customers will suffer) or focusing on employee engagement (at the expense of efficiency). Agile transformations are different because the improvement of one dimension reinforces the improvement of another dimension: the highly successful transformations we studied showed impact across four dimensions on average.

Highly successful agile transformations also led to a three times higher chance of being a top-quartile performer among peers

Our research further showed that a highly successful agile transformation manifests itself directly by measures such as operating-model maturity and performance against peers.

Measuring operating-model maturity

We used a calibrated scale with descriptions of “gaps,” “good,” and “great” for each of the 17 dimensions, and asked the respondents to rate their organizations’ operating model against the scale based on which descriptor best matched their perception. An example of the scale for the first dimension, “purpose,” is shown in Exhibit E.

For each of the 2190 organizations, we also collected their relative performance against peers and compared how the maturity of their operating model (defined as the average across all 17 dimensions) was linked to the likelihood of being a top-quartile performer. Our research revealed that there is a performance threshold at 3.5: going from a good operating model toward a great one rapidly doubles and then triples the chances of being a top-quartile performer among peers (Exhibit F). Only successful transformations manage to get past this threshold.

Using the calibrated 17-dimension scale thus provides a way to determine whether an organization’s operating model is holding it back, keeping it at par with peers, or giving it a competitive advantage. Top teams in various stages of their transformations have used this instrument to give them a quick check on where they are, and which dimensions to focus on.

To measure the maturity of each organization’s operating model in terms of agile working, we devised a calibrated scale for the different sub-elements of the five trademarks of agility —in total, 17 dimensions across the strategy, structure, process, people, and technology elements. For each dimension we used our earlier findings and casework to define a scale for what gaps, good, and great looks like. We asked all 2,190 respondents to self-rate how they experience their organization against the grid, then compared averages depending on where their organization was on its journey (see sidebar “Measuring operating-model maturity” for details on the methodology used).

As shown in Exhibit 2, highly successful transformations reported significantly higher operating-model maturity (scoring on average 3.8 out of 5, where 5 is “great”) compared with those that had not undergone a transformation (scoring 2.5 on average), or those 580 organizations that had done a less successful transformation (scoring 3.2 on average). This was, of course, expected. What was surprising, however, is that the highly successful transformation also scored higher than those that classified themselves as born agile (scoring 3.6 on average). This is highly encouraging because it means that a highly successful transformation allows an organization to overtake born-agile organizations by measures such as operating-model maturity. For example, when it comes to architecture and infrastructure, those organizations that had completed a highly successful transformation believed that their technology setup placed them at a competitive advantage, while many of the born-agile organizations, with decades of legacy in their IT setup, had to make conscious efforts to stay ahead.

Next, we studied the link between completing an agile transformation and achieving a competitive advantage. To judge performance, we asked the respondents to assess how their own organization was doing compared to their peers across financial results, customer satisfaction, speed, operational performance, employee engagement, and innovation. What we discovered was that 57 percent of those that had completed a highly successful agile transformation were in the top quartile of performance—a nearly three times higher likelihood than for those organizations that had not yet transformed (Exhibit 3).

Enterprise agility enabled those who succeeded to make their operating model a competitive advantage, with one caveat: for every highly successful transformation there were two others that missed the opportunity. Despite good intentions, high hopes, and considerable efforts, the less successful transformations achieved only incremental impact (for example, 10 percent improvement in customer satisfaction) and did not materially tilt their likelihood of being a top-quartile performer.

We next turned to the question of what sets the highly successful apart: How does an organization increase its chances of success?

A four-step recipe for success

Distilling the recipe that leads to success.

To identify the factors that lead to success, we collected information on more than 60 variables (different transformation actions and decisions) for each of the 838 transformations in our sample, for example, duration, approach used, use of piloting, frameworks deployed, who was leading, specific changes made, and so on. We first identified the lift of each single variable, for example, those that used front-runners had a one and one-half times higher chance of success than those that did not.

To study the combined effect of factors and the resulting odds, we constructed a logistic regression model. This allowed us to estimate the probability of a transformation being successful, conditional on the combination of the actions taken to complete it. A logistic regression model estimates both the base chances of success, interpreted as the chances of success if you do the opposite of all other factors, in our case 10 percent, and the individual increase in the log odds of each action you perform. When following the four-part recipe in full, an organization has a 75 percent chance of achieving a highly successful agile transformation.

There is a lot of anecdotal, often contradictory advice on how to succeed with an agile transformation. To separate fact from bias, we compared the highly successful agile transformations with the less successful ones to figure out what they had done differently across more than 60 transformation actions and decisions (see more details in the sidebar “Distilling the recipe that leads to success”). Putting it all together into one logistics regression model, we identified a four-part recipe that, when followed correctly, raises the chances of success from 30 percent to 75 percent (Exhibit 4).

What do those driving highly successful agile transformations do, and what should you do?

• Ensure the top team is ready to take your chance of success to 15 percent. Before launch, ensure the top team has a deep understanding of what agility is, and what it is not. This is important for getting profound buy-in from the entire top team and prepares them to lead the change. A deep understanding can be achieved in several practical ways, such as by visiting other organizations, talking to peers about agile working, and understanding enterprise-level concepts (such as the Quarterly Business Review) by doing simulations.
• Be intentional and go after value to give yourself an additional 25 percent boost. This means making a concerted, delegated, and sustained effort from the top—and clarifying how the organization creates value, where and how agile could help (for example, to enable working across functions), and then capturing the opportunities. There are many ways to be intentional: some organizations go all-in; others run the transformation in waves; larger organizations tend to train their leaders in different business units to run localized transformations. In all cases, senior leaders must role-model behaviors and mindset changes and dedicate sufficient time to the transformation. Our research clearly shows that following an unstructured, overly explorative, and bottom-up approach without a clear direction and leadership commitment hurts the chances of success. You cannot pilot your way to scaled agility; an overall enthusiasm for agile seldom translates into scalable impact without decisive leadership and action from the top.
• Go beyond agile teams and build the connective tissue by driving change across all five elements  of your operating model to add an extra 15 percent boost to your chances of success. Enterprise-wide agility is more than just more agile teams—it requires changes to the entire operating model to turbocharge the teams and bring all parts of the new setup together to reinforce one another. Unfortunately, many attempt piecemeal changes when rewiring their operating model, for example, by focusing mainly on ways of working, changing the reporting structure, or adopting new technology. But what sets the most successful apart is that they view their operating model as a system and rewire all of its parts—strategy, structure, process, people, and technology .
• Maintain high speed and use front-runners to unlock the final 20 percent boost. Highly successful transformations tend to complete the main phase 2 Defined as the time between the launch of the transformation and the point at which the changes impacting most of the affected people in the transformation have been implemented. in less than 18 months. For larger organizations, the journey might consist of multiple stages, each covering a specific part of the business (for example, a single country or business unit), each executed in less than 18 months. Those taking much longer tank their chances of success. Additionally, successful transformations tend to launch front-runners early, for example, moving the first 100 people to agile teams early in the transformation to signal commitment and to start the learning that informs iterative improvement.

A detailed description of each of the four elements and their stand-alone impact on chances of success is shown in Exhibit 5. Following this recipe brings you to a 75 percent chance of success; in practice, your success will also depend on company-specific unique factors, context, quality of execution, and even a bit of luck.

Going beyond the numbers, what does it look like in practice to follow the recipe?

1. Ensure the top team is ready

Preparation is key to executing a successful transformation, and so is full commitment from the top team, which must be ready and thoroughly understand what agility at scale means.

One of the large retail groups operating in Oceania recently completed a two-year turnaround—during a COVID-19 lockdown, with teams working remotely—in which it delivered significant quick wins. It knew the next wave of performance gains would depend on local execution, cross-functional initiatives, and rapid testing and learning cycles; thus, the organization shifted to agile working. To prepare for the journey, the CEO engaged with peers in companies that had made similar changes. The top team visited agile companies in the Asia−Pacific region and Europe. The chief human resources officer (CHRO), chief technology officer (CTO), and CEO each worked with an executive from outside their own organization to guide and inspire them and also received monthly coaching. The top team mapped the impact of the changes, knowing they would also need to be reshaped. This preparation phase took several months; when the organization decided to shift, its leaders knew intimately what they were signing up for.

Another large telco company made the preparation phase even more intense for its top team. First, they undertook a tour (both virtual and physical) across a dozen agile companies worldwide. Then, convinced of the potential, they devoted three days to figure out what agility meant for their 7,000 employees, making note of what they referred to as the “scary stuff”:

• From managers to doers. De-layering from six to three levels meant asking hundreds of managers to become agile team members. Would all make the shift?
• New capabilities. New teams would require many performance coaches; yet only a handful existed. How do we train in-house coaches?
• New people model. Evaluating roles by hierarchy would become obsolete. How do we to introduce new contracts, career models, and incentives?
• Let go of (the illusion) of control. Heavy planning and reporting would not suit the new, nimble setup. How do we balance autonomy with alignment and steering?

Impact on us. What is our role? What do we need to learn? What must we unlearn?

After the three days the team made the jump. There was no plan B, so they set out together to solve the scary stuff.

This preparation stage should be as practical as possible. Visits to other companies, talks with peers, and case examples shared by experts help explain what agile working means at the enterprise level. Equally important are immersive simulations and leadership exercises that allow a top team to experience what enterprise agility asks from them as individuals leading in the new operating model.

2. Be intentional and go after value

By intentional, we mean that the transformation should be bold, deliberate, and executed as a coordinated, concerted, and consistent effort. It does not mean ivory-tower command-and-control style. The top team needs to be clear on where the value is and mobilize the entire organization to pursue it in a planned way.

Consider an oil and gas major undergoing a yearlong experiment with agility in its upstream organization. The journey started bottom-up, with hundreds of cross-functional teams across the business coming together to crack issues. The business value this unlocked and the positive employee feedback from the teams whet the company’s appetite, but scaling up would not be successful by simply doing more of the same: rather, the next stage needed to be intentional. After thorough preparations, the top team did three things. First, they delved into value creation, identifying the core end-to-end value chains in the organization, and determining the opportunities for simplification, agility, centralization, and digitization. They would form new teams around these value-creation opportunities, not based on functional boundaries or where people were most eager to try new things. Second, they articulated what it would take to be successful in the new environment: productivity and cost-effectiveness, flexibility to shift resources quickly to evolving priorities, and attracting different kinds of talent—and made sure all actions supported these goals. Third, they made a plan for scale-up: a front-runner in production operations, the part of the organization that required most integration and most immediately impacted value while, in parallel, kicking off the transformation at scale in all other value chains, engaging over 7,000 people across their global portfolio.

Some larger organizations drive top-down change through senior leaders. For example, Roche, a biotechnology company with 94,000 employees in more than 100 countries, launched its change efforts through a personal change program for its senior leaders. More than 1,000 leaders took a four-day immersive program that introduced them to the mindsets and capabilities needed to lead an agile organization. The intent of the program was to help leaders recognize the ways in which their individual mindsets, thoughts, and feelings manifested in the organizations they led and how to drive agility within their domain. Today, agility has been embraced and widely deployed within Roche in many forms and across many of its organizations, engaging tens of thousands of people in applying agile mindsets and ways of working .

The intentional approaches taken by these organizations and in other highly successful agile transformations contrast with those seen in many less successful transformations. In purely bottom-up transformations, there is a proliferation of good pilots and experiments, which typically run into systemic barriers (for example, culture, funding mechanisms, incentives, structures, or something else) that prevent scaling beyond the embryonic stage. As a result, benefits will fail to materialize, leaving cynics to dismiss the whole concept as a fad.

3. Go beyond agile teams and build the connective tissue

As more agile teams are launched, the structures and support around them also need to be rewired—and it needs to be done comprehensively. The operating model is a system, and if we change just one element without addressing the others, we will cripple it. Organizations must therefore pay constant attention to the strategy, structure, processes, people, and technology dimensions of the operating model. Those organizations that change only one part (for example, introduce new technology or launch culture initiatives) often encounter friction between the old ways and the new.

In 2019, Denmark’s 140-year-old incumbent teleoperator, TDC, decided to change course. It separated the network part of the business from the commercial operations and launched the strategy of transforming the latter into a digital service provider able to stand on its own feet. This 4,400-employee unit already had hundreds of people working successfully in agile teams for the digital part of the business , and scaling agility beyond teams to the entire business would best help it thrive in the new competitive arena. The company launched the “Good Rebellion”—a determinedly “go all in” change effort that resulted in clear improvements in customer results, employee engagement, and effectiveness.

In addition to defining new focus areas, such as TV and entertainment, changes in the organization’s strategy went deeper: it defined a new purpose, overhauled the entire identity, and rebranded itself as Nuuday. It changed its structure : a hierarchy gave way to flatter structure of three layers consisting of a top team, 30 unit leaders, and over 200 cross-functional teams. Reporting took place through chapters; chapters focused on consistent and scalable capabilities; and the best talent was deployed to business opportunities instead of internal coordination roles. To ensure alignment among teams, Nuuday introduced a quarterly prioritization  and resourcing process , as well as a biweekly rhythm for teams to follow. To help teams continuously improve their performance and maturity, 40 agile coaches were hired (largely internally) and trained.

Nuuday made the people elements—culture, talent, leadership, and career models—a priority. It started by involving hundreds of people across the business to define the behaviors expected from everyone (for example, challenge the status quo). A new career model rewarding craftsmanship and contribution instead of hierarchical roles were also introduced, and dozens of training and communication events for the different roles and teams ensured a smooth transition. The technology setup was overhauled to allow distributed parallel development across hundreds of teams.

No silver bullet, but some duds

In analyzing the data, we found that no single action significantly moved the odds in an organization’s favor; it was the broad efforts that mattered. Most individual actions were statistically significant but only moderately correlated to success. However, among the actions tested, there were some that had zero or even a slightly negative correlation with success, meaning those organizations that had taken these actions had no greater chance of being highly successful than those which had not. These actions included:

• introducing new language to reinforce new ways of working, for example, using a squad instead of team
• creating a playbook explaining the operating model, for example, governance, structures, agile ways of working
• delivering a generic learning program on agility for all roles

Each of these comes with a nuance. Funky new language for existing concepts did not help, but moving people to cross-functional teams and defining a separate capability-based organization (for example, a chapter) were among the top-performing variables. An agile playbook (which perhaps ended up on the shelf) was not in itself enough; but spending time to adapt the future model to the specific context and to ensure people understood and adopted the new model correlated strongly with success. Broad Agile 101 training did not help, but role-specific training, onboarding boot camps for new teams, and guided first sprints all moved the needle.

These duds further illustrate the need to drive deep and holistic change. Superficial changes indeed lead to disappointing results.

Vital for Nuuday, and for others driving a transformation, is a consistent new operating model—one that goes beyond team-level changes to also cover the connective tissue between them. It is especially important to address the deeper changes head-on. What changes to culture are needed to truly get the benefit of working in teams? What is the new role for leaders  in an agile organization? Do we have the right people  on board, or are there some we must say farewell to? By going below the surface-level changes, organizations can stay focused on being agile instead of just doing agile  (see sidebar “No silver bullet, but some duds”).

4. Maintain high speed and use front-runners

While change needs to be comprehensive, it also needs to be fast (taking more than 18 months reduces the chance of success). When it comes to speed, ING in the Netherlands  is a good example: it set its aspirations in late 2014, and eight months later had already transitioned its entire head office to the new ways of working. Similarly, Spark New Zealand  decided that the risks of going slow outweighed those of going too fast, and opted for “giving it a big run.” Spark launched its first front-runner units within two months and the new agile organization five months later.

Highly successful transformations also use front-runners to get a head start in parts of their organization. Front-runners are not simple pilots (“let’s test if agility works”); rather, they are intentional efforts to see the full new operating model in action in a specific area—covering both agile team-level changes and the connective-tissue changes (with a scope of, for example, the first five through 20 out of 200 agile teams). This is done in an agile spirit by experimenting and iterating to make it a success, with an intention to show commitment, secure early wins, and create a starting point for the broader operating model.

Front-runners are not simple pilots. They are intentional efforts to see the new operating model in action in a specific area.

One Asian telco decided to move fast. One week after a diagnostic that revealed the operating model was failing to capture $200-plus million (run rate), the top team announced the need to change. Five weeks later, four front-runner teams were trained and launched in an agile microcosmos. These teams brought together the doers across departments and tasked them with joint business objectives (for example, reducing the number of inbound service calls) rather than project milestones. Eight weeks later, the entire digital domain was transformed. These first 20 teams acted as a beacon showing what agility looked like and what benefits it could deliver.

A global iconic apparel and footwear company used front-runners when driving agility in its supply chain and logistics-operations unit. Shortly after deciding to adopt agility at scale, it launched the first agile unit of about 100 people. The front-runners were tasked with four objectives:

• discern how to get started at a high pace
• discern how to learn what to do and what to adjust before scaling further
• develop a proof of concept and demonstration of the impact of agility (even in the logistics domain)
• develop a way for people to experience what the future would look like

The decision to launch early front-runners paid off; it strengthened the “why” of the transformation and facilitated the support from the rest of the organization to succeed with the full-scale transformation.

Less successful transformations tend to spend more time and generate less impact. Agility might be a theme in year one, an imperative in year two, part of a few pilots in year three, and so on. Without momentum or examples, employees could not see how the changes affected them in practice, and they did not learn what they should do differently. Prolonged uncertainty about what agile working means to individuals (“Does all the noise about flat organizations and empowerment mean I could lose my job as a manager?”) and lack of observable changes can cause more confusion than good.

Looking ahead: Make agility your advantage

A few years ago, enterprise agility transformations were the domain of a few bold pioneers that had to discover or create the path as they moved along. Now, most organizations are racing to transform to an agile operating model. It is becoming mainstream across many sectors—the big shift to enterprise agility is under way.

Depending on where your organization is on the journey, there are different insights emerging from this research.

• For those who have not started, we emphasize the importance of solid preparation. How can you get senior leaders to fully understand what agility means in practice at the enterprise level? How can you crystallize a clear and ambitious enough aspiration for agility? How can you slow down, prevent false starts, and concentrate more fully on achieving an intentional, rapid, and comprehensive transformation?
• For those who have begun, it is time to look around and see how you are doing. These findings offer a good chance to assess how likely it is that your approach will ultimately deliver significant impact. Is the transformation solidly anchored on value creation and top of mind for the top team, or is it more of a hobby? Are you moving fast enough and showing real progress through front-runner units, or are you dragging along? Are you missing parts of the recipe?
• For those who are not seeing a step change in performance, reflect on why this is the case. Did you set high enough, tangible, and time-bound performance aspirations from the start, or let things drift at their own pace? Have you made it a priority of leaders in the organization to reach and teach these aspirations, or tried to outsource the change to coaches or separate project offices? Have you made holistic change and built the connective tissue between your teams and across all dimensions of the operating model?
• For those who are near the end, and looking beyond, how can you improve? No transformation is ever fully complete. Very few organizations in our sample rated themselves as world class across all dimensions of their operating model, yet the closer they came to this rating the more likely it was that their operating model was a source of competitive advantage. Also, what works now might not work in the future, so there is a need to constantly evolve the operating model. As one executive put it, and as we have seen with some of the born-agile organizations in our sample, “stagnation is death ... you need to ensure you keep changing faster than the market or else you are quickly overtaken.”

Agility has moved from theory to practice, from an unproven approach to a proven way to drive performance and gain a competitive advantage. We hope our findings help bring some method to the madness as you are putting together a winning operating model for today and tomorrow.

The authors wish to thank Désirée af Rosenborg, Frank Barman, Esmee Bergman, Sherina Ebrahim, Ruth Imose, Jason Inacio, Steph Jackson, Quentin Jadoul, Krisztina Katona, Bo Krag Esbensen, Jesper Ludolph, Michael Lurie, Deepak Mahadevan, David Pralong, Guilherme Riederer, Daniel Rona, and Håkon Wik for their contributions to this article.

Explore a career with us

Related articles.

Enterprise agility: Buzz or business impact?

Agility in the time of COVID-19: Changing your operating model in an age of turbulence

The five trademarks of agile organizations

Popular searches

Design Thinking

Customer Experience

Finance Services

View all Categories

Editorial Articles

View all insights

Agile Methodology Examples and Case Studies

It’s useful for organizations to understand and see agile methodology examples and case studies, to understand if they need to consider this approach.

Long have the times passed where Agile was the sole domain of I.T. or the Tech industry.

Agile is now seen as the optimum business model methodology to adopt for most industries. Most industries or organizations are looking to create effieciencies. In their productivity, increased speed to market, and better employee empowerment and morale.

Who uses Agile Methodology?

ADAPTOVATE has worked with clients from every type of industry including :

• Intensive Captial Heavy Industry (Energy, Mining, Manufacturing etc)
• Financial (Banking, Insurance, Loans etc)
• Health (Pharmacutical, Institutions, etc)
• Government deparments, agencies, lobby
• Human Resources
• Engineering
• Food & retail (Large chains, manufacting)
• Not Profit sector

ADAPTOVATE will work closely with our client to best meet the outcome that they are looking for. It should be said that during our assessment we can determine that what a client ‘thinks’ they are looking for oftern turns out not to be what, in actual fact, is needed.

Agile Strategy examples

By undergoing these early discussions, we can determine the agile strategy that will be undertaken. Within ADAPTOVATE we have four key practices we initially operate under. After our assessment, we will undertake our work using one of the following or a combination of all.

• Agile Operating Model Delivery
• Agile Delivery Improvement & Scale
• Agile Business Design & Innovation
• Business Agility Consulting & Training

Agile Transformation

When embarking on an Agile Transformation of any kind, it’s important to start off the right way. This doesn’t mean, it needs to start big. In fact often times, we may encourage pilot teams . If the organization is global, and is looking to roll a new business model across many teams and regions this can be useful. As business change can involve 1000’s of people, pilot teams can be the way to start. Other times not. Have a look at our article on Top-down vs Bottom-up approaches.

Agile Methodology

The very term ‘ agile methodology ‘ may be confusing, misleading or obstructive to some. Many times, we will engage with an organization, who have hired us to review their business model and are looking for a new business design to lead them into the future. ‘Agile’ may not even enter the conversation. ADAPTOVATE believe that applying best practices that have formed the basis of Agile methodology, is always going to bring about positive change. However, sometimes it’s useful, particularly when speaking to employees, not to start with the terminology. Change can be difficult. We recognize that, and are able to help leaders and their teams write the playbook of their future.

Case Studies

With all that in mind, we are happy to share with you some case studies from past clients, to help you understand what our role in their business transformation was.

Case Study Government

Case Study Mining

Case Study Financial Service

Agile Examples

For further Agile examples you can head over to our featured stories where we highlight real-life stories from some of our clients and guests.

For more information please reach out below, we respond within 24 hours of your genuine request.

Get in touch now to find out more

US Headquarters

695 Town Center Dr, Suite 1200

Costa Mesa, CA 92626

+1 424 543 2623

[email protected]

AUSTRALIA & NEW ZEALAND

Simpson House, Level 5, 249 Pitt Street

Sydney NSW 2000

+61 2 7200 2530

L20, 15 William Street,

Melbourne VIC 3000

Auckland ( Tāmaki Makaurau)

Level 4, ACS House, 3 Ferncroft Street,

Grafton, Auckland 1010

New Zealand

3 Temasek Avenue #18-01 Centennial Tower

Singapore 039190

+65 98348486

ul. Czackiego 15/17

00 -043 Warszawa

+48 505 626 416

Postal location:

110 Cumberland Street Suite # 307

Toronto ON M5R 3V5

Physical office location:

296 Richmond St. West

Toronto, ON M5V 1X2

+1 647 631 1205

5th Floor, 167-169 Great Portland Street

London W1W 5PF

+44 20 3603 1662

Key Approaches

Trending Topics

©2022 ADAPTOVATE. All rights reserved

Privacy Policy |  Corporate News |

Case Studies of Agile Enterprise Transformation

“We had happy customers and good software with traditional development. It helped us have a competitive edge in the insurance market, but we can only take it so far. We had squeezed all the improvements and productivity increases that we could get out of what we used to do.” Learn why a current market leader […]

In this webinar, Erik Cottrell interviews Texas Mutual COO, Jeanette Ward. Learn how she’s leading and managing change across the enterprise, how Texas Mutual made the decision to go Agile, and how she worked with peers to leave behind old Command and Control leadership habits.

A supplier of point of sale systems for the retail and commercial fueling industry faced an immovable deadline from a major client. While their teams were said to be practicing Agile, getting a working, shippable product was a constant struggle.

A leading health insurance provider was faced with the challenge of offering online benefits enrollment through Healthcare.gov.

Due to continuously missed deadlines, a growing product company specializing in tech and marketing products for credit unions and small regional banks were in danger of pleasing their customers. Leadership identified the threat and realized the organization needed to implement a change to win back their customers’ trust and confidence.

Ready for Your Last Agile Transformation?

Whether it’s your first or fifth attempt at Agile transformation, we promise that with Path to Agility, it will be your last. Learn how we can help you transform your organization with success and meet your business outcomes.

In the tech world and beyond, new 5G applications are being discovered every day. From driverless cars to smarter cities, farms, and even shopping experiences, the latest standard in wireless networks is poised to transform the way we interact with information, devices and each other. What better time to take a closer look at how humans are putting 5G to use to transform their world.

What is 5G?

5G (fifth-generation mobile technology  is the newest standard for cellular networks. Like its predecessors, 3G, 4G and 4G LTE, 5G technology uses radio waves for data transmission. However, due to significant improvements in latency, throughput and bandwidth, 5G is capable of faster download and upload speeds than previous networks.

Since its release in 2019, 5G broadband technology has been hailed as a breakthrough technology with significant implications for both consumers and businesses. Primarily, this is due to its ability to handle large volumes of data that is generated by complex devices that use its networks.

As mobile technology has expanded over the years, the number of data users generate every day has increased exponentially. Currently, other transformational technologies like  artificial intelligence (AI),  the  Internet of Things (IoT ) and  machine learning (ML)  require faster speeds to function than 3G and 4G networks offer. Enter 5G, with its lightning-fast data transfer capabilities that allow newer technologies to function in the way they were designed to.

Here are some of the biggest differences between 5G and previous wireless networks.

• Physical footprint : The transmitters that are used in 5G technology are smaller than in predecessors’ networks, allowing for discrete placement in out-of-the-way places. Furthermore, “cells”—geographical areas that all wireless networks require for connectivity—in 5G networks are smaller and require less power to run than in previous generations.
• Error rates : 5G’s adaptive Modulation and Coding Scheme (MCS), a schematic that wifi devices use to transmit data, is more powerful than ones in 3G and 4G networks. This makes 5G’s Block Error Rate (BER)—a metric of error frequency—much lower. 
• Bandwidth : By using a broader spectrum of radio frequencies than previous wireless networks, 5G networks can transmit on a wider range of bandwidths. This increases the number of devices that they can support at any given time.
• Lower latency : 5G’s low  latency , a measurement of the time it takes data to travel from one location to another, is a significant upgrade over previous generations. This means that routine activities like downloading a file or working in the cloud is going to be faster with a 5G connection than a connection on a different network.

Like all wireless networks, 5G networks are separated into geographical areas that are known as cells. Within each cell, wireless devices—such as smartphones, PCs, and IoT devices—connect to the internet via radio waves that are transmitted between an antenna and a base station. The technology that underpins 5G is essentially the same as in 3G and 4G networks. But due to its lower latency, 5G networks are capable of delivering faster download speeds—in some cases as high as 10 gigabits per second (Gbps).

As more and more devices are built for 5G speeds, demand for 5G connectivity is growing. Today, many popular Internet Service Providers (ISPs), such as Verizon, Google and AT&T, offer 5G networks to homes and businesses. According to Statista,  more than 200 million homes  and businesses have already purchased it with that number expected to at least double by 2028 (link resides outside ibm.com).

Let’s take a look at three areas of technological improvement that have made 5G so unique.

New telecom specifications

The 5G NR (New Radio) standard for cellular networks defines a new radio access technology (RAT) specification for all 5G mobile networks. The 5G rollout began in 2018 with a global initiative known as the 3rd Generation Partnership Project (3FPP). The initiative defined a new set of standards to steer the design of devices and applications for use on 5G networks.

The initiative was a success, and 5G networks grew swiftly in the ensuing years. Today, 45% of networks worldwide are 5G compatible, with that number forecasted to rise to 85% by the end of the decade according to  a recent report by Ericsson  (link resides outside ibm.com).

Independent virtual networks (network slicing)

On 5G networks, network operators can offer multiple independent virtual networks (in addition to public ones) on the same infrastructure. Unlike previous wireless networks, this new capability allows users to do more things remotely with greater security than ever before. For example, on a 5G network, enterprises can create use cases or business models and assign them their own independent virtual network. This dramatically improves the user experience for their employees by adding greater customizability and security.

Private networks

In addition to network slicing, creating a 5G private network can also enhance personalization and security features over those available on previous generations of wireless networks. Global businesses seeking more control and mobility for their employees increasingly turn to private 5G network architectures rather than public networks they’ve used in the past.

Now that we better understand how 5G technology works, let’s take a closer look at some of the exciting applications it’s enabling.

Autonomous vehicles

From taxi cabs to drones and beyond, 5G technology underpins most of the next-generation capabilities in autonomous vehicles. Until the 5G cellular standard came along, fully autonomous vehicles were a bit of a pipe dream due to the data transmission limitations of 3G and 4G technology. Now, 5G’s lightning-fast connection speeds have made transport systems for cars, trains and more, faster than previous generations, transforming the way systems and devices connect, communicate and collaborate.

Smart factories

5G, along with AI and ML, is poised to help factories become not only smarter but more automated, efficient, and resilient. Today, many mundane but necessary tasks that are associated with equipment repair and optimization are being turned over to machines thanks to 5G connectivity paired with AI and ML capabilities. This is one area where 5G is expected to be highly disruptive, impacting everything from fuel economy to the design of equipment lifecycles and how goods arrive at our homes.

For example, on a busy factory floor, drones and cameras that are connected to smart devices that use the IoT can help locate and transport something more efficiently than in the past and prevent theft. Not only is this better for the environment and consumers, but it also frees up employees to dedicate their time and energy to tasks that are more suited to their skill sets.

Smart cities

The idea of a hyper-connected urban environment that uses 5G network speeds to spur innovation in areas like law enforcement, waste disposal and disaster mitigation is fast becoming a reality. Some cities already use 5G-enabled sensors to track traffic patterns in real time and adjust signals, helping guide the flow of traffic, minimize congestion, and improve air quality.

In another example, 5G power grids monitor supply and demand across heavily populated areas and deploy AI and ML applications to “learn” what times energy is in high or low demand. This process has been shown to significantly impact energy conservation and waste, potentially reducing carbon emissions and helping cities reach sustainability goals.

Smart healthcare

Hospitals, doctors, and the healthcare industry as a whole already benefit from the speed and reliability of 5G networks every day. One example is the area of remote surgery that uses robotics and a high-definition live stream that is connected to the internet via a 5G network. Another is the field of mobile health, where 5G gives medical workers in the field quick access to patient data and medical history. This enables them to make smarter decisions, faster, and potentially save lives.

Lastly, as we saw during the pandemic, contact tracing and the mapping of outbreaks are critical to keeping populations safe. 5G’s ability to deliver of volumes of data swiftly and securely allows experts to make more informed decisions that have ramifications for everyone.

5G paired with new technological capabilities won’t just result in the automation of employee tasks, it will dramatically improve them and the overall  employee experience . Take virtual reality (VR) and augmented reality (AR), for example. VR (digital environments that shut out the real world) and AR (digital content that augments the real world) are already used by stockroom employees, transportation drivers and many others. These employees rely on wearables that are connected to a 5G network capable of high-speed data transfer rates that improve several key capabilities, including the following:

• Live views : 5G connectivity provides live, real-time views of equipment, events, and even people. One way in which this feature is being used in professional sports is to allow broadcasters to remotely call a sporting event from outside the stadium where the event is taking place.
• Digital overlays : IoT applications in a warehouse or industrial setting allow workers that are equipped with smart glasses (or even just a smartphone) to obtain real-time insights from an application. This includes repair instructions or the name and location of a spare part.
• Drone inspections : Right now, one of the leading causes of employee injury is inspection of equipment or project sites in remote and potentially dangerous areas. Drones, which are connected via 5G networks, can safely monitor equipment and project sites and even take readings from hard-to-reach gauges.

Edge computing , a computing framework that allows computations to be done closer to data sources, is fast becoming the standard for enterprises. According to  this Gartner white paper  (link resides outside ibm.com), by 2025, 75% of enterprise data will be processed at the edge (compared to only 10% today). This shift saves businesses time and money and enables better control over large volumes of data. It would be impossible without the new speed standards that are generated by 5G technology. 

Ultra-reliable edge computing and 5G enable the enterprise to achieve faster transmission speeds, increased control and greater security over massive volumes of data. Together, these twin technologies will help reduce latency while increasing speed, reliability and bandwidth, resulting in faster, more comprehensive data analysis and insights for businesses everywhere.

5G solutions with IBM Cloud Satellite  

5G presents significant opportunities for the enterprise, but first, you need a platform that can handle its speed. IBM Cloud Satellite® lets you deploy and run apps consistently across on-premises, edge computing and public cloud environments on a 5G network. And it’s all enabled by secure and auditable communications within the IBM Cloud®.

Get the latest tech insights and expert thought leadership in your inbox.

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.

Supply chain innovation is crucial for maintaining a competitive edge. As companies expand and evolve, the ability to streamline operations, enhance efficiency, and adapt to new technologies becomes paramount. Effective supply chain management not only reduces costs but also improves service levels and profitability, making it a cornerstone for sustainable growth.

The Challenge

In 2007, Kimberly-Clark faced a pivotal challenge. To successfully implement SAP’s Extended Warehouse Management (EWM) system and revolutionize their supply chain efficiency, they needed expert training. K-C made the strategic decision to transition the responsibility for SAP supply chain solutions training from its internal team to trusted third-party partners. MAU was called upon to support this critical initiative.

Enter one of MAU’s key operational managers, whose nearly two decades of dedication to Kimberly-Clark made him an ideal leader for the SAP EWM training initiative. Focused on systems and material flow, as well as continuous improvement initiatives, he led a team of approximately 120 employees to deliver on key warehouse and logistics metrics.

The Results of Supply Chain Innovation

The collaboration between MAU and Kimberly-Clark yielded transformative results:

• Enhanced Warehouse Management : Successful implementation of the EWM system improved operational efficiency.
• Reduced Downtime : At the Beech Island facility, downtime was reduced by 67%.
• Improved Inventory Accuracy : Enhanced precision in inventory management.
• Decreased Shipping Errors : Shipping errors at K-C’s Berkeley Mills were reduced by over 90% within the first year.

Above and Beyond

The partnership between MAU and Kimberly-Clark is a testament to how dedication, expertise, and a willingness to exceed expectations can lead to significant improvements. MAU’s leadership in SAP EWM training and support has not only fortified K-C’s supply chain and warehouse management processes but also contributed to their ongoing success.

For more detailed insights, download the full case study.

RPO Solutions in Manufacturing: Transforming Talent Strategies for a Competitive Edge

by Allie Pizzemento | May 15, 2024 | Workforce Insights

In the high-stakes manufacturing world, the single most important resource isn't raw material, cutting-edge technology, or even the capital that fuels production. No, the true powerhouse behind successful manufacturing operations has always been and always will be...

Strategic Workforce Planning in an Era of Manufacturing Innovation

by Allie Pizzemento | May 8, 2024 | Workforce Insights

The foundation of any manufacturing powerhouse isn't just its state-of-the-art facilities, cutting-edge technology, or well-oiled supply chain. It's the skilled workforce at the core of everything it does. In an age where technological advancements are not just a...

The Evolution of Talent Acquisition in the Manufacturing Sector: Navigating the New Norms

by Allie Pizzemento | May 1, 2024 | Workforce Insights

The manufacturing industry, known for its constant evolution and adaptation, is undergoing a significant paradigm shift in talent acquisition. As the sector navigates through the challenges posed by fierce competition and technological advancements, it's imperative...

• Skip to main content
• Skip to search
• Skip to footer

Products and Services

Contact cisco.

To get global contact information, please make your selections in the drop-down menus. 

Country/region and language

Get in touch

Please reach out to sales for general inquiries or to chat with a live agent.

Sales inquiries

1 800 553 6387 , press 1

Order and billing

1 800 553 6387  , press 2-1

Monday to Friday 8 a.m. to 5 p.m. Eastern Time Chat is available to you 24/7.

Find technical support for products and licensing, access to support case manager, and chat with support assistant. Technical support is available 24/7.

Enterprise and service providers

1 800 553 2447  (U.S. and Canada) 

Small business

1 866 606 1866  (U.S. and Canada)

Training and certifications

1 800 553 6387 , press 4

Explore support

Explore certification support

Cisco partners

Become a partner, locate a partner, get updates, and partner support. 

Explore Cisco partners

Get partner support

Find a Cisco office

Find offices around the world. 

Locate offices

Corporate headquarters

300 East Tasman Drive San Jose, CA 95134

Legal mailing address

Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134

Complete the form below or log in and the form will autofill. One of our sales specialists will call you within 15 minutes or on a date or time you request. Specialists are available Monday through Friday, 8 a.m. to 5 p.m. Eastern Time. We are currently experiencing delays in response times. If you require an immediate sales response – please call us 1 800-553-6387. Otherwise, a sales advisor will call you as soon as possible. * Required

Want to use a different email? Sign out * Required