case study on agile leadership

Case Studies

This page provides an overview of the various case studies available from Scrum.org. These case studies demonstrate successful transforming organizations, uses of Scrum, Nexus, Evidence-Based Management and more. Read them to understand where people and teams have struggled and how they have overcome their struggles.

Organizational and Cultural Transformation

Scaling scrum, successfully implementing scrum, scrum outside of software.

Search All Case Studies

What did you think about this content?

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

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

• 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.

Leading agile transformation: The new capabilities leaders need to build 21st-century organizations

For many organizations, surviving and thriving in today’s environment depends on making a fundamental transformation to become more agile. Those making the transition successfully are achieving substantive performance and health improvements: enhanced growth, profitability, customer satisfaction, and employee engagement.

Stay current on your favorite topics

More than any other factor, the key to a successful agile transformation is for leaders, particularly senior leaders, to develop substantially new mind-sets and capabilities. This article summarizes our guide, Leading agile transformation: The new capabilities leaders need to build 21st-century organizations (PDF–765KB), to readying leaders for agile transformations.

The agile story

Before we dive deep, it’s useful to take a broader view of agile, and particularly what sets agile organizations apart from traditional ones.

Characteristics of traditional and agile organizations

Simply put, the dominant traditional organization model evolved primarily for stability in a well-known environment. It is based on the idea of an organization as a machine, with a static, siloed, structural hierarchy that operates through linear planning and control to execute one or very few business models.

Agile 1 The term “agile” as applied to a way of working that originated in 2001 with a new approach to software development. As organizations increasingly sought to become more agile—that is, faster and more flexible—they recognized that principles of agile software development could be applied much more broadly to organizations as a whole. organizations, viewed as living systems, have evolved to thrive in an unpredictable, rapidly changing environment. These organizations are both stable and dynamic. They focus on customers, fluidly adapt to environmental changes, and are open, inclusive, and nonhierarchical; they evolve continually and embrace uncertainty and ambiguity. Such organizations, we believe, are far better equipped than traditional ones for the future.

While there are many different forms of enterprise agility, they share some common trademarks. We have identified and enumerated these in a related article, “ The five trademarks of agile organizations .”

Leadership in agile organizations

This new kind of agile organization requires a fundamentally different kind of leadership . Recent research confirms that leadership and how leadership shapes culture are the biggest barriers to—and the biggest enablers of—successful agile transformations.

Organizations must therefore begin by both extending and transcending the competencies that made their leaders successful in the past. Leaders need three new sets of capabilities for agile transformations. First, they must transform themselves to evolve new personal mind-sets and behaviors. Second, they need to transform their teams to work in new ways. Third, it’s essential to build the capabilities to transform the organization by building agility into the design and culture of the whole enterprise.

Transforming yourself

To fully transform yourself, several shifts will be necessary—and leaders will need to make these changes in a disciplined way.

Shifting from reactive to creative mind-sets

Changing our mind-set—or adjusting it to the new context—is no easy task, but developing this “inner agility” is essential in releasing our potential to lead an agile transformation.

Reactive, or socialized, mind-sets are an outside-in way of experiencing the world based on reacting to circumstances and other people. Creative, or self-authoring, mind-sets are an inside-out way of experiencing the world based on creating our reality through tapping into our authentic selves, our core passion and purpose.

Would you like to learn more about our People & Organizational Performance Practice ?

Research shows that most adults spend most time “in the reactive,” particularly when challenged, and as a result, traditional organizations are designed to run on the reactive. 2 See Carol S. Dweck, Mindset: The New Psychology of Success , New York, NY: Ballantine Books, 2007. To build and lead agile organizations, however, leaders must make a personal shift to run primarily “in the creative.”

There are three fundamental reactive-to-creative mind-set shifts we have found critical to foster the culture of innovation, collaboration, and value creation at the heart of agile organizations:

• From certainty to discovery: fostering innovation. A reactive mind-set of certainty is about playing not to lose, being in control, and replicating the past. Today, leaders need to shift to a creative mind-set of discovery, which is about playing to win, seeking diversity of thought, fostering creative collision, embracing risk, and experimenting.
• From authority to partnership: fostering collaboration. Traditional organization design tends towards siloed hierarchies based on a reactive mind-set of authority. The relationship between leaders and teams is one of superior to subordinate. Designed for collaboration, agile organizations employ networks of autonomous teams . This requires an underlying creative mind-set of partnership, of managing by agreement based on freedom, trust, and accountability.
• From scarcity to abundance: fostering value creation. In stable markets, companies maximize their shares at the expense of others. This win–lose approach reflects a reactive mind-set of scarcity, based on an assumption of limited opportunities and resources. Today’s markets, however, evolve continually and rapidly. To deliver results, leaders must view markets with a creative mind-set of abundance, which recognizes the unlimited resources and potential available to their organizations and enables customer-centricity, entrepreneurship, inclusion, and cocreation.

A disciplined approach

While these mind-set shifts might be new and require a significant “letting go” of old beliefs and paradigms, collectively, they form a very disciplined approach to leadership. And because of inherent autonomy and freedom, leadership in agile organizations comes from a self-disciplined approach—leading not in fear of punishment or sanction but in service of purpose and passion.

Transforming your teams

Next, it’s important to learn how to help teams work in new and more effective ways.

Help teams work in agile ways

How might leaders help teams work in new and more agile ways? And what does this new way of working require of leaders? There are three essential leadership requirements that follow from all agile ways of working.

First, leaders must learn to build teams that are small, diverse, empowered, and connected. Second, leaders must allow and encourage agile teams to work in rapid cycles to enable them to deliver greater value more efficiently and more quickly. Third, leaders must keep agile teams focused on the external or internal customer and on creating value for customers, by understanding and addressing their unmet, and potentially even unrecognized, needs.

Embrace design thinking and business-model innovation

We have found that in addition to being able to lead in this new agile way of working, it is important for leaders to understand the key elements of two other relatively new disciplines: design thinking and business-model innovation.

Originating in industrial and other forms of design, design thinking is a powerful approach to developing innovative customer solutions, business models, and other types of systems. This begins with understanding the entire customer experience at each stage of the customer journey .

In organizations that are agile, each team is viewed as a value-creating unit, or as a “business.” These teams pursue business-model innovation at every opportunity, seeking new ways to meet the needs of their internal or external customers and deliver more value to employees, investors, partners, and other stakeholders.

Transforming your organization

Here, leaders must learn how to cocreate an agile organization purpose, design, and culture.

Purpose: Find the north star

The first distinctive organization-level skill leaders need to develop is the ability to distill a clear, shared, and compelling purpose—a north star—for their organization. Rather than the traditional executive-team exercise, in agile organizations, leaders must learn to sense and draw out the organization’s purpose in conversation with people across the enterprise.

Design: Apply the principles and practices of agile organization design

The second organization-level skill leaders need to develop is the ability to design the strategy and operating model of the organization based on agile-organization principles and practices. Most senior leaders of traditional companies have a well-honed skill set in this area that reflects traditional organization design as a relatively concentrated, static system: one or a very limited number of major businesses, each with a long-established business model, typically coexisting somewhat uneasily with a set of corporate functions.

The five trademarks of agile organizations

To design and build an agile organization, leaders need a different set of skills based on a different understanding of organizations. They must learn to design their organization as a distributed, continually evolving system. Such an organization comprises a network of smaller empowered units, with fewer layers, greater transparency, and leaner governance than a traditional model. More specifically, leaders must learn how to disaggregate existing large businesses into a more granular portfolio; transform corporate functions into a lean, enabling backbone; and attract a wide range of partners into a powerful ecosystem .

Culture: Shape an agile organizational culture

The third organization-level skill leaders need to develop is the ability to shape a new culture across the organization, based on the creative mind-sets of discovery, partnership, and abundance and their associated behaviors.

Given the openness and freedom people experience in an agile organization, culture arguably plays an even more important role here than in traditional organizations. To shape this culture, leaders must learn how to undertake a multifaceted culture-transformation effort that centers on their own capabilities and behaviors. This includes the following steps:

• role modeling new mind-sets and behaviors authentically
• fostering understanding and conviction in a highly interactive way, through sharing stories and being inspired by the energy and ideas of frontline teams
• building new mind-sets and capabilities across the organization , including among those who do not formally manage people, and weaving learning into the fabric of daily activity to become true learning organizations
• implementing reinforcement mechanisms in the agile organization design

An agile approach to developing leaders

Many organizations start their agile pilots in discrete pockets. Initially, at least, they can build agile-leadership capabilities there. But to scale agility through an organization successfully, top leaders must embrace its precepts and be willing to enhance their own capabilities significantly. Eventually, a full agile transformation will need to encompass building the mind-sets and capabilities of the entire senior leadership across the enterprise. To do this in an agile way, five elements are essential:

• Build a cadre of enterprise agility coaches , a new kind of deeply experienced expert able to help leaders navigate the journey, supported by a leadership-transformation team.
• Get the top team engaged in developing its own capabilities early on, as all senior leaders will take their cue from the executive team.
• Create an immersive leadership experience (anything from a concentrated effort over three or four days to a learning journey over several months) to introduce the new mind-sets and capabilities, and roll it out to all senior leaders.
• Invite leaders to apply their learning in practice , both in agile-transformation initiatives already under way and through launching new organizational experiments.
• Roll out the leadership capability building at an agile tempo , with quarterly pauses to review the leadership experiences, experiments, and culture shifts over the past 90 days, and then finalize plans and priorities for the next 90 days.

Agile transformation is a high priority for an increasing number of organizations. More than any other factor, the key enabler to a successful agile transformation is to help leaders, particularly senior leaders, develop new mind-sets and capabilities. Doing so in an agile way will enable the organization to move faster, drive innovation, and both adapt to and shape its changing environment. 

Download Leading agile transformation: The new capabilities leaders need to build 21st-century organizations , the full report on which this article is based (PDF–765KB).

Aaron De Smet is a senior partner in McKinsey’s Houston office, Michael Lurie is a senior expert in the Southern California office, and Andrew St George is an adviser to the firm and associate fellow of Said Business School, Oxford University.

The authors wish to thank Wouter Aghina, Karin Ahlback, Andre Andreazzi, Christopher Handscomb, Johanne Lavoie, and Christopher Paquette for their contributions to this article.

Explore a career with us

Related articles.

The agile manager

How to mess up your agile transformation in seven easy (mis)steps

This site uses cookies to improve your experience. By viewing our content, you are accepting the use of cookies. To help us insure we adhere to various privacy regulations, please select your country/region of residence. If you do not select a country we will assume you are from the United States. View our privacy policy and terms of use.

• Sustainability
• Communications Management
• Project Cost
• Project Life Cycle
• Risk Management

Vodafone New Zealand's Agile Transformation Case Study

AUGUST 20, 2020

Investing in agile would underpin this approach by introducing ways of working that reduce complexity, improve collaboration and bring the customer to the forefront of each decision. Reaching Agile Maturity Ahead of Plan. Company-wide agile awareness and engagement activities established a strong foundation for change.

5 kinds of Agile bandits: Special Sprints Bandits

JANUARY 13, 2024

Are Special Sprints in Agile Truly Beneficial? In my journey with Agile , I've often encountered teams embroiled in what I term 'special sprints' – Sprint zeros, refactoring sprints, and bugfix sprints. At first glance, these sprints appear as a savvy adaptation of Agile . The result?

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

• The Project Clinic: Assessing Project Health, Planning, and Execution

MORE WEBINARS

Trending Sources

• Green Project Management

ProjectManager.com

• Musings on Project Management

The Evolution of Learning: Embracing Immersive Learning in Scrum and Agile Environments

DECEMBER 15, 2023

This method proves especially beneficial in Scrum and Agile environments, where adaptability and practical skills are crucial. We move away from hypothetical case studies to discuss real challenges and scenarios that participants face in their workplaces.

7 Lessons for Customer-Centric Leadership

JULY 30, 2018

Customer-centric leadership is essential in today’s business climate. Jennifer Bridges, PMP, explains more and cites these well-known brands as excellent examples of customer-centric leadership . In Review – 7 Lessons for Customer-Centric Leadership . Customer-Centric Leadership . Customer Experience.

Encouraging Innovation in an Established Product Culture

Speaker: Richard Cardran, Chief Creative Officer and VP Strategy, HIA Technologies

We'll examine the importance of UX and user-centric feature analysis, the adaptation of Agile Methodologies to the creative process, as well as a way to drive successful culture change for setting expectations and winning approvals with cross-functional stakeholders. Innovation and Leadership go hand in hand.

Servant Leadership in PMO Management: A Path to Success

The IIL Blog

OCTOBER 4, 2023

However, the traditional hierarchical management approach is evolving, giving rise to the concept of servant leadership within PMOs. Servant leadership is a leadership philosophy where the leader’s primary focus is on serving and empowering team members within the PMO. Servant Leadership Approach. Case Study .

IBM Project Manager Certificate: My Student Review

Rebel’s Guide to PM

SEPTEMBER 1, 2023

This is where you read a case study , complete a document template, upload it, and one of the other students assesses it. I don’t think they truly meant to be that specific, especially as there is nowhere in the case study where you get given the exact name in the marking scheme, so how would you even know it?

How to Win with Agile Resistant Teams — Agile Camp Berlin 2021

JULY 8, 2021

TL; DR: How to Win with Agile Resistant Teams w/ Scott Weiner — ACB21. In this highly engaging speaker session from the Agile Camp Berlin 2021, Scott Weiner shares a case study on how to master an agile transition by creating agile resistant teams based on common sense, team autonomy, and the psychology of metrics. ??

Beyond Agile presentation this Friday

Leading Answers

SEPTEMBER 28, 2022

On Friday, September 30, I will be presenting a session on Beyond Agile at the HTEC Project Management Virtual Conference. A colleague recently described Beyond Agile as a “Yes, And, And” toolkit, and I thought it was a great way to summarize the two elements of combining hybrid agile with the Theory of Constraints, and value stream view.

Applying the heuristics of “How Big Things Get Done” to adaptive delivery

Kiron Bondale

MAY 8, 2023

I read a number of project leadership books each year but usually I find only one or two which really make an impact. In the book, the authors provide many case studies supporting eleven heuristics derived from Prof. Whether we are looking to fill the role of a project manager, an agile lead (e.g.

Current State and Future Prospects of Scrum and Agile Development in Japan

MARCH 7, 2023

Since I became a Professional Scrum Trainer in November, I have been asked a lot about the current state, and the future perspectives, for Scrum and agile development in Japan, where I’ve worked for the last six years. Yet, Scrum and the principles of agile development are not as common in Japan as they are in other parts of the world.

[VLOG] 8 Hats The Scrum Master Wears As A True Leader Who Serves

JUNE 8, 2022

This was change from what was initially called servant leadership . Other misinterpretation is turning the Scrum Master as a junior Agile Coach who have a narrow knowledge about agile . We do not need to put an additional noun infront of " leadership ". We do not need to put an additional noun infront of " leadership ".

The Best Team Ever — David Burkus on the Surprising Science of High-performing Teams

MAY 31, 2022

TL; DR: Hands-on Agile #40: Best Team Ever w/ David Burkus. In this energizing 40th Hands-on Agile ‘Best Test Ever’ session, David Burkus delved into the surprising science of high-performing teams. ?? Watch the video now: David Burkus: Best Team Ever — Hands-on- Agile #40. ?? Join 3,800-plus Agile Peers on Youtube.

15 Easy Ways to Earn PDUs in 2023

APRIL 19, 2023

PDUs with the Agile PrepCast $129 Earn 30.5 PDUs by listening to The Agile PrepCast and learning more about agile tools and methods. Get instant access to 10 high quality webinars on leadership and specialist topics to help you earn the difficult 'Power Skills' PDUs. Then anyone who wanted to join the webinars could.

Review Agile transformation

Henny Portman

NOVEMBER 9, 2020

In the book Agile transformation – Structures, processes and mindsets for the digital age , the author Neil Perkin shows how to transform an organization to a new type of business for a new age and to become fit for purpose for both the present and the future. QRC agile transformation Download. Conclusion.

Minecraft Scrum - 3 Years of Teaching and lLarning

OCTOBER 11, 2022

Using other case studies , I find it “normal” to see students in their inbox and be distracted because they are waiting for something from someone. The other case studies don’t have a metaphor to help gain perspective, it is more subtle to land some of the personal learnings. . . That’s just how they do things.

The Complete Guide to Scaling Agile and SAFe for Business Agility

JANUARY 24, 2022

What is Scaling in Agile ? Agile is a set of values and principles. Agile is an umbrella term for a group of iterative product development frameworks. Most organizations started their Agile journey with one of the frameworks mentioned above, and Scrum is the most popular one. Scaling Agile Frameworks. What is SAFe?

Agile. Creativity. Innovation.

International Institute for Learning

JULY 7, 2022

This family of methods are now commonly known as Agile , and it has been through the formation of the Agile Alliance and the publication of the Agile Manifesto (Fowler and Highsmith 2001). We can say the Agile methods have well-interpreted the so-called Copernican Revolution in management.

Is the IBM IT Project Manager Certificate worth it?

MAY 31, 2023

However, the Introduction to Agile Development and Scrum course does recommend that you are comfortable using a computer and that you’ve had some involvement in software development or IT project management, perhaps as a team member or stakeholder in development projects. You can retake the quizzes and peer assessments.

Minimum Viable Library (2) — Product Owner Edition

AUGUST 21, 2023

Explore a series of carefully curated collections of essential books, newsletters, podcasts, and tools to elevate your agile expertise. You can sign up here for the ‘Food for Agile Thought’ newsletter and join 48,000-plus subscribers. ? The Minimum Viable Library — Leadership Edition.

PRINCE2 and PMBOK: How They Compare

OCTOBER 4, 2021

In 2020, AXELOS, the awarding body for the PRINCE2 family of certifications, launched a version specifically aimed at the US market, with relevant vocabulary and case studies . The Project Management Institute approach has been to bring more agile into the main guide, and to publish it alongside the Agile Practice Guide.

PMI Membership for Professionals and Students: Is it Worth It?

NOVEMBER 15, 2022

A Disciplined Agile Approach to Optimizing Your Way of Working (WoW). Project Management Journal – I used this when I was researching my books, so if you’re interested in the theory of project management as well as case studies , this is a great benefit. Get leadership experience and events management experience.

3 Ways Organizations Use Measures Poorly

OCTOBER 3, 2021

Do you want to learn how to leverage EBM to improve business agility ? It is called Professional Agile Leadership – Evidence-Based Management (PAL-EBM). It allows participants to use a case study to practice applying concepts in real-time. Scrum.org has launched an official 1-day training for EBM.

Agile Scrum Master

MARCH 15, 2022

The agile scrum master certification provides a way for people to get trained in the latest project management techniques. The Agile Scrum Master certification is the first step to becoming a certified agile coach. The agile scrum master is the person who facilitates the process of agile development. What is scrum?

Building pedestals worsens the effect of sunk cost fallacy

NOVEMBER 9, 2022

While her book provides lots of good advice with supporting case studies , two had particular applicability to project delivery. If you liked this article, why not pick up my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership ?

Minecraft Scrum - 3 years of teaching and learning

?? Daniel Stillman: Designing Powerful Questions to help you Coach, Create, Connect and Lead

NOVEMBER 29, 2021

Learn from Daniel Stillman how designing powerful questions helps you coach, create, connect, and lead from the 35th Hands-on Agile meetup of October 5, 2021. ?? Watch the video with Daniel Stillman now: Hands-on Agile #35: Designing Powerful Questions to help you Coach, Create, Connect and Lead. ??

15 Non-Academic Project Management Books to Earn PDUs

SEPTEMBER 26, 2023

Books that cover ways of working, technical project management, leadership , power skills, soft skills for the workplace, business acumen and also strategic and business management topics count. Retrospective Antipatterns is a great book for those in agile project management – especially if you’ve read all the classics.

How We Reduced Cycle Time from 164 Days to 8 Days in 6 Months

JANUARY 5, 2021

What adjustments were made in the entire organization as part of a 4 year Agile enablement? What challenges was this specific Agile Team facing when this journey began? What 4 key sets of adjustments made by the specific Agile Team that is the subject of this case study ? ORGANIZATIONAL CHANGE LEADERSHIP .

What Makes A Good Product Owner?

NOVEMBER 24, 2021

Each post discusses scientific research that is relevant to our work with Scrum and Agile teams. Van Waardenburg & Van Vliet (2013) offer a case study in a large organization and conclude that “The Project Manager focuses on the ’how’ of a project, the Product Owner focuses on the ’what’”. What makes a good Product Owner?

Project Management Conferences and Events 2022

JANUARY 7, 2022

It is a platform for project leaders to gain knowledge and share experiences on topics that are driving the leadership of projects today and in the future. Agile and Beyond: Detroit, Michigan, USA, 24-25 May 2022. The Agile and Beyond conference is back again and they are currently looking for speakers!

Agile 2019 Presentations

MARCH 29, 2019

I learned this week that two of my presentation submissions for the Agile 2019 conference in Washington D.C. My talks will be on moving beyond agile approaches and case studies in transitioning from projects to products. Agile approaches succeeded and changed the way we work. August 6-10 have been accepted.

Why Executives Don’t Go to Agile Conferences

Agile Coach

JULY 15, 2016

Let’s say the owner had a little more to worry about than ‘ being Agile ‘ I remember when the Agile Alliance did their first executive forum at the big annual Agile 20XX conference. So where are these executives going to learn about Agile ? If anything, they learn Agile through storytelling.

How To Maximize The Efforts Of Your Agile Team

MARCH 26, 2018

According to agile visionaries, a robust, agile team embodies “we” rather than “I” and that teamwork is crucial to delivering great software. Supposing your organization has embraced an agile methodology and you’re disappointed by failure, then it is time to look into it critically. Start with Proper Planning. The Takeaway!

Artificial Intelligence and Project Management: The First Step

OCTOBER 24, 2023

This means that project managers will also stay relevant in the age of AI if they focus on the core skills of project management, namely: Leadership , Communication (verbal & non-verbal), Empathy, Emotional intelligence, and Negotiation. [6]. However, it is important to remember that there is something AI cannot do – be human. Creativity.

How to Pass Implementing SAFe SPC Training Exam in your First Attempt

JANUARY 19, 2022

If you aspire to become an Agile Coach and then need to lead the SAFe implementation in your organization, becoming a SAFe Program Consultant is the right choice. Gather the Study Content: The first step is to go to the Scaled Agile Community website and download the workbook from the Learn > My Learning section.

4 Ways Organizations Use Goals Poorly (and How EBM Can Help)

JULY 21, 2021

Agile 2018 Conference – Unraveling Team Dependencies

JUNE 29, 2018

I am excited to be presenting on the Enterprise Agile track at the Agile 2018 conference in San Diego, August 7. It combines anecdotes and experiences from 20+ years of agile consulting along with some insights from Troy Magennis on dependency delays, and Dominica DeGrandis, author of Making Work Visible.

6 Ways Your Organizational Culture Affects Project Management

Productivity Land

FEBRUARY 27, 2023

Project management is a complex discipline requiring technical skills, leadership abilities, and effective communication. We will also discuss case studies of companies successfully aligning their organizational culture with project management goals.

How Is Artificial Intelligence Being Used in Project Management?

DECEMBER 20, 2023

How can Agile methodologies be adapted and implemented in non-software development projects?” “Why She has extensive experience with the entire Software Development Life Cycle (SDLC) using both Waterfall and Agile based development practices. There are lots of ways to go about creating prompts. Scenario-Based Prompts.

15 Easy Ways to Earn PDUs in 2020

OCTOBER 13, 2020

Education PDUs are those earned from formal and informal learning across the three areas of the PMI Talent Triangle: Technical, Leadership and Strategic and Business Management skills. Leadership and Strategic and Business Management PDUs count for every certification you hold. Education PDUs. Contribute to a Wiki.

6 Effective Strategies for Employees to Stay Ahead in the Corporate World

MAY 30, 2023

Online MBA programs allow employees to expand their business acumen, leadership skills, and strategic thinking abilities. With a curriculum that covers various business disciplines and real-world case studies , these management programs provide valuable insights and practical tools that can be directly applied in the corporate world.

JANUARY 3, 2024

Lunch and Learn

Growing Agile

NOVEMBER 10, 2021

To understand how we can harness the fear of the unknown, and leverage it as a competitive advantage To consider what courageous leadership is and how courage is viewed as a case study in more progressive companies. The post Lunch and Learn appeared first on Growing Agile . To apply these concepts in your own domains.

Stay Connected

Join 122,000+ Insiders by signing up for our newsletter

• Participate in Project Management Update
• Stay At Home Reading List
• Add a Source
• Add a Resource
• See All 
• 2018 Project Management Update MVP Awards
• 2019 Project Management Update MVP Awards
• 2020 Project Management Update MVP Awards
• 2021 Project Management Update MVP Awards
• 2022 Project Management Update MVP Awards
• Sun. May 19
• Sat. May 18
• Fri. May 17
• Thu. May 16
• May 11 - May 17
• Certification
• More Topics 

Input your email to sign up, or if you already have an account, log in here!

Enter your email address to reset your password. a temporary password will be e‑mailed to you., be in the know on.

Project Management Update

Expert insights. Personalized for you.

We organize all of the trending information in your field so you don't have to. Join 122,000+ users and stay up to date on the latest articles your peers are reading.

Get the good stuff

Subscribe to the following Project Management Update newsletters:

You must accept the Privacy Policy and Terms & Conditions to proceed.

You know about us, now we want to get to know you!

Check your mail, we've sent an email to . please verify that you have received the email..

We have resent the email to

Let's personalize your content

Use social media to find articles.

We can use your profile and the content you share to understand your interests and provide content that is just for you.

Turn this off at any time. Your social media activity always remains private.

Let's get even more personalized

Choose topics that interest you., so, what do you do.

Are you sure you want to cancel your subscriptions?

Cancel my subscriptions

Don't cancel my subscriptions

Changing Country?

Accept terms & conditions.

It looks like you are changing your country/region of residence. In order to receive our emails, you must expressly agree. You can unsubscribe at any time by clicking the unsubscribe link at the bottom of our emails.

You appear to have previously removed your acceptance of the Terms & Conditions.

We noticed that you changed your country/region of residence; congratulations! In order to make this change, you must accept the Aggregage Terms and Conditions and Privacy Policy. Once you've accepted, then you will be able to choose which emails to receive from each site .

You must choose one option

Please choose which emails to receive from each site .

• Update All Sites
• Update Each Site

Please verify your previous choices for all sites

Sites have been updated - click Submit All Changes below to save your changes.

We recognize your account from another site in our network , please click 'Send Email' below to continue with verifying your account and setting a password.

You must accept the Privacy Policy and Terms & Conditions to proceed.

This is not me

An empirical study on changing leadership in agile teams

• Open access
• Published: 22 March 2021
• Volume 26 , article number  41 , ( 2021 )

Cite this article

You have full access to this open access article

• Simone V. Spiegler   ORCID: orcid.org/0000-0002-1234-827X 1 , 2 ,
• Christoph Heinecke 3 &
• Stefan Wagner 1  

13k Accesses

14 Citations

2 Altmetric

Explore all metrics

An increasing number of companies aim to enable their development teams to work in an agile manner. When introducing agile teams, companies face several challenges. This paper explores the kind of leadership needed to support teams to work in an agile way. One theoretical agile leadership concept describes a Scrum Master who is supposed to empower the team to lead itself. Empirical findings on such a leadership role are controversial. We still have not understood how leadership unfolds in a team that is by definition self-organizing. Further exploration is needed to better understand leadership in agile teams. Our goal is to explore how leadership changes while the team matures using the example of the Scrum Master. Through a grounded theory study containing 75 practitioners from 11 divisions at the Robert Bosch GmbH we identified a set of nine leadership roles that are transferred from the Scrum Master to the Development Team while it matures. We uncovered that a leadership gap and a supportive internal team climate are enablers of the role transfer process, whereas role conflicts may diminish the role transfer. To make the Scrum Master change in a mature team, team members need to receive trust and freedom to take on a leadership role which was previously filled by the Scrum Master. We conclude with practical implications for managers, Product Owners, Development Teams and Scrum Masters which they can apply in real settings.

Similar content being viewed by others

Change Management: From Theory to Practice

A critical analysis of Elon Musk’s leadership in Tesla motors

Agile Project Management

Avoid common mistakes on your manuscript.

1 Introduction

Recently, more and more organizations aim at developing their products in a more agile way (Stavru 2014 ). Agile teams are said to work cross-functionally and self-organized in iterative learning loops towards a common goal (Conboy 2009 ). Even though an increasing number of organizations strive to implement agile teams, it is not entirely clear how teams can adopt the agile way of working (Moe et al. 2010 ; Nerur et al. 2005 ). Especially rather bureaucratic companies seem to struggle in their agile transformation (Moe et al. 2009 ; Nerur et al. 2005 ). Fitting leadership behavior is found to be one key success factor for evolving into an agile self-organized team (Gren et al. 2019 ). However, which kind of leadership agile teams need is not yet clear.

The successful implementation of self-organized teams into the industrial sector has been of ongoing interest over the last 70 years. Researchers consider the topic from different angles among which are socio-technical systems (Manz and Sims 1987 ; Srivastava and Jain 2017 ; Trist and Bamforth 1951 ), knowledge management (Takeuchi and Nonaka 1986 ), complexity theory (Bäcklander 2019 ; Schwaber 1997 ), role theory (Hoda et al. 2013 ; Yang 1996 ) and agile project management (Sutherland and Schwaber 2017 ). One recurring topic across the various streams of research is the role of leadership in a team that is by definition self-organized.

Research on leadership in agile teams mostly differentiates between a leader as peer or coach to the team who provides appropriate boundary conditions (e.g. Takeuchi and Nonaka ( 1986 )) and an autonomous team that self-organizes its operational work (e.g. Hoda et al. ( 2013 )). While some researchers suggest a facilitator who serves as a peer to team members (Takeuchi and Nonaka 1986 ) or a leader who empowers the team to lead itself (Manz and Sims 1987 ), other researchers do not consider a formal leader of the team but instead emphasize self-organizing roles within the team (Hoda et al. 2013 ).

At present, the most widely known agile approach is Scrum (Schwaber 1997 ) which divides leadership between three different prescriptive roles: the Product Owner, the Scrum Master and the Development Team. The Product Owner cares for the interaction with the customer and sets the requirements for a product. The Scrum Master facilitates the Scrum process, enables the team to work cross-functionally and self-organized, protects the Development Team from external disruption and helps the organization to adapt to the agile way of working (Sutherland and Schwaber 2017 ). The Development Team self-assigns tasks towards a shared goal (Cockburn and Highsmith 2001 ).

It is not entirely clear how the Scrum Master and the Development Team share leadership. While some empirical studies reveal that leadership is rather focused on one dedicated Scrum Master (Moe et al. 2010 ), other studies suggest that the whole team takes on leadership (Srivastava and Jain 2017 ).

The aim of the dedicated Scrum Master is shared leadership. In this paper, we use the understanding by Pearce and Conger who “define shared leadership as a dynamic, interactive influence process among individuals in groups for which the objective is to lead one another to the achievement of group or organizational goals or both. This influence process often involves peer, or lateral, influence and at other times involves upward or downward hierarchical influence.” (Pearce and Conger, 2002, p. 1) This paper focuses on the link between one dedicated person who takes on leadership and sharing leadership within the team.

We examine leadership in agile teams using the example of the Scrum Master. We consider the dedicated Scrum Master to be a leadership enabler who follows the goal to empower a team to work in an agile way and to share leadership. A leadership enabler transforms followers into leaders while the team matures. The Scrum Master does not aim at a specific quantity or quality of output (Bäcklander 2019 ). We will focus on leadership of the Scrum Master and the Development Team, because we want to understand how the Scrum Master and the developers share leadership over time (Moe et al. 2010 ).

Empirical research on Scrum teams revealed that the Scrum Master does not always split leadership openly with the team but occasionally becomes an obstacle for distribution of leadership within teams in early stages. This is because the Scrum Master tends to stick to a command-and-control mode in newly established teams (Moe et al. 2010 ), while the Scrum Master in a more mature team enables the Development Team to lead itself and to share the leadership role among team members (Srivastava and Jain 2017 ).

These findings could be explained by changes in the maturity of agile teams. Cockburn ( 2002 ) hints at the Japanese philosophy of Shu-Ha-Ri to explain that an agile team matures while they practice Scrum. The team learns how to work in an agile way over time and therefore needs more guidance by a Scrum Master in a less mature stage (Gren et al. 2017 ), while the Scrum Master is even suggested to be shared among developers in mature teams (Hoda et al. 2013 ).

Despite a few qualitative studies that specifically focus on exploring leadership in agile teams (Srivastava and Jain 2017 ; Bäcklander 2019 ), the empirical research on this topic is still underrepresented in the software development community. Besides the high popularity of the method Scrum, the current description of the Scrum method does not provide sufficient information on leadership in agile teams. While the Scrum Guide describes three prescriptive roles, this paper explores descriptive roles. In this article, a descriptive role describes a set of performed, connected activities. Descriptive roles are informal and transient, which implies that they are not linked to a specific position or status (Hoda et al. 2013 ).

To be able to support organisations in an agile transformation, our research objective is to explore how leadership changes while the team matures using the example of the Scrum Master. We believe investigating changing leadership of the Scrum Master will provide valuable insights into how teams can learn to work in an agile way.

Our study focuses on implementing agile teams in bureaucratic companies that are in the middle of their agile transformation. This type of organisation opposes the agile way of working (Nerur et al. 2005 ). It is used to rely on a hierarchy in contrast to self-organizing teams (Moe et al. 2012 ), to rigid planning instead of iterative learning (Boehm and Turner 2005 ) and to divide work according to functional departments instead of cross-functional teams (Nerur et al. 2005 ). In this paper, we use the terms bureaucratic company and traditional development company interchangeably.

We present findings from a study at 11 business divisions of the conglomerate Robert Bosch GmbH, primarily operating in the automotive industry.

We applied grounded theory (Charmaz 2016 ) and conducted three different rounds of interviews. While the first round contained 22 unstructured interviews with practitioners from various roles, including agile coaches and Scrum Masters, the second and third round included 53 qualitative semi-structured interviews with practitioners from 29 different software and non-software project teams that had applied Scrum over a period of three months up to three years. The interviews were supplemented by observations of Scrum meetings and of visiting team rooms. We analyzed derived data and received feedback by agile practitioners on our results to check whether our findings were consistent.

We identified a set of nine leadership roles: Method Champion, Disciplinizer on Equal Terms, Coach, Change Agent, Helicopter, Moderator, Networker, Knowledge Enabler and Protector. We have found that those roles are rather centred on one dedicated Scrum Master in early stage while the roles are rather distributed in more mature teams. We further identified the role transfer process which involves a supportive internal team climate and a leadership gap that enables team members to take on leadership roles.

The main contribution of this paper is to provide a deep insight into the agile transformation at a conglomerate that widely uses the Scrum method to empower self-organized teams. This paper extends our previous conference paper on the changing Scrum Master (Spiegler et al. 2019 ) by the following parts: we add more content on the theoretical background in Section  2 . We provide additional data on the nine leadership roles in Section  4.1 and new data on the internal team environment in Section  4.3 . Moreover, we provide evidence on the impact of the retrospective on the internal team environment in Section  4.4 . We further describe limitations of the role transfer by referring to role conflicts in Section  4.5 .

Our results help practitioners to understand how teams change from a rather traditional way of working to an agile approach by focusing on leadership. This also helps managers to learn how they can support developers in their agile way of working.

The rest of the paper is organized as follows: In Section  2 , we refer to related work on the Scrum Master and describe how maturity helps us in understanding changing leadership in agile teams. In Section  3 , we outline our study design. In the following Section  4 , we present the results of our qualitative interviews including the description of the nine leadership roles and the role transfer process. We discuss how our findings relate to other research in Section  5 . In Section  6 , we provide practical implications, and in Section  7 we refer to limitations and suggest future research.

2 Related Work

We aim at exploring the change in leadership using the example of the Scrum Master. We will first refer to research related to maturity in agile teams, and afterwards elaborate on research on leadership in agile teams.

2.1 Maturity

Team literature research differentiates between dynamic and static teamwork models. While static teamwork models refer to teams that are stable and have successfully reached a constant mature stage, dynamic models assume that a team undergoes different maturity stages. This study focuses on dynamic models because we believe the differentiation between mature and immature teams may help us to explain a change in leadership.

Since the first empirical study on group development phases by Bales and Strodtbeck ( 1951 ), different authors suggested conceptual models on group development phases among which the probably most famous one is the forming-storming-norming-performing model by Tuckman ( 1965 ). Tuckman differentiates between several phases:

The forming phase sets ground rules for interaction between a leader and the team as well as between team members. The storming phase often involves conflicts due to absence of unity and insecurity. The norming phase helps teams to build a shared understanding of roles and responsibilities (Neuman and Wright 1999 ). The performing stage describes that team members play roles flexibly according to what makes most sense in a given situation (Tuckman 1965 ).

While early researchers suggest successive phases on group development, later on authors criticized this approach and suggested that each group develops differently.

For example, Gersick ( 1989 ) and Ginnett ( 2019 ) suggest the first meeting to be decisive for the further collaboration of a team. Still others suggest an iterative approach wherein the team continuously revolves between different phases (Marks et al. 2001 ).

The maturity model by Tuckman was shown to be suitable to explain different development stages of agile teams. Gren et al. ( 2017 ) found a relationship between the group development stages and team agility and speculate that depending on the maturity level of a team, developers practice the agile way of working differently. For example, they suggest that a rather immature team needs structure and order and that it will not accept agile leadership behavior, whereas a mature team is able to self-organize better which allows the Scrum Master to step back. They furthermore identify the retrospective to be a tool that helps the team in developing maturity (Gren et al. 2019 ).

This paper explores how leadership changes while the team matures.

2.2 Leadership in Agile Teams

We investigate leadership in agile teams using the example of the Scrum Master. Most papers on the Scrum Master are based on personal experience and common sense and lack in theory and structured approach to data collection. The leadership perspective on the Scrum Master varies among researchers. Some authors elaborate on research that focuses on individuals as leaders, while other researchers assume that leadership in agile teams can also be conducted by several individuals.

Bäcklander ( 2019 ) refers to complexity leadership behavior and considers the Scrum Master to be an enabling leader without disciplinary power. Often developers grow into Scrum Masters over time. Since its application to a software company the role description has evolved from specifically focusing on the Scrum Method to caring for team dynamics. Furthermore, the Scrum Master continuously balances providing a structure, e.g. with the help of the retrospective, and not providing a structure, e.g. by being absent. Bäcklander ( 2019 ) concludes that leadership literature and team literature are tightly linked together, since enabling leadership fosters team processes, such as team learning (Edmondson 1999 ). She suggests further research on how team members can take on leadership.

A study on group development of agile teams (Gren et al. 2017 ) refers to situational leadership theory which derives from the contingency stream. Contingency theory suggests that the situation influences the effectiveness of a leadership style (Fiedler 1967 ). Situational leadership describes that the leader should change behavior if the followers develop (Hersey et al. 2007 ). Gren et al. ( 2017 ) speculate that a rather immature team needs structure and order to organize itself, while a mature team is able to self-organize which allows the Scrum Master to step back (Gren et al. 2017 ). Moreover, leaders adapt their behavior to company specific culture and structure (Gren and Lindman 2020 ).

In contrast to the aforementioned perspective on the Scrum Master being linked to one individual leader, other authors refer to leadership sharing between one dedicated individual and the agile team (Moe et al. 2010 ; Srivastava and Jain 2017 ).

Moe et al. ( 2010 ) observe teamwork challenges of a newly established Scrum team over a period of nine month. They refer to team leadership which means in their context to provide direction, structure, and support for other team members, such as active listening, and can be shared among Development Teams, Product Owner and Scrum Master. Moe et al. ( 2010 ) reveal that the Product Owner and the Scrum Master rather reduced team leadership by starting to control team members and not listening to their concerns. Consequently, developers demonstrated a lack in trust and willingness to reveal their impediments openly. However, the authors acknowledge that while the team matured, team members started to take on more responsibility and therefore team leadership improved over time. Moreover, the authors state that teams need management support and resources to grow into self-organization.

Srivastava and Jain ( 2017 ) present a leadership framework of the Scrum Master in locally distributed teams that had been working in an agile way for three years on average. They refer to super leadership (Manz and Sims 1987 ), which describes that a leader enables a team to lead itself. They conclude by suggesting rotational leadership, which implies that the Scrum Master is shared among team members depending on the situation. Moreover, they refer to Carson et al. ( 2007 ) and acknowledge that the development of team leadership needs to be accompanied by shared purpose, social support and voice.

2.3 Discussion of the Literature

This paper focuses on leadership in agile teams using the example of the Scrum Master. The scarce empirical findings reveal contradicting results on the Scrum Master. While some authors refer to the Scrum Master as an individual leader (Bäcklander 2019 ; Gren et al. 2019 ; Gren et al. 2017 ), others refer to shared leadership (Moe et al. 2010 ; Srivastava and Jain 2017 ). Some authors describe that a Scrum Master struggles with command-and-control behavior, while team members neglect to take on leadership responsibilities (Noll et al. 2017 ; Stray et al. 2011 ). Researchers still struggle with the inherent paradox of leadership in a team that is supposed to be self-organizing. Thus, leadership in agile teams is not yet sufficiently understood.

We aim to contribute to research on agile teams by focusing on changing leadership. So far, researchers have not built a bridge between one dedicated leader in an immature team and leadership sharing in a mature team.

The Scrum Master either had been found to be centered on one dedicated person in an immature team (Moe et al. 2010 ) or has been suggested to be played by multiple group members in mature teams (Srivastava and Jain 2017 ). Moreover, the company context (Gren and Lindman 2020 ) and the team climate (Carson et al. 2007 ) influence leadership. Our aim is to explore and portray the characteristics of a Scrum Master in immature as compared to mature teams and to describe how leadership changes. To the best of our knowledge, the theoretical suggestion of changing leadership while the team matures (Gren et al. 2017 ) has never been empirically investigated.

This paper aims to explore how leadership evolves while the team matures, in such a way that leadership is shared between the Scrum Master and the Development Team over time. Our results indicate that the Scrum Master plays diverse leadership roles which can be transferred from one individual to distinct team members during the maturity journey.

While empirical data on the Scrum Master is often missing or merely based on single case studies, we provide qualitative data from multiple teams operating at different companies of one conglomerate.

3 Study Design

3.1 research method.

We aim to explore changing leadership in agile teams. Research on human interaction in software development teams is still scarce. We chose grounded theory because this method is applied in research fields with scarce knowledge (Glaser and Strauss 2017 ).

This research method requires to start collecting empirical data without a specific research problem and research question in mind, since this is expected to emerge during the research project at the field. Following grounded theory we collected data in an iterative manner based on emerging patterns and themes, while constantly comparing emerging data (Glaser and Strauss 2017 ).

Grounded theory can be conducted by applying a positivist and constructivist view (Bryant and Charmaz 2007 ). The positivist perspective claims that there is an objective reality, which is linked to the Glaserian point of view. The constructivist view aims to explain subjective reality of individuals that is embedded in the specific context and situation in a particular point in history (Bryant and Charmaz 2007 ). Our objective is to describe how individuals make sense of the ongoing transformation at a rather traditional development company. We aim to describe which kind of leadership individuals believe to be useful during an agile transformation.

The constructivistic approach aims to reveal multiple perspectives on reality (Charmaz 2016 ). Therefore, there may not only be one point of view reflected by the research participants. Moreover, participants may behave in a certain way due to social conventions and power relations (Charmaz 2016 ). We search for underlying assumptions that foster specific behavior (Charmaz 2016 ).

While we apply the iterative approach of the data analysis method by Glaser and Strauss ( 2017 ), we take a constructivist view when interpreting the data.

3.2 Company Context

We conducted this study at Robert Bosch GmbH which employs more than 410,000 people in 60 different countries worldwide. The company history dates back to 1886 and can therefore be classified as established company. The conglomerate is active in four different business areas: mobility solutions, industrial technology, consumer goods as well as energy and building technology. Each business area consists of various subsidiaries and business divisions. Therefore, market conditions and subcultures vary wildly.

While the agile transformation started as a headquarter project that supported divisions in their agile journey, now each division is responsible for its own agile transformation. One wildly used agile approach across various sub-companies is the framework Scrum. Some sub-companies implement Scrum without changing the organisational context (e.g. structure). Other sub-companies implement the Scrum framework while also transforming the whole organisation. Even though a corporate role description of and training for a Scrum Master exists, there is neither an obligatory training nor mandatory leadership responsibility regarding the role.

Internal trainers offer corporate training on diverse topics of the agile way of working, yet, each team can decide on its own how to educate the team and the Scrum Master. For example, a team could book a training internally or externally of the company or not book a training at all.

With scarce exception Scrum Masters are without disciplinary power, responsible for the Scrum process and in charge of team development. Moreover, most practitioners of the company call the Scrum Master Agile Master , indicating that this role should adapt to the specific team, rather than sticking to the Scrum approach by the book. Interviewed teams stated that they apply the Scrum method mostly in modified form, e.g. w.r.t. the regularity of Scrum meetings.

3.3 Data Collection

Since the first and second author are employees of the company, we had direct access to the field. We collected data by conducting interviews and observations, and collected feedback on emerging results from practitioners. We identified Scrum practitioners either via our personal network or via the company’s social media platform and first contacted them by email. We collected data from 11 business divisions which have slightly different subcultures.

Due to confidentiality requirements by the Robert Bosch GmbH, the raw data cannot be provided openly.

Between June 2017 and November 2018 we conducted three different turns of interview collection based on previous findings. Most interviews were conducted in German and later on translated into English. Some interviews were conducted in English.

The first round of interviews included 22 individuals from 10 different sub-divisions. The sample contained all kind of organizational roles including but not limited to Scrum Masters, developers and organizational coaches. The second and third round of interviews includes 22 Scrum Masters, 8 Product Owners and 23 team members from 14 software development and 15 non-software project teams. Some but not all Scrum Masters were certified Scrum Masters. Likewise, some but not all Scrum Masters visited meet-ups and internal conferences to exchange knowledge with other Scrum Masters. The size of teams ranged from 5 to 12 members and often included diverse nationalities. Since the age of teams stretched from three months up to three years, we expected the maturity of teams to vary.

We conducted most qualitative interviews face-to-face while very few interviews were conducted via skype. We scheduled the meetings according to availability and willingness to take part. One interview lasted approximately 45 minutes on average. While the first set of interviews was based on hand-written notes, the second and third round of interviews were audio-taped and transcribed.

Observations

It is recommended to supplement semi-structured interviews by observations to understand the context of the interviews (Adolph et al. 2008 ). The main author observed Scrum events, such as the daily stand-up, review, planning and retro, of sixteen Scrum teams from four different sub-companies. She observed ten of the teams between an hour and a whole day and six of the teams over a period of several months. While observing, the author made nodes and asked clarifying questions afterwards if necessary.

We collected feedback from Scrum practitioners by presenting preliminary findings to observed teams and discussing upon the results. Moreover, preliminary concepts were presented on two internal open space formats, two interactive workshops, one presentation and several one-to-one conversations with practitioners from the company. During discussions with Scrum practitioners the main author made nodes and the participants of the workshops send their group work results to the main author. This material was used to refine and strengthen the developed concepts and add to validity.

During our data collection the first author wrote memos. She wrote down emerging questions, new ideas and relationships between codes and categories while collecting, analyzing and discussing data. Moreover, the memos stored ideas about links between the data and relevant literature.

3.4 Data Collection Procedure

Grounded theory suggests theoretical sampling (Glaser and Strauss 2017 ) in which each step determines the next step to be taken during the research based on previous results. The iterative approach (Glaser and Strauss 2017 ) lead us to the above enumerated three rounds of data collection which will be described thoroughly in the following.

First Round

Grounded theory requires a general up-front research topic (Hoda et al. 2012 ), which was leadership in agile teams.

The research problem should emerge from a challenge that practitioners face (Glaser and Strauss 2017 ). During the first round of unstructured interviews with practitioners from various business divisions and diverse organizational roles, we realized that there was a lack of clarity regarding the Scrum Master. Practitioners agreed that a Development Team was expected to be self-organizing, yet, how the Scrum Master was supposed to enable the team to do so was not entirely clear. Moreover, while some practitioners referred to the Scrum Master as a leader, others opposed the idea that the Scrum Master should be labeled a “leader”. Comparing our results with the Scrum Guide and with scientific literature we found that there was not yet sufficient information to fully explain leadership of the Scrum Master as it is practiced in this organizational setting.

The purpose of the first round was to get an overview on relevant topics and derived data is not included in the results section.

Second Round

Thereafter we conducted a second set of interviews mainly interviewing Scrum Masters besides a minority of developers. A semi-structured questionnaire focusing on the development of leadership behavior of a Scrum Master guided the interviews and allowed further questions when the answer of an interviewee appeared to offer more insights. Interviewees were asked to describe what they did to support agile teams and what they had learned since they had started to play the Scrum Master. The guiding questions are available online (Spiegler et al. 2018 ).

We identified nine leadership roles which the Scrum Master performs. Yet, the interviews revealed that not only the Scrum Master conducted leadership but that developers tended to take on some of the Scrum Master activities, as well.

Third Round

We developed a second questionnaire that focused on sharing leadership between the Scrum Master and the Development Team with a specific interest in how the sharing of leadership had developed over time. Moreover, we asked questions regarding supporting and hindering factors of taking on leadership.

Our third round of interviews approached entire teams and viewed the Scrum Master from three different angles: the Product Owner, the Scrum Master and the Development Team.

This helped us in understanding how the Scrum Master evolved while the team matured and how leadership activities were shared among developers and the dedicated Scrum Master. We came to realize that Scrum teams without a Scrum Master struggled with working in an agile way.

Theoretical saturation of data describes that data collection stops if data analysis does no longer reveal new patterns (Charmaz 2016 ). We stopped collecting data when we perceived that the content of the interviews was repetitive and data analysis revealed no more new insights.

During the research process the following research questions emerged

RQ1: How does the Scrum Master perform leadership in an agile team?

RQ2: In which way do team members take on leadership over time?

RQ3: How is leadership transferred from the Scrum Master to the Development Team?

RQ4: What is the underlying internal team environment required for the transfer of leadership?

RQ5: How can the Scrum Master foster the internal team environment?

RQ6: Which expectations on the Scrum Master limit the changing leadership?

3.5 Data Analysis

We followed the instructions for Glaser’s open coding as described in the dedicated paper by Hoda et al. ( 2012 ). While Glaser and Strauss ( 2017 ) have a positivist view, we had a constructivist perspective for interpretation of data (Charmaz 2016 ).

We openly coded transcripts sentence-by-sentence. We aligned codes that appeared to be alike to one concept. The content of the interviews was constantly compared within the same interview and across interviews. We constantly reflected and compared emerging concepts critically. Observations helped us to place the content of the interviews into context.

Quote: If I am convinced of something I bring it into the world. [...] simply I bring agility with me, always on the basis of a mind-set [...], so that people can understand why it makes sense to work in that way. (AM)

Key Point: serves as role model to others

Codes: role model, agile mind-set, change team

Concept: Change Agent

Category: Leadership Role

This example reveals that the Scrum Master convinced some team members of the agile manner by acting as a role model. The codes merged to the concept Change Agent . Overall we identified nine different concepts during our iterative data analysis. Our core category is leadership role . One leadership role is a set of performed, connected activities that influences individuals with the objective to lead one another to the achievement of team or organizational goals or both. We chose the term role because it expresses a set of connected activities that is unrelated to a position or title. A leadership role can be either performed by a developer or a Scrum Master. A leadership role emerges context-dependent.

Scrum Masters explained that they gradually lead the team less and also that sometimes they empower the team by keeping back, which we labelled leadership gap . Through constant comparison (Glaser and Strauss 2017 ) of various interviews and observations we identified nine different leadership roles and developed a substantive theory (Glaser and Strauss 2017 ) which we termed the role transfer process .

While analysing our data we compared emerging concepts with existing research in agile software development. We had identified new roles, but also roles that were similar to findings of other studies. The names of the nine leadership roles resulted from their relation to the agile team features, e.g. the Knowledge Enabler aims at continuous learning, but also from previous research on human behavior in agile development teams, e.g. the Change Agent is named a critical role during the agile transition (Parizi et al. 2014 ).

During data analysis we made a few sketches, quick power-point presentations and used sticky notes on whiteboards demonstrating preliminary results. We critically discussed the concepts in our researcher group and with practitioners. This led to a refinement of the concepts.

3.6 Validity Procedure

At the beginning of each interview, participants were informed about the purpose of this study and assured of confidentiality, so as to receive open and honest responses.

The majority of participants spoke openly, also about their personal concerns what was not working well in their organisation or in their agile team. There were three people from three different teams whose overly positive statements did not match with the comments on the same topic from other interviewees of the very same team. Moreover, after the official part of the interview had finished, the interviewees made contradicting statements to what they had claimed during the interviews. Since the authors could not be sure whether social response bias applied, those three participants were excluded from the sample.

The aim of a constructivist study is to reveal the reality how research participants perceive it (Bryant and Charmaz 2007 ). To ensure that we captured the perception of the research participants accurately, we received feedback from practitioners as described in Section  3.4 , and from the research community during presentations and informal discussions. Moreover, we did not only conduct interviews but enriched our data by observations and further feedback sessions such as workshops. Despite these measures, our data analysis involves subjective interpretation of the researchers which is a well-known issue in grounded theory (Charmaz 2016 ).

In this section, we illustrate the findings of our interviews.

We grouped our findings on leadership in agile teams into the following nine different leadership roles that empower a team to work in an agile way: Method Champion, Disciplinizer on Equal Terms, Coach, Change Agent, Helicopter, Moderator, Knowledge Enabler, Networker and Protector. While some teams described that the leadership roles were rather centred on the Scrum Master, other teams outlined that leadership of the Scrum Master had changed over time. In the latter cases, developers started to take over some of the leadership roles themselves and the Scrum Masters diminished the extent to which they played those roles.

We first describe the leadership roles as they were played by the Scrum Master (RQ1) and then outline the leadership roles as they were performed by the team (RQ2). Thereafter, we refer to the role transfer process which build the bridge between both levels of analysis (RQ3). We further describe the underlying internal team environment which serves as an enabler of transferring leadership (RQ4) and the supportive role of the retrospective (RQ5). We conclude by reporting on role conflicts which limit a change in the Scrum Master (RQ6).

To respect participants’ confidentiality, we cite them by AM (Agile Master), Dev (Developer) and PO (Product Owner).

4.1 Nine Leadership Roles

4.1.1 role 1: method champion.

The interviews revealed that teams often adapted the Scrum Method to their specific context. Even though the Scrum framework may help a team to work in an agile way, Scrum was not always perceived to be beneficial in every team setting. Often the team needs support in finding the appropriate method for a specific context (Moe et al. 2009 ; 2010 ).

Well, I actually bring a broad method toolbox and expertise to the table. I’ve noticed it everywhere, like creative techniques. It’s all about technical topics, if you can get them fast, you can create proper workshops and pick the right method. It can be a real door-opener. (AM)

While some Scrum Masters insisted on doing Scrum according to the book, a large majority of Scrum Masters mentioned conducting and adapting the method to be their main task when working with agile teams. We label this role Method Champion which describes activities related to the implementation and application of the Scrum Method. On the one hand the Method Champion adapts the Scrum method to the specific team context, on the other hand the role aims at realizing when the Scrum approach is not the most fitting one regarding the context. Some Scrum Masters described that they introduced other methods besides Scrum, e.g. XP or Kanban.

Also two Development Teams explicitly stated that the developers visualised information on a board on their own initiative and that this was the way they learned and exchanged knowledge. Moreover, some teams stated that the Scrum Master had initially organised team events but after some time the team members organised such events themselves.

4.1.2 Role 2: Disciplinizer on Equal Terms

Initially, some team members were reluctant to follow the Scrum process. Some Scrum Masters reported that when they insisted on discipline, such as only talking for a certain amount of time during the daily or to follow up on measurements they had agreed on during the retrospective, the team members started to see the benefit. We call this role Disciplinizer on Equal Terms which describes to help the team to focus on respective tasks and stops developers from multi-tasking.

There are people [...] after a quarter of an hour they still talk. You do that two or three times and then you point it out carefully, it doesn’t work like that. And more and more clearly and at some point I set a clock in the backlog, in the stand up and said hey, we are out of time. (AM)

However, there were also developers who did not appreciate this role and rather felt they were forced to behave in a certain way. While some developers welcomed timekeeping, others felt that the Disciplinizer was more interested in following a process than caring for people. Since one agile principle involves people over processes , we are not entirely convinced that the Disciplinizer can be considered an agile role. Therefore, we add the on equal terms to the name. In agile settings, individuals treat each other unrelated to title or position (Hoda et al. 2012 ).

The aim of the role is to help the team developing focus and discipline without directly monitoring teams top-down but communicating on a par. During different Scrum events we observed, that the Disciplinizer on Equal Terms did rather not involve forcing the team to focus by referring to hierarchical power, e.g. by asking for status reports.

We assume that interaction on equal terms creates non-hierarchical spaces which are important to speak openly with each other, suggest new ideas and allow every team member to take on responsibility.

While at the beginning the Scrum Master was more concerned on discipline, also the developers started to emphasize on the agile value focus . Some improved focusing on their operational tasks.

I also used to have this switch. That was a lot! So I tried to focus on one specific thing, on this day, for this particular amount of hours. (Dev)

Whereas other developers reminded their fellows to stop endless discussions.

Usually it is a team member who says, ok we could talk about this another 40 minutes but the facts will not change. (Dev)

We also observed in several teams that after 2 to 3 months developers started to tell the Scrum Master that he or she should stick to agreed rules, e.g. not being late for meetings or only talking for a certain amount of time.

4.1.3 Role 3: Coach

Often interviewees claimed that they observed team behavior to identify which kind of team behavior was missing for executing the agile way of working and to help the team to develop this behavior. Some interviewees also said that they brought developing conflicts to the surface. We label this role Coach . A coach helps developers to constantly develop themselves further by setting triggers, such as asking the right questions at the right time (Kozlowski et al. 2009 ), and by encouraging for self-criticism, observation and feedback delivery (Manz and Sims 1987 ). Several interviewees described these activities.

Scrum Masters emphasized that they aimed at supporting the team to reflect upon their behavior and continuously improve mastering the agile way of working.

What you always deal with is to think and observe what went well in the team and what did not go so well. [...] As a team coach you often have to act from the background and observe strongly at first. (AM)

Therefore, this interviewee did not act as a visible leader, but rather supported cautiously from the background. Previous research has described that an immature team that aims to become self-organized needs a supportive coach (Wageman 1997 ; Magpili and Pazos 2018 ). Yet, we found that the Coach was not linked to a specific person like the Scrum Master, but that anyone in the team could act as a Coach. For example, one developer described how the team established psychological safety over time during the retrospective.

The retrospectives [...] push us to actually stand up for some opinion, to say what is wrong or to open up, and then he [the Scrum Master] unleashed the monster. I have always been very critical about lots of stuff, but now I see that everyone is critical sometimes, now I see that they [the other team members] actually care to say “look, I am not happy about this” and speaking openly had never happened before. (Dev)

This developer expressed how mutual trust created an atmosphere within which team members felt safe providing feedback to each other. When trust among team members increased, it was no longer merely the Scrum Master who revealed personal observations.

While the Method Champion knows distinct project management methods like Scrum, Kanban or XP, and can consult the team on the different methods, a Coach helps the team to understand which way of team behavior needs improvement. Someone who acts as a Coach may be good at asking the team the right questions, but may not necessarily know anything about project methods.

4.1.4 Role 4: Change Agent

The Change Agent relates to two different facets: convincing stakeholders of the agile way of working and serving as a role model.

Some individuals would persuade managers or other stakeholders to behave in a more agile way. The overall aim is to convince individuals why agile values and principles are relevant and useful.

If you do not set an example [...], you will not be able to take the team on that journey and to take that road. (SM)

This quote allows to speculate that dedicated leaders who expect the team to behave in a more agile way, but do not embrace agile values and behavior themselves, will most likely not inspire developers to work in an agile manner.

Some Scrum Masters described to serve as a role model by believing in the agile values.

If I am convinced of something I bring it into the world. [...] simply I bring agility with me, always on the basis of a mind-set [...], so that people can understand why it makes sense to work in that way. (AM)

The developers learn the agile manner by observing the Change Agent and imitating this behavior. Therefore, it is especially important at the beginning when implementing agile teams. While the team matures team members become more and more convinced of the agile manner, hence the Change Agent is played to a lesser extend.

Back then when I started with agile development, it was rather amusing. Because we felt like animals in a circus. At first, there was astonishment, then amusement, later interest and, finally, they asked whether they [our partner team] couldn’t do it the same way. But this was not a process of a few days. It rather took several months. (PO)

This example demonstrates that agile teams started to serve as role models for traditional project teams who apparently had raised the wish to also start working in an agile way.

It may make sense to start an agile transformation with a team that embraces several team members that naturally bring the agile values with them. Those will than inspire others.

While the Coach helps the team to develop itself further by asking the right questions, and the Method Champion focuses on implementing the right project methods, the Change Agent serves as a role model to others.

4.1.5 Role 5: Helicopter

Teams have a cross-functional understanding of the overall project, in order to be able to self-organize their work and to make fast high quality decisions towards a common goal (Cockburn and Highsmith 2001 ; Takeuchi and Nonaka 1986 ).

During our interviews we identified a role we call Helicopter which implies the ability to catch the big picture of a project, to understand how topics are interrelated and to know who possess the right skill for a certain task within the team.

During the observation of one team over several months, we observed that a Scrum Master constantly took on the Helicopter during the daily. Yet, this limited the degree to which the developers acted as Helicopter. The Scrum Master complained, that the Development Team did not work in a more cross-functional way, and that he had to be the mediator of the diverse threads. After this conversation during the Retrospective, the developers started to pay more attention to each other’s skills and competences.

Either it is good if the team itself has the complete overview and everyone knows a little bit of everything or you need someone who kind of intellectually brings the threads together. Well, someone who spots what people get out of single issues. So to say if there was a complex heterogeneous team and you let it work independently, they may not necessarily look to the right and left what other people can do. (AM)

Also in other heterogeneous teams the developers learned to have the bigger picture in mind. Due to daily communication and visualisation, team members formed a mutual understanding (Moe et al. 2010 ; Hoda 2011 ) while they matured, so that they knew who had which knowledge or skills, and whom they should hand over a task if they have finished it and needed someone else to continue working on it.

But one can sense now that we try to exchange information with each other more and more, because we also see the complexity. It is really no longer the way it used to be that someone says: ’hey, I pick this single topic and do it all by myself.’ [...] Because there are always some dependencies between topics and we try to sit together from the beginning. And this is how everyone gets to know the other topics a little bit. (Dev)

We speculate that the reason for the Helicopter is that developers tackle complex projects, which implies that one individual cannot understand how all matters of the project are linked to each other. Therefore, they need to build shared mental models (Levesque et al. 2001 ) of each others competences and skills to understand in which way tasks are interdependent. This allows them to plan and divide their work among each other according to the team needs and personal fit (Hoda et al. 2012 ).

4.1.6 Role 6: Moderator

Agile teams work cross-functionally which implies varying cognition, behavior and personalities (Takeuchi and Nonaka 1986 ). This may involve different domain languages and working habits, and may cause a lack in understanding each other properly.

The Moderator moderates all kind of meetings and builds a bridge between perspectives and domains, and thereby helps the cross-functional team develop a shared understanding.

Several Scrum Masters mediated between individuals from different domains and helped the team to tolerate each others point of view.

We like to discuss a lot, thus the Scrum Master needs to moderate the conversation, to mediate between different points of view. (PO)

We have not come across any team within which the Development Team succeeded in playing the Moderator. One team had attended a well-prepared meeting which was moderated by a developer. While it was supposed to be a retrospective it had ended up in a planning instead. Two teams believed that the Scrum Master needed to be the Moderator since it was considered to be difficult to remain neutral during a discussion while being part of the operating team.

While Helicopter focuses on the product as a whole and links technical issues to individual’s skills, Moderator makes sure that developers talk about the same and discuss constructively with each other.

4.1.7 Role 7: Knowledge Enabler

The aim of the Knowledge Enabler is to teach the team a new approach to learning, thereby team members work themselves fast into new topics and solve complex issues which had not been solved before.

They just do not know the whole approach and how to access it. They know classic learning like you go to a training or you study a book, but in this field, you have so many user groups, meet-ups […]. And we also try to just propose a nice event. They can meet other people there and discuss with them. For example, we all went to a conference together. (AM)

This interviewee felt that the Scrum Master helps teams who are used to a rather traditional way of learning, e.g. learn with the help of a book, to a more unconventional way of learning, e.g. using github or attending meet-ups. The role recognizes which kind of knowledge the team needs, e.g. expert information or methodological skills, and supports team members to acquire that knowledge, e.g. sends them to training or conferences, and schedules knowledge exchange meetings.

The Knowledge Enabler supports and reminds the developers of team learning (Edmondson 1999 ) and of transparent knowledge sharing. For example, the role encourages learning sessions for sharing knowledge openly with colleagues and for learning from each other.

Some Scrum Masters urged developers to take time for learning and to share knowledge more openly with each other.

There is one person who is a specialist. It is important to me that not everything goes through this person, but that this person explains to the other person how it works. So that this person can do the job him- or herself in the future. The person should get the ability to solve the task by him or herself in the future. (AM)

In a traditional organisation, developers expect their supervisors to own deep technical knowledge and teach them. While a few team members expected the Scrum Master to own technical expertise to provide feedback, other interviewees had learned to receive feedback from their peers. They shared improvements and lessons-learned and served as a sparring partner. Developers also described to simply approach colleagues to ask for information, to learn from each other and to work together on tasks. For example, some developers would do pair programming.

Agile projects often tackle new challenges which require an inspect and adapt approach and learning on the job (Takeuchi and Nonaka 1986 ). The technical issues have not been solved before, and thus the classic approach to learning is less helpful. Therefore, developers learn iteratively and apply team learning (Edmondson 1999 ).

4.1.8 Role 8: Networker

Even though an agile team is cross-functional, it does not contain all expertise needed within one team but has access to all competences needed (Takeuchi and Nonaka 1986 ). The agile team connects to external parties depending on specific Sprint goals.

We uncovered a role Networker . It connects the team with relevant stakeholders, from within and outside the organisation, and thereby ensures that the team has access to required support that goes beyond the competences and skills within the team.

Several Scrum Masters reported to approach relevant stakeholders depending on the team’s demand. For example, they invited management to gain support or called internal administrative support when needed.

For me it is very important to see and help people when they need external help. This is very important too when they need to go outside of the team to contact somebody else. In Organisation or even outside the project. (AM)

Over time, developers increased their personal network and learned whom they could approach for what. Moreover, during dailies team members increasingly offered personal network contacts to their team members. This increased access to knowledge and improved speed of solving tasks.

For example, that one has an information for someone, that he normally would not have access to as a planning guy. […] Actually, I bring in my network from production and the developer his network and the TEF person yet another. During the open discussion at the Daily Stand-Up, I can say that I have a problem. Someone knows someone who can help me with it. (Dev)

The Networker bridges the team with the organisation. Developers can approach any stakeholder unrelated to position or hierarchy. A project team embedded in a traditional hierarchy has to keep to a official, formal communication chain, and often a team and superior managers do not talk directly to each other. Also colleagues from neighbouring departments tend to not speak directly with each other but via department managers. A team leader or group leader may serve as a mediator. In an agile team, developers can directly approach any colleague or manager in the organisation.

4.1.9 Role 9: Protector

Like Networker, Protector is a role that focuses on the organizational setting. Development Teams need interference-free space to focus on their respective Sprint goals (Stray et al. 2011 ). Therefore, the team needs a Protector who shields the team from disrupting and unreasonable requests (Stray et al. 2011 ). The Protector aims to maintain trouble-free working conditions as Development Teams are meant to focus on their respective sprint goals only.

Managing stakeholders. Talk to all those who are involved in the reviews, those who have had arguments from time to time, and communicate with them. That way they can keep work off the table. Talk to them, because they always asked, ’do this and do that’. Then simply say that this makes us no longer capable of acting. (AM)

Scrum Masters reported to shelter the team from re-prioritisation or excessive work demands by the Product Owner. Moreover, Scrum Masters protected the team from management interfering in daily business or reversing team decisions.

But then, I also pushed some things through in certain teams, [...] in which managers had taken decisions again. I had to go to the management and tell them “that is not OK, you make a mistake”. Then they had to compromise and later they were really glad that they had reacted that way. Because the team gave the right hints after all. That is a situation in which one has to fight a battle on behalf of the team. (AM)

However, multiple team members reported on occasions when they encountered disturbances by stakeholders, yet, no team had developed a strategy how to protect themselves successfully from such disturbance when the Scrum Master was absent.

We came across one approach by a team aiming at protecting themselves but did not succeed long-term:

Not everyone could participate, because actually we also have to do the fire fighting thing. We have a Batman for this. One of us would take over the role while the others were working. For example, someone for Monday, for Tuesday and so on. We rotate with this. [...] now we do not answer any call when we are not batman. So the team was shielded and we could actually learn in little steps. So in terms of learning, people gradually became to learn. Even though the technology felt new to most of us. (Dev)

In particular, teams without a regular support by a Scrum Master struggled to work in an agile manner. One team reported that it had occurred twice that management removed members temporarily while the Product Owner was absent. Likewise, a Product Owner of another team revealed that he struggled with not disturbing operational work and tended to give orders. Both Product Owners wished that there was a Scrum Master on a regular basis to defend the team.

While the Disciplinizer on Equal Terms strengthens focus in teams, the Protector shelters the team from the organization.

We explored which role the Scrum Master plays (RQ1) and in which way team members play that role over time (RQ2). While Scrum Masters were found to perform nine diverse leadership roles in rather immature teams, more mature teams played some of the roles themselves. Besides, we discovered that some roles were more applicable to be performed by mature teams than others. In the following, we will portray how roles were transferred from the Scrum Master to the team.

4.2 The Role Transfer Process

Our goal was to examine how the Scrum Master transferred leadership roles to team members (RQ3) and discovered that the role transfer occurs during three consecutive steps we labelled the role transfer process (shown in Figs.  1 and  2 ). In the following we elaborate on the three steps:

The three steps of the role transfer process

Factors describing the Internal Team Environment

The first step illustrates that the Scrum Master serves as a role model by demonstrating the activities of the nine leadership roles while team members observe the behavior to learn it. The Scrum Master empowers the team in understanding the value and utility of the roles, e.g. during the retrospective.

I try to help colleagues to find their way into the roles. It is always tricky to keep the balance between what the team should do by themselves and what should be done by the PO or SM. That is one thing that one has to reflect upon and to level out. (AM)

They build a shared understanding of the roles and its meaning for the agile manner and agree to aim at distributing the leadership roles among team members.

The second step describes that the Scrum Master provides a leadership gap when the team is considered to be more mature.

As a Scrum Master I can provide strong support at the beginning to get started. But then I have to retreat gradually so that the team gets into the mode of self-organisation. Because if you do not create some free space or a vacuum, nobody will jump in. (AM)

This quote reveals that the Scrum Master plays particular roles to a lesser extend while keeping management and Product Owners from undertaking the respective role. The emerging leadership gap provides the space for team members to perform the roles themselves.

While a team member claims to play the role the colleagues grant that person to take on the leadership role and respect the new role keeper.

The most exciting thing is to bear the silence until someone says something and to wait until someone else gets active. [...] Also we have to give them some free space to experiment and try out themselves. (AM)

This quote exemplifies that a Scrum Master provided a leadership gap intentionally, such that developers could perform the Knowledge Enabler.

Scrum Masters claimed that they either prepared a leadership gap intentionally by withdrawing from particular roles while waiting that team members would take on the role, or they were not playing the role due to being absent which gave the team the chance to perform the role. Moreover, some teams experienced that management truly empowered them to take on responsibility, whereas others encountered that management, Scrum Masters or Product Owners clung to power and kept them from taking on leadership roles.

The third step contains that the Scrum Master only plays certain roles when necessary while team members perform most of the roles themselves.

It takes a lot of energy but is quite nice to experience when the team gradually walks by itself. At the same time, the time effort by the Scrum Master can be reduced. (AM)

Yet, we found that not every role can be passed on to the team equally, e.g. Moderator and Protector tended to remain with the committed Scrum Master. This indicates that the dedicated Scrum Master does not disappear in a mature team but is played to a lesser extent over time.

4.3 Internal Team Environment

Furthermore, we aimed at exploring the team enablers required for the role transfer to occur (RQ4). We found eight enablers shaping an internal team environment that stimulated team members to take on leadership roles.

Firstly, teams that communicated with each other on equal terms and seemed to refrain from hierarchical thinking appeared to share leadership roles more openly among team members and the Scrum Master. One developer described the hierarchical free space in the following way:

Even if people have different pay grades, you do not feel like this one is the one being above the other one because this one belongs to a higher salary group than the other one. Maybe also because of the occupation or because of the level of knowledge. No one makes someone else realize that there might be a difference between each other but rather it works well with each other. (Dev)

The Scrum Master was not considered to be a formal leader they had to please. Hierarchical free space allowed the leadership gap to occur and therefore, to claim and grant a leadership role.

Secondly, teams who communicated on equal terms had established psychological safety (Edmondson 1999 ; Moe et al. 2010 ) which made them feel safe taking over the risk of playing a leadership role without previous experience in it. The Scrum Master was found to provide safety by the Scrum process. The retrospective helped teams to build trust among each other and encouraged team members to talk openly about personal matters.

Additionally, as referred to in Section  4.2 team members had developed a shared mental model (Levesque et al. 2001 ) regarding the meaning and content of the roles often via transparency , e.g. during the retrospective. Furthermore, they had agreed that anyone in the team could claim and should grant performing the leadership roles.

Moreover, team orientation (Moe et al. 2010 ) was identified to be important for developers to understand how each role contributed to the shared team goal. It empowered teams to feel responsible for a particular topic and thus feel the urgency to play the respective leadership role. For example, one team struggled in iterative learning and they complained that they had no vision. They felt like the knowledge they were required to learn was useless, and they did not understand why they should learn continuously. As a consequence, the team members seldom took over the Knowledge Enabler role.

Furthermore, we found that team members who performed leadership roles increased their team potency which implies to believe in the team’s capability to be successful (Guzzo et al. 1993 ). Therefore, they felt motivated to continue playing leadership roles in the future. Yet, it seemed to be challenging to have the courage to get started playing the respective leadership role for the first time. One developer described it to be painful to take on a leadership role when facing the leadership gap initially.

Additionally, developers felt that self-monitoring (Moe et al. 2010 ) would empower them to take on leadership roles. Teams with low level of self-monitoring stated that they externalized the sense of responsibility to a formal leader.

If think, maybe if the Product Owner would not tell me everyday what I have to do, maybe I would be more intrinsically motivated to do my tasks, maybe I would chose my tasks voluntarily. But like this. . . I just deliver a status report to my Product Owner every day! (Dev)

Finally, team learning (Edmondson 1999 ) allows the team to continuously reflect upon the leadership roles, e.g. during the retrospective, and therefore, develop themselves further regarding playing the diverse roles.

Answering our third (RQ3) and fourth research questions (RQ4), we found that an internal team environment of communication on equal terms, psychological safety, transparency, shared mental models, team orientation, team potency, monitoring themselves and team learning enabled roles to be transferred from the Scrum Master to developers.

4.4 Retrospective

Some teams reported to struggle in developing the internal team environment needed for transferring the roles. Our fifth research question was therefore: How can the Scrum Master foster the internal team environment? (RQ5)

The interviews revealed that the retrospective supported agile teams to develop a supportive internal team environment. One interviewee explicitly said that the retrospective helped the team to continuously develop itself further, while others circumscribed its positive effect on the team atmosphere. In the following we will provide different examples of how the retrospective influenced the internal team environment.

The retrospective helped the team to develop shared mental models regarding working together as a team and on individual preferences, e.g. with regard to personality or working style. A shared understanding of differences between team members also stimulated team orientation.

Additionally, the retrospective led to transparent communication which is one prerequisite to talk openly about the roles.

Furthermore, the retrospective established psychological safety which is necessary to have the courage to take on the diverse roles.

Each time before the retrospective I tried to explain that the purpose was not about blaming someone but to discuss constructively with each other and to develop further. I want to create an atmosphere within which failures are allowed to happen. (AM)

The retrospective also helped team members in developing team potency . Development Teams learned that they themselves were responsible to change situations for the better. Consequently, team members became aware that they were responsible to take on the divers leadership roles.

Our first retrospective was quite bad. There was always an external view. Such as the manager does not do anything about it, or the team does not do this or that. Always focused on individuals. At some point we managed [...] to talk about things that we could influence and could change our-selves. Even though those are not big changes, it motivates me when I see, that I can change things and that I benefit from it. (AM)

Investigating how the Scrum Master fostered the internal team environment we found that the retrospective promoted different facets of the internal team environment. We therefore conclude that the Scrum Master empowers the team to develop a supportive team climate and consequently take on leadership roles by facilitating the retrospective.

4.5 Role Conflicts

So far, we have described that the Scrum Master tends to play nine different leadership roles which are handed over to the team via a leadership gap, a supportive internal team environment and the retrospective. Yet, despite a supportive internal team environment, still the leadership roles may not be transferred to the team. Interviewees often described rather bureaucratic demands on the Scrum Master that led to role conflicts and to a struggle in providing the leadership gap necessary for the role transfer. Comparing our findings with other studies we learned that also in other companies Scrum Masters tend to perform additional activities, such as project management (Noll et al. 2017 ), which contradict the nature of the agile way of working, and led to role conflicts (Noll et al. 2017 ; Stray and Sjøberg 2016 ).

Our sixth research question was therefore: Which expectations on the Scrum Master limit the changing leadership? (RQ6)

In the following we will refer to diverse expectations by the Development Team, managers and the Product Owner, as well as requirements due to the position of the Scrum Master in the organisational chart.

4.5.1 Development Team

Often team members expected the Scrum Master to behave in an agile way, e.g. allowing the team to monitor themselves while opening the leadership gap.

He is a person who gives freedom to the team member to select tasks that he or she would like to do and in case of problems the Scrum Master is the one who can support and enable the team member to really work on the topic. In another way the Scrum Master is a team member but if he directs the associate how to do things this would not be a right Scrum Master. (Dev)

Yet, some developers also expected the Scrum Master to take on typical project manager tasks, e.g. providing clear direction or taking over responsibility for team decisions. These behaviors are in contrast to maintaining a leadership gap within which the team takes on leadership roles.

For us it is very difficult to find the right role as a Scrum Master where he only follows the methodology, because from an organizational point of view we actually need a project manager as a developer who tells us what to do and our Scrum Master already takes over this role. If he didn’t know what was going on then it would be difficult because then we would have to manage ourselves completely and our organization would not allow that. (Dev)

Therefore, even though the Scrum Master would provide the leadership gap, developers would not take the opportunity to take on leadership roles.

4.5.2 Managers

Managers involved the disciplinary supervisor of the Scrum Master or of the Development Team, internal customer and line managers. A few managers expected the Scrum Master improving teamwork. Yet, many managers rather demanded achieving defined hard facts, e.g. improved efficiency, and keeping to formal standards. Some managers had expectations regarding the Scrum process, formal standards and leadership behavior that were in contrast to opening the leadership gap.

It was easy for the project leaders, the group leaders and the department leaders to say ’from now on you do Scrum’. What it was really all about often did not matter to them at first. Since then, [...] they have gone through a long valley of tears while doing a mix of Scrum and of we don’t do it after all. The department heads still wanted to see their documents, still wanted to orientate themselves on the waterfall model. But overwrote it with ’Scrum’. Of course, this was a stupid hybrid for the project teams. (AM)

While the Development Team should take on leadership and is therefore responsible for work outcomes, manifold managers expected the Scrum Master or Product Owner to be mainly responsible for outcomes.

This topic reporting structure, this must change colossally. This internal reporting to the next level of the hierarchy, that must no longer be. We are using a relatively large number of resources in the Group for this. That’s why I believe that today’s management team must radically change. (PO)

Therefore, the Scrum Master was rather expected to follow the rules of the pre-existing bureaucratic organisational system instead of serving as a Coach for the agile approach. The Scrum Master was torn in between meeting traditional management requirements and embracing agile leadership behavior, such as providing a leadership gap.

4.5.3 Product Owner

Some Product Owners expected the Scrum Master to serve as a counterpart with whom they could have constructive conflicts. Yet, some Product Owners were found to put high pressure on the Scrum Master or directly on the Development Team. This led to the Scrum Master also putting more pressure on the team instead of opening the leadership gap. Furthermore, it diminished the willingness of the Development Team to take on leadership roles.

That [the Product Owner position] is not really a nice position to be in in such an organization. Because you have a team that has the pull and you are under a lot of pressure, you have the push and you have to bear it, this balancing act where you say, ok, I’m letting go of the reins for two weeks and I’m under incredible pressure. And I’m put under pressure every day. It’s incredibly difficult. (PO)

4.5.4 Scrum Master Position in Organisational Chart

Furthermore, some Scrum Masters said that the way their role was formally embedded in the organisational chart led to role conflicts and diminished the options to open the leadership gap. For example, some interviewees described that they hold distinct formal roles within one team that embodied contradicting interests.

I am part of the team myself. I still perform my tasks in the team, in the part of the project where my responsibilities still lie. This is sometimes a difficult point, because you can’t discuss the work packages from the outside in a really neutral way as a Scrum Master, but you also have a certain amount of action and interest in who does what and when. (AM)

One interviewee was simultaneously Scrum Master and disciplinary supervisor. While the role of a Scrum Master was rather expected to provide a leadership gap in which the team took on leadership roles, the disciplinary supervisor was rather considered to make decisions him- or herself.

For me, I would say the tasks differ a little bit. On the one hand, as I said, I would rather see myself as a team coach and as part of the team, because that promotes the cause. On the other hand, [...] I also have other tasks. I have to do that from time to time, although we try to make a decision and see how we get it done. (AM)

Furthermore, some Scrum Masters lack in positional power to protect the leadership gap.

I mean when I say there is nothing it is a volunteering thing if you say ’No, I don’t want these people working there’. I just do not know the consequences. I do not know if they have the authority to say no. ’No, I am not giving anyone of my people to you’, I don’t know the consequences. You do it in good faith and release people to the task force. (Dev)

We uncovered how demands by the Development Team, managers and the Product Owner limited the role transfer. The Scrum Master was often expected to meet requirements deriving from a rather bureaucratic view on ’leading a project team’, e.g. reporting, monitoring and decision-making. This contradicts the nature of the agile way of working which implies that the Development Team takes on leadership roles. The contradiction led to role conflicts between meeting the needs of the existing bureaucratic system and the new agile approach. Fulfilling the rather traditional requirements restricted opening the leadership gap, thus, limited the changing Scrum Master.

5 Discussion and Relation to Existing Evidence

5.1 summary of the research findings.

There is a steadily increasing number of attempts to implement agile teams in industrial setting. Simultaneously, a growing body of papers point at challenges such teams face (e.g. (Moe et al. 2012 ; Nerur et al. 2005 )). Scarce empirical research explores how teams can actually learn to work in an agile manner. Our research objective was to explore how leadership empowers a team to work in an agile way in real organizational settings with a particular focus on the changing Scrum Master.

Empirical studies have suggested that leadership evolves while the team matures (Moe et al. 2010 ; Gren et al. 2017 ; Srivastava and Jain 2017 ). Some authors state that team members in a more mature team also take on leadership roles (Moe et al. 2010 ; Srivastava and Jain 2017 ). Up to our knowledge, no scientific research project has examined how leadership changes in an agile team over time. We explored how the Scrum Master enables the developers to take on leadership and to adapt the agile way of working.

We reported on the results of a grounded theory study. Based on observations and semi-structured interviews with 53 Scrum practitioners from 11 different business divisions of the Robert Bosch GmbH we answered research questions RQ1 to RQ7.

In the following we summarize our research findings by referring to the respective research questions in consecutive order.

How does the Scrum Master perform leadership in an agile team? (RQ1)

We identified that the Scrum Master plays 9 leadership roles. Each role aims at fostering agile team features. Moreover, the goal of one dedicated Scrum Master is to empower the developers to perform the nine leadership roles themselves.

In which way do team members take on leadership overtime? (RQ2)

The semi-structured interviews with Development Teams, Scrum Masters and Product Owners provided examples for the team taking over 7 of the 9 leadership roles over time: the Method Champion, Disciplinizer on Equal Terms, Coach, Change Agent, Helicopter, Networker and Knowledge Enabler. We did not come across examples in which the team played the Protector and the Moderator.

How is leadership transferred from the Scrum Master to the Development Team? (RQ3)

Leadership is transferred in three consecutive steps which we name the role transfer process . Firstly, the Scrum Master is a role model and demonstrates nine leadership roles while the team is observing the behavior. Secondly, the Scrum Master provides a leadership gap, namely a hierarchical-free space within which neither the dedicated Scrum Master, managers, the Product Owner nor any other formal leader role interferes. This allows the developers to take on leadership. Team members claim and grant leadership roles depending on the situation. In the last step, the Scrum Master only plays the leadership roles when still needed, while the team performs most of the nine roles.

What is the underlying internal team environment required for the transfer of leadership? (RQ4)

The role transfer requires an internal team environment of communication on equal terms, psychological safety, transparency, shared mental models, team orientation, team potency, self monitoring and team learning. These team features help the team to understand the leadership roles and agree upon sharing the roles.

How can the Scrum Master foster the internal team environment? (RQ5)

By facilitating the retrospective the Scrum Master helps developers to grow a supportive internal team environment. The retrospective contributes to building a shared understanding on leadership in agile teams and empowers to take action.

Which expectations on the Scrum Master limit the changing leadership? (RQ6)

The Scrum Master is torn between fulfilling expectations deriving from a bureaucratic way of thinking and the agile way of thinking which led to role conflicts. For example, sometimes managers expect the Scrum Master to do monitoring aiming at control of work progress, even though the agile way of working describes that the Development Team monitors itself aiming at transparency. As a consequence of the role conflicts, the Scrum Master is torn between clinging to the leadership roles and handing them over to developers. If the Scrum Master decides to fulfill expectations deriving from a bureaucratic system, the role transfer is diminished.

5.2 Nine Leadership Roles

Following grounded theory, we did a minor up-front literature search before collecting and analysing data. While developing our grounded theory grounded in the gathered data, we compared it to current research on agile software development teams. In the following, we elaborate on the similarities of and differences between our findings and existing research on agile teams.

Our interviews revealed that a Scrum Master plays multiple leadership roles which are transferred to the team while it matures. Consequently, roles are shared between the Scrum Master and a mature Development Team. Our suggestion that developers can learn to take on parts of the Scrum Master is in line with the findings of other researchers (Bäcklander 2019 ; Moe et al. 2010 ; Srivastava and Jain 2017 ).

Our data analysis uncovered the following nine leadership roles:

Method Champion: makes sure that the method fits the specific team context. Brings new methods to the team and discusses how to adapt the method to the team context.

Disciplinizer on Equal Terms: ensures that the team focuses on relevant topics. Discipline is accomplished via communication on a par.

Coach: Observes colleagues and uncovers which kind of behaviour is missing in the team to improve teamwork, provides feedback, and helps others to find out what they wish to change and how to do so.

Change Agent: Serves as a role model, and thereby convinces newly established project teams of the agile way of working.

Helicopter: Has the ability to see the bigger picture and knows who possesses the right skill for a certain task.

Moderator: Moderates all kind of meetings and builds a bridge between perspectives and domains.

Knowledge Enabler: Teaches the team a new approach to learning and promotes iterative learning.

Networker: Connects the team with relevant stakeholders from within and outside the organisation.

Protector: Shelters teams from inappropriate requests from the Product Owner, managers, disciplinary leaders and other departments.

A similar grounded theory study by Hoda et al. ( 2013 ) discovers six different self-organizing roles (Mentor, Coordinator, Translator, Champion, Promoter, and Terminator). Up to our knowledge, the research by Hoda et al. ( 2012 ) is the only scientific study related to human behavior in agile software development exploring descriptive roles in self-organizing agile teams. Therefore, we compare our findings on leadership roles in agile teams with the findings on self-organizing roles in agile teams. Even though our interviews focused on leadership of the Scrum Master, we discovered similarities to self-organizing roles in agile teams (Hoda et al. 2012 ).

When starting our research, we had not been familiar with the self-organizing roles. The research by Hoda et al. ( 2012 ) refers to a job description of an Agile Coach who plays most of the self-organizing roles in an immature team, but shared the roles in a more mature team. Similarly, we found that the Scrum Master played most of the nine leadership roles in a rather newly established team. Yet, even though the content of the roles overlap they slightly differentiate.

Comparing our findings on leadership roles with the work by Hoda et al. ( 2012 ) on self-organizing roles, the role descriptions of the Champion, Mentor and Translator clearly overlap with our Change Agent, Method Champion, Networker and Moderator. Yet, the Change Agent does not only convince management of the agile way of working (like the Champion) but also persuades team members of the agile manner. The Networker connects the team with management (like the Champion). Moreover, the Networker also builds a bridge between the developers and experts externally to the team. The Method Champion does not only refer to the implementation of an agile method (like the Mentor), but also consults the team upon which method (e.g. Scrum, XP, Kanban) to use in a given context, and how to adapt the Scrum method to a specific context.

Translator is similar to Moderator. While the Translator refers to translating between the business context of the customer and the technical context of the developers, the Moderator focuses on mediating between team members and is more comprehensive. The Moderator does not only translate between different domain languages, but also between working habits or cognition.

Coordinator and Translator (Hoda 2011 ) involve customer representation. We have not identified roles that relate to the customer. In Scrum the Product Owner is responsible for the customer integration. Probably we did not identify a role related to the customer integration, because our study focused on the leadership role of a Scrum Master.

Moreover, we found additional roles, such as the Coach, which is not described by Hoda et al. ( 2012 ), but by the study of Bäcklander ( 2019 ). The Coach observes team behavior, actively listens to the team’s concern and helps the team to get along well with each other, to talk openly about developing conflicts and to deliver feedback to each other. While Bäcklander ( 2019 ) examines an individual leader within the team and leaves it open whether or not team members can take on leadership, we found that also several team members performed the Coach.

Hoda et al. ( 2012 ) describe that mature teams tend to share the self-organizing roles more broadly within the team than immature teams. While immature teams rather stick to formal role keepers, the roles can be transferred to other team members with the fitting skill set in more mature teams. While Hoda et al. ( 2012 ) suggest that the self-organizing roles can be performed by any team member in a mature team and Bäcklander ( 2019 ) even speculates if the Scrum Master can be replaced by team members, we do not believe that all leadership roles can be shared equally among the Development Team and the Scrum Master, but instead claim that the Scrum Master keeps the Protector and the Moderator role in a mature team.

Therefore, we suggest that some roles should always be played by the Scrum Master, which builds upon the findings by Hoda et al. ( 2013 ) who discovered that in the absence of specific formal role keepers some aspects of agile working lost the team’s attention, such as the retrospective. In line with Gren et al. ( 2019 ) we found the retrospective to be an important enabler for continuously fostering an internal team climate that stimulates the role transfer.

Grounded theory is always embedded in the context under research (Glaser and Strauss 2017 ). We speculate that we have identified these particular nine leadership roles in our research context, because they are typical for bureaucratic companies that are in the middle of their agile transformation. Traditional development companies are build upon departmentalized silos as opposed to cross-functional teams (Nerur et al. 2005 ), upon top-down hierarchy as opposed to self-organization (Moe et al. 2012 ), and rigid planning as opposed to iterative learning (Boehm and Turner 2005 ).

The Protector may protect the team from a rather hierarchical organizational context. The Method Champion supports teams that are used to the waterfall model, to learn new methods for building products in incremental steps. The Helicopter, Knowledge Enabler, Moderator and Networker support the developers in breaking departmental silos to work in cross-functional teams.

We are convinced that in a rather traditional development company a Scrum Master will not become obsolete in a mature team, but is continuously needed to empower a team to work in an agile way. Therefore, the implications of our research are applicable to rather traditional development companies.

5.3 Role Transfer Process

We refer to maturity and suggest that the Scrum Master is located within one dedicated leader in an immature team, but shared between one individual and several team members in a more mature team. Consequently, we suggest that leadership is a fluid concept that evolves over time while the team matures. Yet, similar as the research by Gren and Lindman ( 2020 ) we suggest that teams will only take on leadership roles if they are embedded in a supportive organizational environment. Thus, we take the context within which leadership emerges into account.

Our role transfer process reflects several elements of the forming-storming-norming-performing model by Tuckman ( 1965 ). The forming phase by Tuckman ( 1965 ) suggests that team members focus on a leader who sets ground rules for further cooperation. Team members are insecure how to behave and search for opportunities to observe expected behavior. It is therefore decisive for a Scrum Master to demonstrate the agile leadership roles from the beginning onward and to agree with the team that they aim towards sharing those roles.

While some interviewees described that the Scrum Master provided a leadership gap others had experienced that the Scrum Master, the Product Owner or the managers struggled with transferring leadership roles to the developers. This is also described by role conflicts during the storming phase by Tuckman ( 1965 ).

Over time agile teams establish a shared understanding of roles and responsibilities which is expressed by the norming phase by Tuckman. Developers who are used to a rather traditional way of working become to understand how to work in an agile manner. They start to claim and grant leadership roles: developers learn to play parts of the Scrum Master themselves while being allowed to do so by other developers, the Scrum Master, the Product Owner and the managers.

The performing stage allows individuals to take on roles whenever it makes sense. Yet, it is important to emphasize that we have not come across many teams during our research in which leadership roles were truly shared among the Scrum Master and the team members. We have two possible explanations for this finding: firstly, previous research from the literature stream on self-managed teams finds that leadership roles vary according to the development stage of a team, and suggests that roles of monitoring and coordinating may be replaced by team norms after a while (Yang 1996 ). Similarly, we suggest that certain roles may turn into team values in a more mature team. The Disciplinizer on Equal Terms may turn into the team values of focus and working on a par. Secondly, earlier empirical observations reveal that the performing phase is seldom reached in organizational context (Marks et al. 2001 ).

We suggest that a contradiction between expectations deriving from a rather bureaucratic organisation and from the agile way of working is one of the reasons why truly agile teams are rare in company settings. As found in previous studies (Stray and Sjøberg 2016 ; Noll et al. 2017 ) we identified role conflicts. The Scrum Master was torn between meeting demands of rather bureaucratic organisations and of the agile way of working. Those conflicts limited the role transfer from the Scrum Master to the team. Therefore, to enable the team to take on leadership roles, the organisation should adapt its processes and requirements to the agile approach. An alternative option would be to add project management activities officially to the Scrum Master.

No matter which choice an organisation makes, it is important for organisations to have a common understanding regarding leadership in agile teams and to communicate clearly what is expected in the specific company setting. Otherwise teams may have wrong expectations of the agile way of working which results in frustration.

5.4 Leadership Gap

Command-and-control behavior by Scrum Masters, Product Owners or management was found to weaken self-organisation of teams (Moe et al. 2010 ; Hoda 2011 ). Bäcklander ( 2019 ) advices Scrum Masters to be absent from time to time to improve teamwork, which was already found to increase information sharing among team members in earlier studies (Moe et al. 2010 ). We believe that our finding of displaying a leadership gap that permits teams to play leadership roles fits well with those previous empirical findings.

We found that a Scrum Master provides a leadership gap . The leadership gap generates hierarchical free space in which developers take on leadership depending on the situation. The Scrum Master may create it on purpose, e.g. by stepping back, or unintentionally, e.g. by being absent. This leadership gap may be rather small at the beginning, gradually allowing the team to step in. In a more mature team, the leadership gap may be larger. The Scrum Master continuously needs to find a balance between performing the nine leadership roles, and letting the team take on the roles. To determine a suitable size of the leadership gap, the dedicated leader may consider the willingness and capability of a Development Team to take on the leadership roles.

6 Practical Implications

In the previous sections we have elaborated on our research model and our empirical findings on the changing Scrum Master. We now suggest ideas on how practitioners can apply the knowledge in company context.

Many practitioners on the management level have set the agile transformation of their organisations as one of their top priorities. One way to reach this goal is implementing the method Scrum. Often managers believe that when implementing the Scrum framework, developers will do “twice the work in half the time” (Sutherland and Sutherland 2014 ). The Scrum Guide describes an ideality missing a link to team mechanisms such as maturity and a detailed description of how to comfort project teams on their journey to become an agile team. Thus, few have recognized and welcomed the time required for the team development process.

Furthermore, even though management expects employees to change and take on more responsibility, some managers are reluctant to grant leadership roles to the teams. Due to the tayloristic past being deeply imprinted in parts of the organisational memory, traditional viewpoints on hierarchy tend to remain and it is therefore easy to hold on to traditional sources of power.

When implementing agile teams in rather traditional development companies, often organisations develop hybrid models: they try new approaches of collaboration while keeping to traditional processes and sources of power, e.g. in terms of reporting, resource allocation or decision making. This leads to even more complexity and higher efforts for alignment and communication. For example, agile teams may have an external review and an internal status report to the team separately. This does not only take more time but may also result in controversial decision-making processes. Even though managers expect developers to take on leadership roles, they still cling to traditional decision-making rituals. This leads to de-motivation of Development Teams since they were promised more leadership responsibility when launching agile methods.

We therefore suggest to critically examine the existing structure and processes and agree upon decision-making responsibilities while including the agile team. This will build a shared understanding on leadership. Moreover, we propose to avoid introducing even more formal meetings when implementing Scrum teams but instead trust agile teams to take on leadership roles in a more informal way. This will lead to improved team maturity, and therefore to high performing teams.

To empower developers to take on leadership, not only the team environment influences the agile way of working but also the organisational environment. For example, external pressure, top-down changed targets and shifted priorities as well as frequent changes of the team setup destroy the sheltered space within which agile teams can grow. Therefore, organisational culture and structure have to change since this strongly influences expectations and scope of actions of the roles. We suggest that managers try even harder to change their mind-set towards more agility and provide the appropriate boundary condition for the agile way of working.

Managers should provide opportunities for agile teams to be actively part of the needed structural change towards a more agile organisation. For example, managers should allow the team to design their own working conditions freely within set boundaries in terms of time or budget. Furthermore, we urge managers to provide even more transparency and opportunities to voice the opinion by a regular Backlog Grooming and implementing openly accessible activity boards. Including Development Teams in strategic decisions will lead to even more motivation and commitment to take on leadership roles.

Product Owner

The Product Owner is an important mediator between the customer and the agile team. The Product Owner is supposed to point at the overall direction, as agreed to with the customer, while also protecting the team from organisational pressure. When developers truly feel the freedom to take on leadership roles, they will be able to tackle complex challenges as a team. In an agile environment every team member brings skills, expertise, wisdom and knowledge openly to the table. Everyone suggests own ideas and challenges the status quo, such that innovative and complex products can be build together.

However, the Product Owner was found to be torn in between delivery pressure and providing freedom to the agile team. Some Scrum Masters were limited in their scope of action due to the Product Owner putting pressure on them. Therefore, the agile teams seldom performed the leadership roles.

We found that in rather traditional development organisations it is rather difficult for the Product Owner to bridge the expectations by the management with the expectations and needs of the Scrum Master and the Development Team.

We therefore suggest measurements to diminish the organisational pressure. For example, core circles of representatives of the different agile teams could meet regularly and increase alignment between teams to ensure most effective usage of budget and resources. Also, the Product Owner should believe even more in the power of providing freedom to the Development Team instead of asking for regular status reports. Hence, Product Owners must seek to minimize top-down or external influence to a Development Team during defined sprints to foster the process of taking over responsibility for decisions and committed work products by the team.

Development Team

When individuals from rather traditional development companies start working in agile teams they have to learn a new way of leadership in teams, which will lead to slower delivery of work products at the beginning. Team members must get familiar with interacting with their team and managers in a different way, and to develop the courage to bridge the leadership gap when provided. Developers need time to try out the roles and learn them, possibly by failure. Just like any newbie in a formal leadership position needs time and is given time to learn being a leader, Development Teams need time to learn the leadership roles of Scrum.

Furthermore, the Development Team should occasionally invite stakeholders and managers to the retrospective. This allows them to build a shared understanding of working together, a shared leadership culture and ultimately necessary trust in their abilities and shared responsibilities.

We also found that not aligning responsibilities at all leads to insecurity about roles and responsibilities. Worst case, no one in the team will take on the respective leadership roles which may lead to a leadership vacuum within which no one takes on responsibility. Therefore, we urge practitioners to talk openly about roles and responsibilities and to agree on having specified owners for some topics and on having shared ownership for other topics.

Scrum Master

The Scrum Master has to be granted sufficient legitimacy to shelter the team while it matures and to preserve the leadership gap as a major enabler for the team’s transformation. The Scrum Master must encourage the team to take the time to regularly reflect upon the leadership roles during the retrospective, learn their meaning and content, build a mutual understanding and figure out how and to what extent to take on leadership roles. Simultaneously, the Scrum Master must be patient and wait until developers take on responsibility when they face a lack of leadership.

The Scrum Master steps back and may be needed less over time, and can start focusing on other issues. Either a Scrum Master could become responsible for other Development Teams since the respective team requires less time or the Scrum Master could become an organizational coach and focus even more on solving organizational impediments and aligning diverse agile teams. For example, the Scrum Master could increase coaching service for management and Product Owner. Also the Scrum Master could take even more care of linking the Development Team with relevant stakeholders.

7 Limitations and Future Work

In the following we will critically reflect upon the research limitations and suggest topics for follow-up studies.

Grounded theory does neither claim to test hypotheses nor to be universally applicable but to build new theory grounded in the specific context under research (Glaser and Strauss 2017 ). The grounded theory explains only the specific context, because the theory emerged while analysing the data from that particular context (Adolph et al. 2008 ). More specifically, the theory explains the behavior of the people in that particular organisation under study (Adolph et al. 2008 ). Therefore, our results cannot be generalized.

Constructivist grounded theory assumes that the researchers’ perspectives and interaction with the practitioners influences the way data is interpreted (Charmaz 2016 ). The aim of the research is to get as close to the practitioner’s reality as possible. Thereby, providing insights into the motives, believes and intended action of research participants (Charmaz 2016 ). Therefore, subjectivity cannot be completely eliminated from data analysis and data collection (Charmaz 2016 ).

Despite these features of grounded theory, the following measures aimed to increase the quality of our study:

To increase construct validity , we draw data from different organizations from one conglomerate and used multiple sources of evidence by capturing the Scrum Master from three different angles involving Scrum Masters, Product Owners and developers. The researchers discussed the extracted results and built concepts and theories. Additionally, emerging results were frequently reflected critically with various agile practitioners from the company and the main author observed multiple agile teams at the company site over a period of 1.5 years. The final results were supported by the observations and discussions with practitioners.

All participants work at the same conglomerate, mostly in the automotive industry. To increase external validity , we aimed at approaching an equal number of project teams at each division. Despite their slightly similar overall working culture, the 11 business divisions embrace different subcultures. Yet, we do not claim our results to be universally applicable and acknowledge that they might be limited to the specific context. Further studies should compare our findings on the changing leadership with data drawn from other companies. For example, researchers could examine if the Protector and Disciplinizer on Equal Terms can also be found in more mature agile companies or if they are rather linked to traditional development companies.

Reliability

An open-ended semi-structured questionnaire guided the interviews and therefore, each interview followed a similar structure. Yet, we asked participants about past activities based on memory. Since memories of individuals tend to change retrospectively our interviews are difficult to replicate. Furthermore, a grounded theory study cannot proof hypotheses. In order to examine whether a larger majority of Scrum Masters and Development Teams play the nine leadership roles we have identified, a quantitative follow-up study is needed to increase reliability of our study.

Adolph S, Hall W, Kruchten P (2008) A methodological leg to stand on: lessons learned using grounded theory to study software development. In: Proceedings of the 2008 conference of the center for advanced studies on collaborative research: meeting of minds, pp 166–178

Bäcklander G (2019) Doing complexity leadership theory: How agile coaches at spotify practise enabling leadership. Creat Innov Manag 28(1):42–60

Article   Google Scholar  

Bales RF, Strodtbeck FL (1951) Phases in group problem-solving. J. Abnorm. Soc. Psychol. 46(4):485

Boehm B, Turner R (2005) Management challenges to implementing agile processes in traditional development organizations. IEEE Softw 22(5):30–39

Bryant A, Charmaz K (2007) Grounded theory. SAGE Publications Ltd, London

Google Scholar  

Carson JB, Tesluk PE, Marrone JA (2007) Shared leadership in teams: An investigation of antecedent conditions and performance. Acad Manag J 50 (5):1217–1234

Charmaz K (2016) Shifting the grounds: Constructivist grounded theory methods for the 21st century. In: Morse J M, Stern P N, Corbin J, Bowers B, Charmaz K, Clarke A E (eds) Developing grounded theory: The second generation, vol 3. Routledge, pp 127–193

Cockburn A (2002) Agile software development, vol 177. Addison-Wesley, Boston

Cockburn A, Highsmith J (2001) Agile software development, the people factor. Computer 34(11):131–133

Conboy K (2009) Agility from first principles: Reconstructing the concept of agility in information systems development. Inf Syst Res 20(3):329–354

Edmondson A (1999) Psychological safety and learning behavior in work teams. Adm. Sci. Q. 44(2):350–383

Fiedler FE (1967) A theory of leadership effectiveness. McGraw-Hill, New York

Gersick CJ (1989) Marking time: Predictable transitions in task groups. Acad Manage J 32(2):274–309

Ginnett RC (2019) Crews as groups: Their formation and their leadership. In: Crew resource management. Elsevier, pp 73–102

Glaser BG, Strauss AL (2017) Discovery of grounded theory: Strategies for qualitative research. Routledge

Gren L, Lindman M (2020) What an agile leader does: The group dynamics perspective. In: International conference on agile software development. Springer, pp 178–194

Gren L, Torkar R, Feldt R (2017) Group development and group maturity when building agile teams: A qualitative and quantitative investigation at eight large companies. J Syst Softw 124:104–119

Gren L, Goldman A, Jacobsson C (2019) Agile ways of working: A team maturity perspective. Journal of Software: Evolution and Process

Guzzo RA, Yost PR, Campbell RJ, Shea GP (1993) Potency in groups: Articulating a construct. British J Soc Psycho 32(1):87–106

Hersey P, Blanchard KH, Johnson DE (2007) Management of organizational behavior. Prentice Hall, Upper Saddle River

Hoda R (2011) Self-organizing agile teams: A grounded theory, PhD thesis, Victoria University of Wellington

Hoda R, Noble J, Marshall S (2012) Developing a grounded theory to explain the practices of self-organizing agile teams. Empir Softw Eng 17(6):609–639

Hoda R, Noble J, Marshall S (2013) Self-organizing roles on agile software development teams. IEEE Trans Softw Eng 39(3):422–444

Kozlowski SWJ, Watola DJ, Jensen JM, Kim BH, Botero IC (2009) Developing adaptive teams: A theory of dynamic team leadership. In: Team effectiveness in complex organizations: Cross-disciplinary perspectives and approaches, pp 113–155

Levesque LL, Wilson JM, Wholey DR (2001) Cognitive divergence and shared mental models in software development project teams. J Organ Behav 22 (2):135–144

Magpili NC, Pazos P (2018) Self-managing team performance: A systematic review of multilevel input factors. Small Group Res 49(1):3–33

Manz CC, Sims HP Jr (1987) Leading workers to lead themselves: The external leadership of self-managing work teams. Administrative science quarterly 106–129

Marks MA, Mathieu JE, Zaccaro SJ (2001) A temporally based framework and taxonomy of team processes. Acad Manag Rev 26(3):356–376

Moe NB, Dingsøyr T, Dybå T (2009) Overcoming barriers to self-management in software teams. IEEE Software 26(6):20–26

Moe NB, Dingsøyr T, Dybå T (2010) A teamwork model for understanding an agile team: A case study of a scrum project. Inform Softw Technol 52 (5):480–491

Moe NB, Aurum A, Dybå T (2012) Challenges of shared decision-making: A multiple case study of agile software development. Inform Softw Technol 54(8):853–865

Nerur S, Mahapatra RK, Mangalaraj G (2005) Challenges of migrating to agile methodologies. Commun ACM 48(5):72–78

Neuman GA, Wright J (1999) Team effectiveness: beyond skills and cognitive ability. J Appl Psychol 84(3):376

Noll J, Razzak MA, Bass JM, Beecham S (2017) A study of the scrum master’s role. In: International conference on product-focused software process improvement. Springer, pp 307–323

Parizi RM, Gandomani TJ, Nafchi MZ (2014) Hidden facilitators of agile transition: Agile coaches and agile champions. In: 8th. Malaysian software engineering conference (MySEC). IEEE, pp 246–250

Schwaber K (1997) Scrum development process. In: Business object design and implementation. Springer, pp 117–134

Spiegler SV, Heineck C, Wagner S (2018) Interview Guidelines for “Leadership Gap in Agile Teams: How Teams and Scrum Masters Mature”. https://doi.org/10.5281/zenodo.2243113

Spiegler SV, Heinecke C, Wagner S (2019) Leadership gap in agile teams: How teams and scrum masters mature. In: International conference on agile software development. Springer, pp 37–52

Srivastava P, Jain S (2017) A leadership framework for distributed self-organized scrum teams. Team Perform Manag: An Int J 23(5/6):293–314

Stavru S (2014) A critical examination of recent industrial surveys on agile method usage. J Syst Softw 94:87–97

Stray V, Sjøberg DI (2016) The daily stand-up meeting: A grounded theory study. J Syst Softw 114:101–124

Stray VG, Moe NB, Dingsøyr T (2011) Challenges to teamwork: a multiple case study of two agile teams. In: International conference on agile software development. Springer, pp 146–161

Sutherland J, Schwaber K (2017) The Scrum guide: The definitive guide to Scrum: The rules of the game. http://scrumguides.org/

Sutherland J, Sutherland J (2014) Scrum: the art of doing twice the work in half the time. Currency

Takeuchi H, Nonaka I (1986) The new new product development game. Harvard Business Rev 64(1):137–146

Trist EL, Bamforth KW (1951) Some social and psychological consequences of the longwall method of coal-getting: an examination of the psychological situation and defences of a work group in relation to the social structure and technological content of the work system. Human Relations 4(1):3–38

Tuckman BW (1965) Developmental sequence in small groups. Psychol Bull 63(6):384

Wageman R (1997) Critical success factors for creating superb self-managing teams. Organ Dynam 26(1):49–61

Yang O (1996) Shared leadership in self-managed teams: A competing values approach. Total Qual Manag 7(5):521–534

Download references

Acknowledgements

Our sincere gratitude to all those who participated in this research.

This document is the result of the research project funded by the Robert Bosch Automotive Steering GmbH.

Open Access funding enabled and organized by Projekt DEAL. This project is part of a larger PhD project on the Scrum Master role by Simone V. Spiegler and is funded by the Robert Bosch Automotive Steering GmbH.

Author information

Authors and affiliations.

Institute of Software Engineering, University of Stuttgart, Stuttgart, Germany

Simone V. Spiegler & Stefan Wagner

Robert Bosch Automotive Steering GmbH, Schwäbisch Gmünd, Germany

Simone V. Spiegler

Robert Bosch GmbH, Stuttgart, Germany

Christoph Heinecke

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Simone V. Spiegler .

Ethics declarations

Conflict of interests.

Simone V. Spiegler is an industrial PhD student and has received a research grant by the Robert Bosch Automotive Steering GmbH. Christoph Heinecke is an employee at the Robert Bosch GmbH.

Additional information

Communicated by: Kelly Blincoe

Availability of Data and Material

Publisher’s note.

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Rights and permissions

Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/ .

Reprints and permissions

About this article

Spiegler, S.V., Heinecke, C. & Wagner, S. An empirical study on changing leadership in agile teams. Empir Software Eng 26 , 41 (2021). https://doi.org/10.1007/s10664-021-09949-5

Download citation

Accepted : 04 February 2021

Published : 22 March 2021

DOI : https://doi.org/10.1007/s10664-021-09949-5

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Agile working
• Development team
• Scrum master
• Find a journal
• Publish with us
• Track your research

• You are here:
• Agile Business Consortium
• Knowledge Base

Case Studies

Read our latest case studies of how people have used business agility within their organisations.

Agile Business Conference 2024

The Awards Conference took place as a global and virtual event in April 2024.  The awards offered the opportunity for organisations to be recognised for innovation and achievement relating to agile ways of working.

Panel Discussion on Agility in Marketing

Presentation from the Agile Business Conference 2024

Allianz Türkiye: Agile@scale: unleashing hyper-productive teams in the organisation

DEWA: DEWA's Journey Towards Excellence, Sustainability, and Innovation

All case studies.

TBC Bank: How to win the Agile Transformation Game in a Sustainable Way

Sunlife India: We are Next generation Procurement

Bumrungrad International Hospital: Agility that transforms World-Class Healthcare Business

Panel Discussion on Agility in Finance, Procurement & Contracts

Panel Discussion on Business Agility

Vodafone UK Digital: A Blooming Success! Cultivating Vodafone's Agile Garden

Evaro - Sprinting Towards Success (Evaro's journey to adopting Agile Methodology)

Liberty Specialty Markets - Running at the speed of change? Let’s talk coaching

Coca-Cola Europacific Partners: Breaking barriers with an agile reset

Other resources .

White Papers

Discover the latest research in business agility with our large selection of white papers.

Find out more

Watch our latest webinars and events focusing on business agility.

Business Agility Toolkit

A suite of tools designed to support individuals, teams, and organisations on their agile journey.

Read online our collection of business agility handbooks and pocketbooks.

Read about recent events, community news and the latest agile trends.

To use in your business agility projects.

Bitesize Guides

An introduction to key business agility practices.

Discover the Spotify model

What the most popular music technology company can teach us about scaling agile

Spotify is the largest and most popular audio streaming subscription service in the world, with an estimated 286 million users. A key part of Spotify's success is driven by the company’s unique approach to organizing around work to enhance team agility. As Spotify’s engineering teams traveled down the path towards improved agility, they documented their experience, shared it with the world, and ultimately influenced the way many technology companies organize around work. It is now known as the Spotify model.

What is the Spotify model?

The Spotify model is a people-driven, autonomous approach for scaling agile that emphasizes the importance of culture and network. It has helped Spotify and other organizations increase innovation and productivity by focusing on autonomy, communication, accountability, and quality.

The Spotify model isn’t a framework, as Spotify coach Henrik Kniberg noted , since it represents Spotify's view on scaling from both a technical and cultural perspective. It’s one example of organizing multiple teams in a product development organization and stresses the need for culture and networks.

…the Spotify model focuses on how we structure an organization to enable agility.

The Spotify model was first introduced to the world in 2012, when Henrik Kniberg and Anders Ivarsson published the whitepaper Scaling Agile @ Spotify , which introduced the radically simple way Spotify approached agility. Since then, the Spotify model generated a lot of buzz and became popular in the agile transformation space. Part of its appeal is that it focuses on organizing around work rather than following a specific set of practices. In traditional scaling frameworks, specific practices (e.g. daily standups) are how the framework is executed, whereas the Spotify model focuses on how businesses can structure an organization to enable agility.

The Spotify model champions team autonomy, so that each team (or Squad) selects their framework (e.g. Scrum , Kanban , Scrumban, etc.). Squads are organized into Tribes and Guilds to help keep people aligned and cross-pollinate knowledge.

Now, let’s demystify some of these terms…

Key elements of the Spotify model

The Spotify model is centered around simplicity. When Spotify began organizing around their work, they identified a handful of important elements on how people and teams should be structured.

Similar to a scrum team, Squads are cross-functional, autonomous teams (typically 6-12 individuals) that focus on one feature area. Each Squad has a unique mission that guides the work they do, an agile coach for support, and a product owner for guidance. Squads determine which agile methodology/framework will be used.

When multiple Squads coordinate within each other on the same feature area, they form a Tribe. Tribes help build alignment across Squads and typically consist of 40 - 150 people in order to maintain alignment (leveraging what we call Dunbar's Number ). Each Tribe has a Tribe Lead who is responsible for helping coordinate across Squads and for encouraging collaboration.

Even though Squads are autonomous, it’s important that specialists (e.g. Javascript Developer, DBAs) align on best practices. Chapters are the family that each specialist has, helping to keep engineering standards in place across a discipline. Chapters are typically led by a senior technology lead, who may also be the manager for the team members in that Chapter.

Team members who are passionate about a topic can form a Guild, which essentially is a community of interest. Anyone can join a Guild and they are completely voluntary. Whereas Chapters belong to a Tribe, Guilds can cross different Tribes. There is no formal leader of a Guild. Rather, someone raises their hand to be the Guild Coordinator and help bring people together.

The Trio (aka TPD Trio) is a combination of a Tribe Lead, product lead, and design lead. Each Tribe has a Trio in place to ensure there is continuous alignment between these three perspectives when working on features areas.

As organizations scale, sometimes multiple Tribes need to closely work together to accomplish a goal. Alliances are a combination of Tribe Trios (typically three or more) that work together to help their Tribes collaborate on a goal that is bigger than any one Tribe.

That’s it. There are not a lot of practices that need to be followed or ceremonies that need to happen. Squads may have ceremonies like sprint planning and retrospectives, but the focus of the Spotify model is on how teams organize around work. It’s up to Squads to figure out the best way to get the job done.

The benefits of the Spotify model

When Spotify changed the way they scaled agile they wanted to enable Squads to move fast, ship software quickly, and do so all with minimum pain and overhead. They realized these benefits and more as they took their model and evolved it. The organizational benefits of implementing the Spotify model include:

Less formal process and ceremony

The Spotify model focuses on organizing around work and not necessarily processes and ceremonies. This gives an organization greater flexibility when it comes to how Squads work. Instead of requiring Squads to change how they do their work (“you must do scrum”), it focuses on aligning them with each other and driving towards individual team outcomes.

More self-management and autonomy

The Spotify model encourages autonomy and creativity by trusting people to complete the work they are doing in the way they see fit. Do you need to ship software? That’s up to the Squad. Do you need to change direction? That’s also up to the Squad. The Spotify model focuses on decentralizing decision making and transferring that responsibility to Squads, Tribes, Chapters, and Guilds.

“Control leads to compliance;  autonomy  leads to engagement.”

- Dan Pink, Author, “Drive: The Surprising Truth About What Motivates Us”

The Spotify model can offer increased transparency across the work being done and grow a more experimentation-based approach to problem solving in a high trust environment. All this can lead to things like better products, happier customers, and more engaged employees. However, not everyone will experience these outcomes.

The challenges of the Spotify model

The Spotify model was based on one organization's way of working. Many organizations desire the same benefits of the Spotify model, so they attempt to emulate what Spotify did. Some organizations experienced more success than others, but it’s likely no organization experienced the same success as Spotify. The reason? Like any way of working, an organization's current culture and structure need to be taken into account. The model is simple, but the environment it's implemented in is complex.

Wise executives tailor their approach to fit the  complexity  of the circumstances they face.

- Dave Snowden, Management Consultant

Unfortunately, many organizations try to copy the Spotify model. To some, it may seem like a simple matrix organizational structure where people report to a functional area (Chapter), but work with a cross-functional team (Squad). However, it’s more complex than that. Although it may look like a matrix organization, the key cultural elements of the model need to be in place to allow the structure to thrive, such as trust and autonomy. If an organization doesn’t shift its behaviors (and ultimately its culture), the benefits of the Spotify model will never be realized. If you simply rename teams to Squads, you’re just putting lipstick on a pig.

Spotify model best practices

If you’re looking to enable a culture of trust, autonomy, and rapid learning, you can’t go wrong looking to the Spotify model for inspiration. If your organization is looking at the Spotify model as a means to help you approach agile at scale , the following is a list of best practices to keep in mind.

Don’t copy the model

Seek to understand the structure, practices, and mindset behind Spotify’s approach. With that understanding, tweak the aspects of the model to fit your own environment. Your goal is not to be Spotify, but to leverage their model to improve how your organization works together.

Autonomy and trust is key

Spotify gave as much autonomy as possible to their people in order to help them pivot quickly. Allowing teams to pick their own development tools and modify another team's code are just some examples. Within your organization, determine if there are decisions that can be pushed to the teams instead of being mandated by parts of the organization that are disconnected from the day-to-day work.

Transparency with community

Spotify’s success is credited to their focus on building community and transparency around their work. Establish your first Guild around the Spotify model adoption and encourage participation from everyone in the organization. Build trust by creating transparent, inclusive ways to gather feedback, and gain alignment on how your organization wants to work in the future.

Encourage mistakes

You will fall down and stumble in this journey. But that’s okay. Improvement involves experimenting and learning from both our successes and failures. Spotify went through many iterations before they attained the model we know today, and have since continued to experiment to constantly look for new ways to improve the way they work. Encourage the same within your organization!

If you focus on these practices you’ll see positive impacts on how your organization collaborates and aligns, whether or not you use the Spotify model as a guide.

In conclusion…

The Spotify model is a great source of inspiration if you’re looking to build an organization focused on moving quickly with autonomy and purpose. Even more formal scaling frameworks, such as Scrum@Scale , have gained inspiration from the model (and vice versa). It's important to remember that the Spotify model is not a destination. Ironically enough, Spotify doesn’t leverage the original implementation of the Spotify model anymore; they evolved and adapted the model to fit their changing organization. Trios and Alliances are actually newer elements in Spotify as they were brought about to solve new problems the organization faced as it grew larger. Starting with the key elements of the Spotify model can get you moving, but true agility comes with evolving the model to fit your context.

Taking the next step

Are you hungry to learn more about the Spotify model? Check the two-part video posted on Spotify Labs about the engineering culture at Spotify ( Part I and Part II ). You can also learn how the Spotify model compares with other scaling framework by visiting the agile at scale page on the Agile Coach.

If you’re looking to implement the Spotify model within your organization, it’s important to have the feedback mechanisms and transparency in place to generate and sustain a culture of trust and autonomy. Leveraging Atlassian’s Jira Align , organizations can organize Squads into Tribes, form Guilds and Chapters, and make product decisions transparent across the organization.

Mark Cruth is Atlassian’s resident Modern Work Expert. Focused on practice over theory, Mark spends his days coaching both Atlassian and customer teams on new ways of working, then sharing what he’s learned at events around the world.

Joining Atlassian in 2019, Mark brings over a decade of experience experimenting with work and helping people, teams, and organizations transform at places like Boeing, Nordstrom, TD Ameritrade, and Rocket Mortgage. Mark has made it his mission to inject modern ways of working, a transformation mindset, and the power of expert storytelling into everything he does.

Scaled Agile Framework (SAFe) Values & Principles

The Scaled Agile Framework® (SAFe®) is a set of organization and workflow patterns for implementing agile practices at enterprise scale.

Agile Quarterly Planning - 8 Steps to Start

Agile quarterly planning helps you build great software while keeping the big picture in mind. Start here with 8 steps as your quarterly planning template.

• 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

HBS Case Selections

OpenAI: Idealism Meets Capitalism

• Shikhar Ghosh
• Shweta Bagai

Generative AI and the Future of Work

• Christopher Stanton
• Matt Higgins

Copilot(s): Generative AI at Microsoft and GitHub

• Frank Nagle
• Shane Greenstein
• Maria P. Roche
• Nataliya Langburd Wright
• Sarah Mehta

Innovation at Moog Inc.

• Brian J. Hall
• Ashley V. Whillans
• Davis Heniford
• Dominika Randle
• Caroline Witten

Innovation at Google Ads: The Sales Acceleration and Innovation Labs (SAIL) (A)

• Linda A. Hill
• Emily Tedards

Juan Valdez: Innovation in Caffeination

• Michael I. Norton
• Jeremy Dann

UGG Steps into the Metaverse

• Shunyuan Zhang
• Sharon Joseph
• Sunil Gupta
• Julia Kelley

Metaverse Wars

• David B. Yoffie

Roblox: Virtual Commerce in the Metaverse

• Ayelet Israeli
• Nicole Tempest Keller

Timnit Gebru: "SILENCED No More" on AI Bias and The Harms of Large Language Models

• Tsedal Neeley
• Stefani Ruper

Hugging Face: Serving AI on a Platform

• Kerry Herman
• Sarah Gulick

SmartOne: Building an AI Data Business

• Karim R. Lakhani
• Pippa Tubman Armerding
• Gamze Yucaoglu
• Fares Khrais

Honeywell and the Great Recession (A)

• Sandra J. Sucher
• Susan Winterberg

Target: Responding to the Recession

• Ranjay Gulati
• Catherine Ross
• Richard S. Ruback
• Royce Yudkoff

Hometown Foods: Changing Price Amid Inflation

• Julian De Freitas
• Jeremy Yang
• Das Narayandas

Elon Musk's Big Bets

• Eric Baldwin

Elon Musk: Balancing Purpose and Risk

Tesla's ceo compensation plan.

• Krishna G. Palepu
• John R. Wells
• Gabriel Ellsworth

China Rapid Finance: The Collapse of China's P2P Lending Industry

• William C. Kirby
• Bonnie Yining Cao
• John P. McHugh

Forbidden City: Launching a Craft Beer in China

• Christopher A. Bartlett
• Carole Carlson

Booking.com

• Stefan Thomke
• Daniela Beyersdorfer

Innovation at Uber: The Launch of Express POOL

• Chiara Farronato
• Alan MacCormack

Racial Discrimination on Airbnb (A)

• Michael Luca
• Scott Stern
• Hyunjin Kim

Unilever's Response to the Future of Work

• William R. Kerr
• Emilie Billaud
• Mette Fuglsang Hjortshoej

AT&T, Retraining, and the Workforce of Tomorrow

• Joseph B. Fuller
• Carl Kreitzberg

Leading Change in Talent at L'Oreal

• Lakshmi Ramarajan
• Vincent Dessain
• Emer Moloney
• William W. George
• Andrew N. McLean

Eve Hall: The African American Investment Fund in Milwaukee

• Steven S. Rogers
• Alterrell Mills

United Housing - Otis Gates

• Mercer Cook

The Home Depot: Leadership in Crisis Management

• Herman B. Leonard
• Marc J. Epstein
• Melissa Tritter

The Great East Japan Earthquake (B): Fast Retailing Group's Response

• Hirotaka Takeuchi
• Kenichi Nonomura
• Dena Neuenschwander
• Meghan Ricci
• Kate Schoch
• Sergey Vartanov

Insurer of Last Resort?: The Federal Financial Response to September 11

• David A. Moss
• Sarah Brennan

Under Armour

• Rory McDonald
• Clayton M. Christensen
• Daniel West
• Jonathan E. Palmer
• Tonia Junker

Hunley, Inc.: Casting for Growth

• John A. Quelch
• James T. Kindley

Bitfury: Blockchain for Government

• Mitchell B. Weiss
• Elena Corsi

Deutsche Bank: Pursuing Blockchain Opportunities (A)

• Lynda M. Applegate
• Christoph Muller-Bloch

Maersk: Betting on Blockchain

• Scott Johnson

Yum! Brands

• Jordan Siegel
• Christopher Poliquin

Bharti Airtel in Africa

• Tanya Bijlani

Li & Fung 2012

• F. Warren McFarlan
• Michael Shih-ta Chen
• Keith Chi-ho Wong

Sony and the JK Wedding Dance

• John Deighton
• Leora Kornfeld

United Breaks Guitars

David dao on united airlines.

• Benjamin Edelman
• Jenny Sanford

Marketing Reading: Digital Marketing

• Joseph Davin

Social Strategy at Nike

• Mikolaj Jan Piskorski
• Ryan Johnson

The Tate's Digital Transformation

Social strategy at american express, mellon financial and the bank of new york.

• Carliss Y. Baldwin
• Ryan D. Taliaferro

The Walt Disney Company and Pixar, Inc.: To Acquire or Not to Acquire?

• Juan Alcacer
• David J. Collis

Dow's Bid for Rohm and Haas

• Benjamin C. Esty

Finance Reading: The Mergers and Acquisitions Process

• John Coates

Apple: Privacy vs. Safety? (A)

• Henry W. McGee
• Nien-he Hsieh
• Sarah McAra

Sidewalk Labs: Privacy in a City Built from the Internet Up

• Leslie K. John

Data Breach at Equifax

• Suraj Srinivasan
• Quinn Pitcher
• Jonah S. Goldberg

Apple's Core

• Noam Wasserman

Design Thinking and Innovation at Apple

• Barbara Feinberg

Apple Inc. in 2012

• Penelope Rossano

Iz-Lynn Chan at Far East Organization (Abridged)

• Anthony J. Mayo
• Dana M. Teppert

Barbara Norris: Leading Change in the General Surgery Unit

• Boris Groysberg
• Nitin Nohria
• Deborah Bell

Adobe Systems: Working Towards a "Suite" Release (A)

• David A. Thomas
• Lauren Barley

Home Nursing of North Carolina

Castronics, llc, gemini investors, angie's list: ratings pioneer turns 20.

• Robert J. Dolan

Basecamp: Pricing

• Frank V. Cespedes
• Robb Fitzsimmons

J.C. Penney's "Fair and Square" Pricing Strategy

J.c. penney's 'fair and square' strategy (c): back to the future.

• Jose B. Alvarez

Osaro: Picking the best path

• James Palano
• Bastiane Huang

HubSpot and Motion AI: Chatbot-Enabled CRM

• Thomas Steenburgh

GROW: Using Artificial Intelligence to Screen Human Intelligence

• Ethan S. Bernstein
• Paul D. McKinnon
• Paul Yarabe

Arup: Building the Water Cube

• Robert G. Eccles
• Amy C. Edmondson
• Dilyana Karadzhova

(Re)Building a Global Team: Tariq Khan at Tek

Managing a global team: greg james at sun microsystems, inc. (a).

• Thomas J. DeLong

Organizational Behavior Reading: Leading Global Teams

Ron ventura at mitchell memorial hospital.

• Heide Abelli

Anthony Starks at InSiL Therapeutics (A)

• Gary P. Pisano
• Vicki L. Sato

Wolfgang Keller at Konigsbrau-TAK (A)

• John J. Gabarro

Midland Energy Resources, Inc.: Cost of Capital

• Timothy A. Luehrman
• Joel L. Heilprin

Globalizing the Cost of Capital and Capital Budgeting at AES

• Mihir A. Desai
• Doug Schillinger

Cost of Capital at Ameritrade

• Mark Mitchell
• Erik Stafford

Finance Reading: Cost of Capital

David Neeleman: Flight Path of a Servant Leader (A)

• Matthew D. Breitfelder

Coach Hurley at St. Anthony High School

• Scott A. Snook
• Bradley C. Lawrence

Shapiro Global

• Michael Brookshire
• Monica Haugen
• Michelle Kravetz
• Sarah Sommer

Kathryn McNeil (A)

• Joseph L. Badaracco Jr.
• Jerry Useem

Carol Fishman Cohen: Professional Career Reentry (A)

• Myra M. Hart
• Robin J. Ely
• Susan Wojewoda

Alex Montana at ESH Manufacturing Co.

• Michael Kernish

Michelle Levene (A)

• Tiziana Casciaro
• Victoria W. Winston

John and Andrea Rice: Entrepreneurship and Life

• Howard H. Stevenson
• Janet Kraus
• Shirley M. Spence

Partner Center

Nike Case Study

While Nike had adopted Agile as a method prior to our engagement with them, the practice hadn’t been rolled out in full across the organization. As a result, the leadership was seeing only pockets of improvement. As part of Nike’s innovation strategy, which included reducing time-to market, the company’s leadership planned to increase their agile capabilities. Their aim was to increase the overall agility of the organization in an effort to 1) improve team engagement, and 2) reduce costs.

Hyperdrive trained and developed 30 Nike Agile Coaches over the course of the engagement, located across the world. In addition to the OPEX savings of over $4 million, the Nike Consumer Digital arm was able to focus their efforts on meeting the larger company goals of increasing innovation and reducing time-to-market for their deliverables. Moreover, Nike surprised Wall Street with strong 2nd quarter growth following the engagement. An analyst reported, “We believe Nike’s Q2 performance proves the brand remains strong, margin drivers are intact (Direct to Consumer / Digital) and global demand is healthy.”

Questions? We Can Help.

If you have questions, we have answers. Get personalized guidance from the world’s leaders in Agility.