agile case study presentation

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. 

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

• Online Academy Login
• Community Login
• Book Software Profit Steams™ written by Jason Tanner & Luke Hohmann
• Community Join the Virtual Gathering place for business and Product Leaders to gain expert advice
• Partners Deliver Profit Streams Courses and Services by becoming a Profit Streams Partner
• Solution Profitability Management™ Our services and products help companies design pricing and packaging that maximizes profit throughout the solution lifecycle.
• Training Use Profit Streams™ to accelerate your growth, get expert advice, and gain a deeper understanding of Pricing, Profit Engines, and Customer ROI.
• Profit Stream Canvas Discover the relationship between Economic, Relationship, and Solution sustainability, and design a sustainably profitable software-enabled solution.
• Horizon The official Solution Profitability Management Platform.

Introducing Horizon

• Solution Profitability Workshops A workshop for leadership teams that provides the knowledge needed to improve pricing, packaging, and ROI models to fuel your growth
• Profitable Portfolios with SAFe Create sustainably profitable portfolios, unlocking your full potential for financial success.
• Pricing & Packaging Make data-driven decisions to manage profitability
• Sustainable SAFe® By integrating our deep expertise in SAFe and Solution Profitability Management, our Sustainable SAFe consulting services ensure you realize the full value of SAFe throughout every solution lifecycle
• Custom Solutions We have the expertise to design a customized engagement that caters to your unique context. No matter what you need, we will create a solution that works best for you
• View Upcoming Courses Check out the upcoming CSPO, SAFe, and CSM classes
• Profitable Software Academy Transform your product organization and grow world-class product managers with our online academy.
• SAFe Learn the Scaled Agile Framework® from experts with real-world experience.
• Scrum Live Online & In-Person Scrum Alliance Certified Training. Check out our upcoming CSPO and CSM Courses.
• Profit Streams Use Profit Streams™ to accelerate your growth, get expert advice, and gain a deeper understanding of Pricing, Profit Engines, and Customer ROI

APM/LPM Open Forum

• Profitable Software Profitable Software is necessary to create a sustainable business.
• Product Management Keep up to date on the latest advances in the Product Management Industry
• SAFe Thriving in the digital world requires a way of working grounded in agility, adaptability, and resiliency.
• Product Management Minute Dive quickly into product management topics in this series of short, webinars.
• Video Testimonials We know the work we do makes a difference. See what our clients say.
• Art of Agile Access resources designed to further your Scrum learning journey.
• Profit Streams Profit Streams are the necessary evolution of value streams. Align on what matters most. Profit.
• SPC Journey Explore what being a SAFe Practice Consultant really means.
• Webinars Check out webinars hosted by thought leaders and experts in Agile, Product Management, SAFe, and Profitable Software.

What is a Profit Stream?

• About Applied Frameworks Thought leaders advancing the communities we love and serve.
• Partners Deliver world-class Profit Streams training and consulting services as a Profit Streams Partner
• Our Team Innovators. Designers. Authors. Developers. SAFe Framework Contributors. Collaborators building sustainably profitable software-enabled solutions.
• Careers Life is about creating memories. Work is about achieving amazing goals. At Applied Frameworks, you can do both.
• Diversity, Equity, and Inclusion DE&I are powerful values that forge a sense of belonging within our environment.

• Profit Streams Overview
• Profit Stream Canvas
• Consulting Overview
• Solution Profitability
• Profitable Portfolios with SAFe
• Sustainable SAFe
• Packaging & Pricing
• Custom Solutions
• Training Overview
• Profitable Software Academy
• Profit Streams

Examples of Scrum Case Studies

[Updated February 2024]

Successful Scrum Implementations across various Industries

In my Scrum training courses , students often ask for examples of Scrum case studies. This happens consistently in classes for Product Owners, Scrum Masters, and our Advanced courses . 

In general, I believe case studies are irrelevant to learning Scrum. To truly grasp Scrum, it is best to experience it firsthand. By trying it yourself, you can then evaluate (inspect and adapt) and make necessary adjustments. This is more effective than solely relying on reading about how others have implemented it.

However, I recognize the value of seeing successful adoption when learning new skills and toolkits. Today, I decided to succumb to this request and offer up these seventeen examples for your reading pleasure.

• Dutch Railways : this case study describes how Dutch Railways used a distributed team from the Netherlands and India to implement Scrum . It was successful after a previous project failed to deliver in three years. The case study discusses architecture, requirements, documentation, and other topics.
• Agile Project Management at Intel – A Scrum Odyssey:   is a detailed case study that describes how Intel used distributed Scrum within a traditional management culture to reduce cycle time by 66% and eliminate schedule slips within a year .
• Agile Case Study – H&R Block:  summarizes how a traditional, time-sensitive consumer tax preparation service transformed its business using Scrum. The real value in this case study are the links to the high-quality, short video testimonials from the participants explaining the benefits of Scrum .
• How to Implement Scrum in an Interrupted Environment:  If this sounds like your organization, then you have to read how Intronis, a leading provider of online backup services, doubled the productivity of its call center in six months. Scrum Inc. has shared its five steps to help this organization tame the interruption beast.
• Scrum Boosts Effectiveness at the BBC :  in this thirty-eight-minute video presentation, the Head of Development of the BBC's New Media Division discusses their multi-year journey to use Scrum effectively.
• Owning the Sky with Agile: this case study describes the results of Jeff Sutherland's effort to help Saab Defense adopt Agile practices to develop an advanced fighter jet. While the title says "Agile, "this is a case study of Scrum's effectiveness in building mission-critical software.
• Effects of Scrum Nine Months Later :  case study author Richard Bank identifies the lasting benefits of Scrum after a disastrous, piecemeal introduction of Scrum . Be sure to read his candid assessment of how he failed.
• Effective Practices and Federal Challenges in Applying Agile Methods :  the Government Accountability Office (GAO) reviews the challenges and success factors for Agile projects within the federal government based on their investigation of four successful programs.
• Adobe Premiere Pro Scrum Adoption : in this 2012 study, Adobe explains how they used Scrum to successfully coordinate the actions of a distributed Scrum Team within an environment composed of non-Scrum Teams .
• Mayden's Transformation from Waterfall to Scrum:  the Scrum Alliance offers this short case study of how a young UK provider of cloud-based software used Scrum to break away from old habits to improve code quality and customer service.
• Rolling Out Agile in a Large Enterprise : This 2006 case study discusses how Yahoo! used Scrum to support over 100 software teams and provides interesting metrics on how to evaluate and monitor Scrum Teams in a large enterprise.
• Borland's Agile Journey – A Case Study in Enterprise Transformation :  in this 2009 case study, the Senior Vice President of R&D at Borland talks about the benefits they received and the key lessons learned in their three-year journey to apply Scrum to their business.
• Business Analysts and Scrum Projects :  This case study briefly describes how a business analyst's role changes when embedded full-time on a cross-functional Scrum Team.
• My Experience as QA in Scrum : This is a detailed experience report of the day-to-day activities of a tester on a Scrum Team.
• Moving Back to Scrum and Scaling to Scrum of Scrum in Less Than a Year :  this fifteen-minute video presentation explains how one Brazilian company struggled with Scrum, failed, and eventually succeeded .
• Introducing Scrum in Companies in Norway:  Nordic researchers provide this case study of the factors that lead to successful Scrum adoption and which factors lead to failure and frustration. 
• A CIO's Playbook for Adopting the Scrum Method of Achieving Software Agility :  this 28-page whitepaper from 2005 describes step-by-step how Ken Schwaber envisioned a Scrum business transformation might unfold .

Qualifying for the List:

• Do "out-of-the-box" Scrum with very few modifications.
• Write a document or blog entry describing their experience (a PowerPoint presentation without narration does not qualify).
• Case Study is freely available on the internet.

Additional Resources for Scrum Learning

Continuous learning and adaption are persistent themes in successful Scrum Implementations.  To set yourself and your teams up for success, attend an upcoming public or private CSPO or CSM course.  

Already a Certified Product Owner or Certified Scrum Master?  Check out our online, on-demand advanced training programs.   The world’s first online, on-demand Advanced Scrum Certification offers you the unique ability to earn an A-CSM, A-CSPO, CSP-PO, or CSP-SM at a pace that works for you.

Editors Note: This blog was initially published in 2012 and has been revised repeatedly, republished in 2022, and most recently updated in February 2024. Do you have a case study you'd like to add?    Contact us .

Carlton Nettleton

Carlton Nettleton is the former SVP of Product at Applied Frameworks, and co-creator of the company's Advanced Scrum Online Academy and Profitable Software Academy. Carlton has over twenty years of industry experience working with clients to improve quality, increase productivity, build great teams, and launch new products using Agile software development practices and techniques. Today, Carlton is the President of Look Foward Consulting and focuses on mentoring and supporting Scrum and Agile practitioners who work in less-than-ideal conditions. He shares his energy and enthusiasm with learners so they can achieve their personal and professional goals. Carlton is fluent in both English and Spanish, has written a short book on Scrum, and has been Certified Scrum Trainer® since 2012.

What's Next?

There's always more to learn. check out webinars, practice exams, and more., agile metrics: 4 balanced kpis to measure success, csm practice exam: update for 2020, the scrum master exam questions you’re most likely to get wrong, want to be notified when new content is added.

Stay up to date on all things profit and subscribe to the Applied Frameworks Splash page!

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?

Salesforce: An Agile Case Study

Key Takeaways: What worked for Salesforce 

• Organizational culture and established values prime an organization to be ready to take on an Agile framework.
• When Agile values are communicated from the top, they are infused into the organizational mindset to occur organically without enforcement as “rules.”
• Finding the right language to explain Agile to un-transitioned departments encourages teams to use Agile frameworks in a way that works for them.  

  In 2006 Salesforce decided to go all in with agile and transform their entire R&D department from traditional “Waterfall” SDLC — a top-down software lifecycle process — to Scrum, an iterative agile framework. At the outset of the transition, company leadership knew they would face roadblocks if they couldn’t make clear to employees the compatibility between Scrum principles, their company’s mission, and their individual employees’ values. Without this critical first step, the same lightweight, adaptable quality that makes Scrum successful could also render it susceptible to misinterpretation. So, Salesforce began its agile transformation not by blindly adopting the Scrum framework, but by first educating employees on Scrum’s alignment with preexisting company values.    Their “Educate Without Enforcing” strategy generated positive results, in part because upper management and staff already shared a coherent sense of the company’s overall mission and each employee’s individual purpose and could easily explain how the Scrum framework was uniquely suited to achieve those ends.    “We are fortunate that our founders were as intentional about the culture they wanted to create as they were about the products they wanted to build,” says Arun Ramanna, an Enterprise Agile Coach at Salesforce. “Agile frameworks such as Scrum, XP, and Lean face less transitional challenges at Salesforce than at others, because Salesforce has an environment of trust, customer success, diversity, equality, and innovation.”   It was in 1999 that Salesforce founded their popular  V2MOM Process . The acronym stands for vision, values, methods, obstacles and measures, and is used as a management tool for organization wide communication and adaptive development.V2MOM had pre-established transparency throughout the organization, so the company had a cultivated sense of trust vital to successful Scrum practices. And as a result, Salesforce proved to be better prepared for Scrum than many other pre- or partially agile organizations.   Yet challenges remained. Project managers feared losing the accurate timetables and deliverables on which they relied, and it was difficult to explain to them the purposes of agility beyond its concrete definition or discrete practices. To address these issues, the company held frequent meetings with departments that had not switched to an agile framework, framing agility as a mindset uniquely compatible with — and already present within — the organization’s mission and values. Leaders were able to explain how and why agility aligned with Salesforce and its employees’ sense of shared purpose.    Salesforce also used the strategy of framing Agile techniques, such as XP practices, Scrum artifacts, and Lean thinking as “tools.” This helped the company explain the benefits of agility to the organization without imposing Agile principles as mandates.    “We often hear our leaders say things like ‘Make sure we are focused on our customer’s success’, ‘Better, better, never done!’ and ‘Let’s approach it with a beginner’s mind’ to keep us on this journey,” Arun explains. These phrases embody the values of the  Agile Manifesto . Salesforce leaders regularly communicate the sentiment of agile without directly enforcingthe values as hard rules.   “Salesforce is always looking to improve our technology, products, and processes to make us more agile and customer focused,” continues Arun. “It’s because Salesforce continues to have both ‘top-down’ and ‘bottom-up’ organizational buy in and support for agile that it is able to be so successful and adaptive.”    Today, Salesforce continues to explore new approaches in applying agility within its different departments. As an organization, they remain flexible regarding their methods and open-minded about their results and are still discovering what practices work in different organizational contexts. Currently, their most essential task has become learning to tailor Agile methods to allow all departments and teams to have an iterative approach to work.    “The response has been very positive thus far, and it would be hard to imagine ever going back to a traditional waterfall approach,” Arun concludes. “In fact, our agile coaching team’s long-term goal is to spread this agile mindset beyond our R&D, IT and Marketing departments to our entire organization, and to all our partners and customers.”

Get the latest resources from Scrum Alliance delivered straight to your inbox

Large-scale agile transformation at Ericsson: a case study

• Open access
• Published: 11 January 2018
• Volume 23 , pages 2550–2596, ( 2018 )

Cite this article

You have full access to this open access article

• Maria Paasivaara 1 ,
• Benjamin Behm 1 ,
• Casper Lassenius   ORCID: orcid.org/0000-0003-4192-7024 1 &
• Minna Hallikainen 2  

50k Accesses

78 Citations

18 Altmetric

Explore all metrics

Many large organizations are adopting agile software development as part of their continuous push towards higher flexibility and shorter lead times, yet few reports on large-scale agile transformations are available in the literature. In this paper we report how Ericsson introduced agile in a new R&D product development program developing a XaaS platform and a related set of services, while simultaneously scaling it up aggressively. The overarching goal for the R&D organization, distributed to five sites at two continents, was to achieve continuous feature delivery. This single case study is based on 45 semi-structured interviews during visits at four sites, and five observation sessions at three sites. We describe how the organization experimented with different set-ups for their tens of agile teams aiming for rapid end-to-end development: from component-based virtual teams to totally cross-functional, cross-component, cross-site teams. Moreover, we discuss the challenges the organization faced and how they mitigated them on their journey towards continuous and rapid software engineering. We present four lessons learned for large-scale agile transformations: 1) consider using an experimental approach to transformation, 2) consider implementing the transformation step-wise in complex large-scale settings, 3) team inter-changeability can be limited in a complex large-scale product — specialization might be needed, and 4) not using a common agile framework for the whole organization, in combination with insufficient common trainings and coaching may lead to a lack of common direction in the agile implementation. Further in-depth case studies on large-scale agile transformations, on customizing agile to large-scale settings, as well as on the use of scaling frameworks are needed.

Similar content being viewed by others

Future Trends in Agile at Scale: A Summary of the 7th International Workshop on Large-Scale Agile Development

Business Development in Large-Scale Agile Software Development: Barriers and Enablers

Tailoring Agile in the Large: Experience and Reflections from a Large-Scale Agile Software Development Project

Avoid common mistakes on your manuscript.

1 Introduction

Increasing pressure to reduce cycle time, improve quality, and swiftly react to changes in customer needs are driving companies, large and small, to adopt agile software development (VersionOne 2016 ). Agile development can improve efficiency and quality (Livermore 2008a ), and enable shorter lead times and a stronger focus on customer needs (Petersen and Wohlin 2010 ).

Even though agile software development methods were originally designed for single, small teams, during recent years, large organizations have increasingly adopted them (Hossain et al. 2009 ; Larman and Vodde 2010 ; Leffingwell 2007 ). A recent systematic literature review (Dikert et al. 2016 ) revealed the lack of systematically conducted studies on large software development organizations adopting agile methods. The review identified only six scientific studies on large scale agile transformations, as almost 90% of the included papers were experience reports. According to the State of Agile Survey (VersionOne 2016 ), 43% of the self-selected respondents worked in development organizations having more than 50% of teams using agile, while only 4% of respondents stated that none of their teams were agile, and 62% of almost 4000 respondents came from an organization with over a hundred people in software development. While the survey is non-scientific, and problematic from a methodological point of view (Stavru 2014 ), it is the largest reoccurring survey on agile adoption, and it indicates that a significant number of big organizations use agile. Moreover, practitioners at the XP conference in 2010 listed the topic “Agile and large projects” as the number one top burning research question (Freudenberg and Sharp 2010 ). In recent workshops on large-scale agile development, the introduction of agile methods was one of the highlighted themes needing more research (Dingsøyr and Moe 2013 ; 2014 ).

Large organizations often have big projects executed by large and distributed development organizations, requiring agile methods to be scaled. According to (Leffingwell 2007 ), scaling involves many challenges, including coordination between several agile teams, lack of up-front architecture, lack of requirements analysis, as well as all the challenges of distributed projects, as many large organizations are distributed. Despite these challenges, many large companies have chosen to adopt agile methods, even though research on how to scale agile methods to large-scale projects (Hossain et al. 2009 ), and on successfully conducting agile transformations in large organizations is largely missing (Dikert et al. 2016 ).

The purpose of this paper is to start filling the gap in the literature on large-scale agile transformations. We investigate how one large-scale R&D product development program within Ericsson adopted agile methods at scale. We present the motivation for the transformation, the steps taken, the challenges encountered, as well as the mitigating actions taken to tackle the challenges.

The case organization was a new R&D product development program at Ericsson developing a XaaS Footnote 1 platform and a set of services. Ericsson’s customers, telecom operators, can provide a number of services to their customers using the platform.

The development organization wanted to develop the capacity for continuous delivery (Rodríguez et al. 2016 ). As a step towards that goal, the organization adopted agile methods (Schwaber and Beedle 2002 ). The planning of the agile adoption started in late 2012 and the full-scale roll-out took place during 2013. By spring 2014, the development organization had grown from two team at the end of 2011 to 15 development teams, distributed to five global sites. Thus, this can be viewed as a large-scale agile adoption according to the definition used in (Dikert et al. 2016 ), which states that large-scale agile is software development organizations with 50 or more people or at least six teams .

In our previous work, we presented the initial results of the transformation (Paasivaara et al. 2014a ) and how the case organization had used Value Workshops as to facilitate organizational alignment during the transformation (Paasivaara et al. 2014b ). This paper elaborates on and extends the previous papers by presenting an in-depth analysis of the case, including an additional research question (RQ1), a more detailed description of the research method, with an additional validation interview, a significantly extended results section going deeper into the results, and a completely new discussion section.

The paper is structured as follows: Section  2 provides an overview of the previous literature, Section  3 describes the case background, research goals and methods, Section  4 presents our results, Section  5 discusses the results, and finally, Section  6 concludes the paper.

2 Related Work

In this section we present relevant previous work. First, we explain what we mean by large-scale agile software development, and why it is important to study. Second, we discuss why large organizations are interested in large-scale agile, as well as challenges and success factors of the transformations.

2.1 Large-Scale Agile Development

Agile methods were originally developed for small organizations, and despite success stories, large-scale application has proved challenging (Dybå and Dingsøyr 2008 ). Challenges in large-scale agile adoptions relate partly to organizational size bringing inertia, which slows down the change process (Livermore 2008b ). Another challenge is the need to interface with and integrate existing processes and organizational structures (Boehm and Turner 2005 ).

Agile methods focus largely on intra-team practices, which work well in small organizations. A challenge in large organizations is that it is necessary to coordinate and communicate between several development teams, and also between different organizational units. Agile methods provide little guidance on how agile teams should interact with the environment at large. Because of this, large organizations must tailor the methods to fit their specific needs. As a consequence, practices requiring additional formal communication may need to be put in place, which might reduce agility (Lindvall et al. 2004 ).

Large organizations are often globally distributed, which brings the need to apply agile in distributed projects. During recent years agile practices have gained a foothold in global software engineering projects, and there is evidence of benefits of agile use (Hanssen et al. 2011 ). However, agile methods are largely based on frequent internal and external collaboration and communication (Highsmith and Cockburn 2001 ), and such close collaboration is inherently challenging in global work, which complicates the use of Agile in global software engineering (Hanssen et al. 2011 ). On the other hand, Agile has qualities that brings remedy to the challenges caused by distance in global work. Suitable agile practices may bring distributed sites closer each other by improving coordination and communication (Holmstrom et al. 2006 ).

During recent years frameworks for scaling agile software development have been suggested by several consultants, e.g., the Scaled Agile Framework (SAFe) (Leffingwell 2015 ), Large-Scale Scrum (LeSS) (Larman and Vodde 2015 ), and Disciplined Agile Delivery (DAD) (Ambler 2012 ). However, documented experiences on the usage of these frameworks is still scarce, e.g., how they are used, to what kind of circumstances they are best suited, and what the challenges and success factors of their usage are. The State of Agile Survey (VersionOne 2016 ) shows that a large number of companies seem to be using some framework, as 27% of the respondents reported using SAFe, 6% LeSS and 4% DAD. In addition, most respondents (72%) stated using Scrum or Scrum-of-Scrums to help to scale (respondents could make multiple selections).

A recent systematic literature review on large-scale agile transformations (Dikert et al. 2016 ) reported that only six, or 12% of existing 52 reports were scientific. Most of the selected papers were experience reports published in the XP and Agile conferences, showing practitioner interest in the topic, and that academic research is lagging behind.

None of the scientific studies included in the systematic literature review by (Dikert et al. 2016 ) focused directly on the transformation process, even though they briefly described it. Two of the papers (Abdelnour-Nocera and Sharp 2007 ; 2008 ) reporting on the same case concentrated on the effects of the agile transformation. A study about Ericsson R&D Finland (Rodríguez et al. 2013 ) Footnote 2 focused on how Lean thinking is implemented, however the focus was mostly on the current state instead of the transformation process. A paper from Nokia Siemens Networks (Korhonen 2012 ) studied whether the visibility, reaction speed, quality, or motivation had changed, comparing the situation before and after the transformation. (Murphy and Donnellan 2009 ) studied the good and bad aspects of communication during an agile transformation and (Vlaanderen et al. 2012 ) in their multiple-case study of two cases analyzed the Scrum introduction paths. While evaluating the relevance of each of the research papers regarding how well they provide information on large-scale agile transformations on scale a 1-5 (1: some sentences revealing factors relating to transformation, 5: the entire paper focuses on describing how the transformation proceeded). (Dikert et al. 2016 ) gave two of the papers (Abdelnour-Nocera and Sharp 2007 ; 2008 ) (reporting on the same case) the rating 3, while the rest received only either 1 (one paper) or 2 (3 papers). This reveals how the current research on large-scale agile transformations is lagging behind the state-of-the practice.

2.2 Motivation to Initiate an Agile Transformation

According to the literature one of the top reasons for a large software development organization to start an agile transformation was to reduce the time to market (Gat 2006 ; Goos and Melisse 2008 ; McDowell and Dourambeis 2007 ; Prokhorenko 2012 ; Silva and Doss 2007 ), as the competition and market situation was changing towards speedier deliveries (Greening 2013 ). Companies want to improve their competitiveness, or even fear that they are losing competitiveness. Thus, their response is to improve delivery speed and responsiveness to change.

Another significant motivator was software project management related reasons. Many companies had experienced problems related to project management (Long and Starr 2008 ), people management, and managing schedules (Chung and Drummond 2009 ) that they were hoping to correct.

The old process and the whole way of working was considered problematic due to overhead, seen in extra bureaucracy causing needless costs in the form of unproductive meetings (O’Connor 2011 ), process gates (Chung and Drummond 2009 ), change management overhead (Vlaanderen et al. 2012 ) and excess documentation (Hansen and Baggesen 2009 ; Murphy and Donnellan 2009 ). Slow processes with long cycle times led to late feedback (Beavers 2007 ; Ranganath 2011 ).

2.3 Challenges and Success Factors of Large-Scale Agile Transformations

Any organizational transformation that involves numerous individuals will face challenges. A systematic literature review (Dikert et al. 2016 ) identified 29 success factors for large-scale agile transformations grouped into 11 categories and 35 challenges in 9 categories. The review identified the following main challenges for large-scale agile transformations: other functions unwilling to change (mentioned by 31% of the reported cases), lack of guidance from the literature (21%), reverting to the old way of working (19%) and misunderstanding agile concepts (19%). The top challenge categories mentioned were agile difficult to implement, integrating non-development functions, change resistance and requirements engineering challenges.

The most salient success factors identified were: coaching teams as they learn by doing (29%), ensuring management support (29%) and customizing the agile approach carefully (26%). The top success factor categories listed are: choosing and customizing the agile approach, management support, mindset and alignment, and training and coaching.

The State of Agile Survey (VersionOne 2016 ) reports the following tips for large-scale agile transformations: consistent process and practices (mentioned by 43% of respondents), implementation of a common tool across teams (40%), agile consultants or trainers (40%), executive sponsorship (37%), and internal agile support team (35%).

3 Methodology

3.1 background.

This paper uses a single case study methodology (Yin 2009 ) in a software development organization at Ericsson developing a XaaS platform and a related set of services. We subsequently refer to this whole as the “product”.

The product provides a set of services to business customers, who use it to provide services to their clients. Originally, the platform was designed for a single customer. At the time of our interviews, the product was in its early life-cycle with tens of customers, the number of which was expected to grow rapidly, and the product was considered to have a vast market potential.

Architecturally, the product consisted of modules, subsequently referred to as components. Some components were developed by third-parties and some by Ericsson. The development of the components required highly specialized expertise due to their complexity.

Ericsson acquired the product in 2011. Before the acquisition, approximately 30–35 people, including external contractors and consultants, developed the whole platform. As part of the acquisition, Ericsson hired around ten domain experts from the previous development organization and took over the further product development. Directly after the acquisition, the newly built organization had to focus on knowledge transfer from the external consultants to Ericsson’s employees and to the newly hired consultants.

The development organization at Ericsson grew rapidly: from two teams at the end of 2011 to 10 teams in spring 2013 and 15 teams by the spring of 2014. New developers and teams were added to the organization gradually. The biggest increases happened in late 2012 and during 2013. In the fall of 2012 an external consultancy provided personnel to the project (at site E), and both internal and external recruiting was done. During the summer and fall 2013, five agile teams were added to Site A, part of which were reassigned from another project at Ericsson.

During this time, the size of organization increased from a few dozens to around 200. In spring 2014 the development organization consisted of agile teams (typically consisting of 7-9 persons), Product Owners, architects, agile coaches, line managers, product managers and other managers. In addition, the organization included sales personnel, and customer support and operations.

At the time of our data collection (Fall 2013 - Fall 2014) the development organization was distributed to five sites in three countries as illustrated in Fig.  1 . Four of the sites were in Europe (sites A, B, C, D) and one (site E) in Asia. Site E was a subcontracted site, not Ericsson’s own. In addition, customer support and operations were located at a sixth site (site F), which was not considered as part of the development organization, and was therefore not included in this study.

Project sites and distribution at the time of our data collection (Fall 2013 - Fall 2014)

After the acquisition, when moving the development to Ericsson, experts on specific components were hired both internally and externally to several sites. As each component required deep expertise, learning new components takes a lot of time. The competences for each component were in many cases not located at a single site, but distributed to several locations. Moreover, a single feature could span several components, requiring different expertise to develop, see Fig.  2 . Thus, matching features spanning several components to the component-based competences located at different sites provided significant challenges for rapid end-to-end development. This feature-component structure remained the same during the transformation, even though the organization structure around was changed.

Features vs. components

Ericsson has traditionally used a plan-driven software process. However, during recent years the company started a global adoption of agile software development. The studied organization started its transformation, or “the agile journey”, as they call it, in late 2012 and the first agile pilot team was formed in early 2013. This transition has been particularly challenging, as the organizational growth has been significant and rapid during the transformation, which is still ongoing.

3.2 Research Goals and Questions

Our research goal was to investigate how this large, globally distributed organization reorganized its development and processes by taking agile methods into use.

We purposefully selected this information-rich case (Patton 1990 ), as we had the possibility to gain access based upon participation in a joint research program, and we had previously studied another agile transformation in the same company (see (Paasivaara et al. 2013 )), thus we knew that this case would provide us rich data on the studied phenomenon. We selected a revelatory case (Yin 2009 ), which enabled us to study a yet unstudied phenomenon. This case enabled us to study, over a longer period of time, how a large, globally distributed organization developing a complex product takes agile into use, the steps of the transformation, as well as challenges and mitigating actions. As discussed earlier, this is a topic that has not been studied scientifically almost at all, thus we saw this as a unique research opportunity. The case setting provided us with access to an industrial real case setting in a rarely studied empirical context and allowed us to follow the transformation over a period of time, thus proving us a unique dataset.

We posed the following research questions:

Why did the organization initiate an agile transformation?

How did the transformation proceed?

What challenges did the organization encounter?

How did the organization mitigate the challenges?

3.3 Data Collection

The data collection took place between September 2013 and September 2014. We used three sources of data: 1) interviews, 2) observations, and 3) company internal documents.

The first three authors collected the data together. The fourth author, a representative of the organization, was our main contact person during the study, as well as one of the key informants. She helped us select the interviewees and arranged access to the events we observed. She also validated the findings of this paper by reading and commenting on the paper draft. Figure  3 shows the data collection timeline.

Timeline of the data collection

3.3.1 Interviews

We conducted a total of 45 semi-structured interviews in three rounds: 1) 31 interviews on the transformation journey, 2) twelve interviews on value workshops (which were one of the major steps during the transformation journey described later on), and 3) two validation interviews after analyzing the data.

The goal of the transformation interviews was to study the large-scale agile adoption. During that first interview round we conducted 31 interviews of altogether 34 persons at four sites.

The roles of the interviewees included development team members (i.e., members of agile teams such as developers and testers), Product Owners, coaches and managers. We aimed to interview a broad representation of the organization, talking to informants in different roles, with various backgrounds and representing different organizational levels in order to gain as complete a view of the situation as possible. We mainly selected persons with long experience with the organization to be able to reflect the whole transformation journey, but also a few persons joining later on to give us another perspective. Many of the interviewees had a long background at Ericsson. About half had joined Ericsson over ten years ago. 2/3 of the interviewees had joined the studied case project over a year before our interviews and only 1/3 had less than a year of experience from the case project. A bit more than half of the interviewed persons had a background in agile methods before joining the project, and around half of them had transferred to the project from the first agile project at site A, reported in (Paasivaara et al. 2013 ). All interviewees were selected with the help of case organization representatives. The interviews typically lasted one hour, but the length ranged from half an hour to two hours. Especially for the few first interviews, we reserved more time, as we asked more background questions in order to understand the history of the organization and the starting point of the transformation. These early interviewees were managers and coaches, who had a broader overview of the organization. The subsequent interviews were focused on the transformation and were somewhat shorter. During the first interview round, two researchers participated in all interviews, one being the main interviewer (Author 1, in a few interviews Author 3) and the other one taking detailed notes, as well as asking additional questions (Author 2).

During the first interview round we learned that the organization had started to define common values, and would be working further with these values in workshops. The common values and the related value workshops were an important step during the transformation journey, which was the reason why we decided to study them further. We had a possibility to participate as observers in both workshops and, after the second workshop, interview 12 participants from three different sites. This formed the second interview round. These interviews were short, ranging from 15 to 30 minutes each. The interviewees ranged from team members to managers. These interviews were conducted by a single researcher (Author 1), who selected the interviewed persons amongst the workshop participants.

During the third interview round two interviews were done to validate our results after we had analyzed the data. The first interview took place after we had analyzed the data from the first interview round and the second one after analyzing the second round interviews. The main purpose of these interviews was to deepen our understanding about topics that emerged when analyzing the data, as well as validate that we had understood particular issues correctly, e.g, the product structure. In the first of these interviews two researchers and two interviewees were present and in the last one, one researcher and one interviewee. These interviewees were selected as they had a broad view of the whole organization and were actively involved in the transformation in the whole organization in their roles as line manager, project steering committee member and organizational coach.

The number of interviews and interviewees differ, as in two interviews we had two interviewees and in another three. The multi-person interviews during the first interview round were due to interviewee time limitations. For example, we could have interviewed only one of the three coaches (who had been doing exactly the same work) and only one of the consultants (also working tightly together), but the interviewees suggested group interviews to which we agreed, as we thought it would give us a broader picture than conducting single person interviews. In addition, in the last validation interview we had two interviewees, with whom we checked our results and asked clarifying questions.

During the two first interview rounds we used an interview guide approach with predetermined topics as suggested by Patton ( 1990 ). The main topics were the same for each interviewee but the questions were adjusted based on their position and background. Table  1 shows the roles interviewed and the interview guides can be found in Appendix  A and  B .

All interviews were conducted face to face in the organization’s facilities and recorded. The recordings were transcribed by a professional transcription company.

As part of this study, we visited all the European sites (A, B, C, D). Unfortunately, due to budgetary restrictions, we were not able to visit the Asian subcontracted site (E), but were able to interview one representative of that site who temporarily was located at site D. Except for that one interview, the data we have on site E are the descriptions given by people at sites A, C, and D who closely collaborated with that site. However, our results focus on the main internal sites (A, B, C and D), as this was where the large-scale agile transformation took place. Site E as an external site, was not actively included in the transformation, and the plan was to drop the site in the near future.

3.3.2 Observations

To support the interviews, we conducted five observation sessions of altogether 31,5 hours during seven days. The events observed were selected carefully to support our study: 1) to see in practice how the basic Scrum practices were implemented in the case organization we observed how a Scrum team performed the activities related to a sprint change: sprint review, retrospective and sprint planning. 2) To understand how the major coordination events worked in practice, we observed the weekly Product Owner meeting, as well as two common bi-weekly demos, where a team or teams who have finished something that might interest others demonstrated their work. 3) To follow major transformation events, we observed both 2-day value workshops (arranged at sites A and D) and one continuous integration (CI) roadshows (arranged at site A). As explained later on, common values and the related value workshops were one of the major transformation steps. They were organized to unite the globally distributed organization. Building the CI system and spreading the CI knowledge and CI mindset in the organization was another major transformation step. During the CI roadshow sessions the persons who had participated in building the first CI system presented the current situation of CI and the goals of CI to the other teams, as well as discussed current challenges in the area. Similar CI roadshow events were organized at three other major sites.

The first and second author conducted the observations as non-participants. During the breaks they discussed with the participants. The observers took detailed notes during the observation sessions on what happened, what was presented and discussed, who were present, and how the participants behaved. For confidentiality reasons, the observation sessions were not recorded, as during those sessions details of new product features were discussed. Such details were, naturally, highly confidential, and as a result we were not allowed to record the sessions. The information gathered during the observations was used to support and complement the interviews. Table  2 shows the details of the observations.

3.3.3 Documents

We received a number of documents from our interviewees, e.g., slides discussing the process, working practices, product and organization structure, as well as a fictional story called the “Showcase”, created by the agile coaches together with the management team to describe how this organization would look like in two years. These documents were used to triangulate and complement the information received in the interviews.

3.4 Data Analysis

We analyzed the data qualitatively, using the Atlas.ti software package. We coded the data in six main categories: four main themes according to our research questions, and two context categories, i.e. organization structure and case background. The research question-based themes were motivation for the transformation, phases of the transformation, transformation challenges, and mitigations and success factors. We then proceeded with detailed coding, resulting in 605 codes, such as Business flow definition , Daily Scrum , and Domain owner meeting participants . Following this, we grouped the detailed codes into a total of 58 code families, such as Development Practices , Coaching Community of Practice , and Cross-site teams . The qualitative coding of the transcriptions of the first interview round was done by one researcher (Author 2), while two researchers (Authors 1 and 3) instructed and closely followed the process discussing together daily. The second round interviews were coded by one researcher (Author 1).

3.5 Limitations and Validity

We discuss the validity of our research from four viewpoints: internal validity, construct validity, external validity and reliability (Yin 2009 ). The fourth type of validity, statistical conclusion validity, is not relevant to this study.

Internal validity concerns the validity of the causal relationships observed in the case (Yin 2009 ). As this is a descriptive case-study, we refrain from theory building, and the reported causal relationships represent the views of our subjects. The threat that this might not perfectly represent reality remains.

In case study research, construct validity concerns how well the description of the case represents reality. We interviewed people who were actively involved in the ongoing transformation. Therefore, it is likely that their views and recollections reflect reality as the events discussed were contemporary. However, there are always risks related to respondents’ bias due to personal opinions or social pressure. The construct validity of a case study can be increased by the triangulation of data sources, investigators, theories and methods (Jick 1979 ; Yin 2009 ). We used several types of triangulation: we collected data by several methods, from several subjects and by several researchers. First, as it is not recommended to conduct a case study by relying on a single data source (Yin 2009 ), we collected data by three different methods: interviews, observation, and document analysis. Second, we interviewed a large number of subjects in different roles, with varying backgrounds, from different sites, and with differing length of experience in the organization to get as broad representation as possible. Third, the data was collected by three researchers, who all conducted interviews and two participated in the observation sessions. 32 of 45 interviews were conducted by two interviewers and one observation session, a two-day value workshop was observed by two researchers. All three researchers participated in data analysis and writing. In the feedback session, we received no corrections to our findings. Of these, we employed the investigator, method and data source triangulation. Three different investigators collected and analyzed the data. We employed three data collection methods: observations, interviews and document collection. Our data sources included observation notes, interview transcripts, and company documents.

The external validity of research concerns the domain to which the research results are generalizable (Yin 2009 ). To help the reader to understand the contextual factors of the case organization, we have described the context in detail.

Reliability concerns whether different researchers had produced the same results if they had studied the same project (Yin 2009 ). The main threat to reliability in this case is the variability in data collection. We minimized this threat by involving several researchers in the interviews, and having the analysis results checked by both other researchers and company employees. This triangulation makes our results robust against threats to reliability (Jick 1979 ; Yin 2009 ). Most data collected converged between the investigators, methods and data sources and revealed no notable threats to the construct validity or reliability of our results.

After analyzing the data, we arranged a feedback session in March 2014 to validate our results. The feedback session took place in the site A team area with a videoconference connection to the other European sites: B, C, and D. The whole organization was invited to the session and around thirty people participated actively in the session. We received positive feedback: the organization had already started implementing some of the suggested improvements and would take into account our findings when planning the next improvement steps. No corrections to our findings were presented. Feedback we gave to the organization did not affect our results, as the session was organized after our main interview rounds and only one validation interview took place after the feedback session. Finally, the fourth author of this paper, a representative of the case organization commented on the final draft of this paper.

4.1 Motivation

In this section we answer our first research question, RQ1: Why did the organization initiate an agile transformation?

According to our informants, there were three main motivators for the transformation in the case organization: 1) Agile software development was becoming an important part of Ericsson’s corporate strategy, 2) a dissatisfaction with the current way of working, and 3) a need to enable rapid end-to-end flow of features and continuous deployment.

4.1.1 Agile as Part of the Corporate Strategy

At the corporate level, Ericsson had identified the need to be more agile, and had made the adoption of agile methods a strategic priority. Several successful agile transformations had already taken place in various units withing the company. However, each unit inside Ericsson was given the freedom to choose whether and how to adopt and apply agile. At site A, the biggest site of our case organization, a previous, still ongoing project, had started the transformation earlier (see (Paasivaara et al. 2013 )). A large group of people from that project were gradually transferred to the case organization, and to them, agile was already a natural way of working. Thus, given their exprience with agile, it became natural also for the case organization to start thinking about adopting agile.

4.1.2 Dissatisfaction with the Current Way of Working

After the product was acquired, the case organization started to implement Ericsson’s traditional, waterfall process framework, even though the first development teams did not use any well-defined development process. The early development teams were simply assigned new features with preassigned deadlines.The teams then implemented the features as they saw fit. Our interviewees reported that development was slightly chaotic at this time, but features were finished on time. The lack of a defined process was not considered a major problem, because there were only a couple of small teams working on the product, in addition to a group of external consultants.

However, as the organization started to grow in 2012, it became necessary to implement at least somewhat orderly process. The first step, in 2012, was to implement a component-team based model, which seemed natural, as the product was composed of several components, each requiring specialized technical knowledge. The component teams had members with deep expertise on their individual components. When developing features spanning several components, virtual feature teams were used. In these, specialists from different component teams collaborated on a specific feature. There were several issues with the component based structure: it was challenging to plan and coordinate work, as features depended on several components, and experts were not always available when needed; the work was not considered efficient; development lead-times were long; teams had difficulties in finishing promised features on time; and team members felt that this way of working was stressful and somewhat chaotic. The rapid organizational growth from around twenty persons to over one hundred exacerbated the situation. Thus, they felt that change was needed.

4.1.3 The Need to Enable Rapid End-to-end Flow and Continuous Deployment

At the time of our study, the product was released every eight weeks, the same rhythm as when it was acquired by Ericsson. However, this was considered too slow, and the goal of the organization was to transition towards continuous deployment. The idea was that anew feature could be taken as part of the product instantly when ready.

My dream is that we shouldn’t have releases at all, but that afeature goes to production right away when it is ready. It means that what we do here should include coding and verification in the team, as well as continuous integration and automatic regression tests so that we can trust that when they [the team] say it’s ready, we can just push it to the system.— Manager

Thus, the hope was that going agile would enable them to implement each feature in across-functional team as efficiently as possible, from requirement until delivered as part of the product. Moreover, by using agile practices, Ericsson aimed to optimize the whole end-to-end flow:

Our goal is that we can make this whole end-to-end chain work in anew way, to remove all waste, all unnecessary handovers, and [...] to optimize the whole flow, from customer requirement until deployment.— Manager

Optimized end-to-end development would help the organization to respond quickly to changing customer requirements, as well as to provide customers constant visibility on what is coming out next.

To achieve these goals, a wide spectrum of organizational improvement actions were undertaken, as described next.

4.2 Phases of the Transformation

In this section we answer our second research question, RQ2: How did the transformation proceed?

The overall approach to the transformation was experimental — based on their previous experience in transitioning another product program to agile, the managers had learned that it is impossible to plan the transition in detail and execute it with a “waterfall mindset”. Instead, the managers and coaches took an experimental approach, purposefully focusing on a single key change or improvement target at a time. This way, the main transformation steps were not planned beforehand, but were decided one at a time on a need basis. Thus, the phases we report below are the researchers’ construct that we present as a way of structuring the discussion rather than as a prescription for conducting agile transformations.

We discuss the transformation organized by three main phases: 1) introducing agile, 2) finding common ground through value workshops, and 3) towards continuous integration and deployment. In addition, we describe the situation before the transformation as Phase 0: knowledge transfer and component-based teams. The main phases, as well as some major events are presented in Fig.  4 . As illustrated in the Fig.  4 , the phases were somewhat parallel and most did not have clear ending dates. Next, we describe each phase in detail.

4.2.1 Phase 0: Knowledge Transfer and Component-Based Teams

Knowledge transfer from the original development organization, including external consultants, started soon after the acquisition. The first two teams were built in fall 2011. During winter 2011-2012, these teams worked partially collocated at site Dand partially as distributed teams, as part of the team members came from sites Aand B. However, during the most intensive knowledge transfer period, most members worked collocated at site Dfor longer periods. These first teams were working without any specific process. Instead, team members collaborated informally aided by “agile seating”, i.e. they shared asingle large table:

As Isee it, we had no process in the beginning that we would have been following... So no Agile processes, nor [any] traditional waterfall model.— Team Member

When growing the organization from the initial two teams, the idea was to hire experts with knowledge of specific system components. In particular, they intended to use internal recruiting as far as possible. As aresult, the experts were located at different Ericsson sites. In addition, aconsultancy company offering experts with specific domain knowledge was hired at site E. Even though the organization had started talking about agile already in late 2011, they decided to go for acomponent-based team structure in early 2012. The main reason for this was that each component required highly specialized knowledge and it was time-consuming to learn even asingle component.

You cannot really ask people to learn more than one component in two years. — Product Owner

Furthermore, Ericsson had a long history in using a waterfall type process. Thus, this initial organization structure was based on component teams and a sequential, waterfall type, process. Typically, a single component team comprised of 10–20 people, was distributed to multiple sites, and communicated through weekly or daily teleconferences.

Experts from these component teams were selected to virtual feature teams, as illustrated in Fig.  5 , whenever the development of a new feature would start. Virtual feature teams were loosely structured—team members performed their own feature-related tasks for their component, and then passed the work further. Usually, a new virtual team was established for every feature.

Virtual feature team

This component-based organization structure had several challenges, e.g., suitable resources for anew feature were not always available, and virtual feature team members simply performed their own tasks individually, and did not actually work together as ateam.

Setting up the virtual teams was challenging because we had the feature and then we found three guys [with competence A] but we don’t have [competence B] because they’re all busy with other features. So here we have the resources [with competence A] available but then we cannot wait for three weeks, so the guys start with something else. So it’s like apuzzle all the time.— Manager

Furthermore, the team members considered it challenging to work in virtual teams. The people you were supposed to collaborate with changed constantly and it took time to make the acquaintance of new people, hindering the development of trust and slowing down team building. The interviewed team members reported that at that time they identified themselves more with the component teams, rather than with the constantly changing virtual feature teams.

As a whole, the organization structure based on component teams and virtual feature teams created on top of them was seen as too rigid and not being able to answer market requirements fast enough. It was not efficient nor predictable enough.

4.2.2 Phase 1: Introducing Agile

When the organization decided to move to Agile software development, the idea of creating cross-functional, cross-component teams was born. Here, we focus on the organization and team structure while moving to agile, as it turned out to be both important and challenging. The structure was tested and modified several times.

At the team level agile, teams were given the freedom to themselves decide the practical agile implementation, guided by the coaches. Thus, no common agile framework was prescribed or used.

The organization structure evolved into the current agile team structure through four phases:

Building a pilot cross-functional agile team

Full-scale roll-out of cross-component, cross-functional agile teams

Creating a competence pool providing team members to cross-component teams according to the needs of each feature

Cross-component, cross-functional teams specializing on specific business flows

The first pilot team was created in early spring 2013 to evaluate the new concept. This team was formed of volunteers from two sites, who had an avid interest in adapting agile ways of working. According to our interviewees this team both collaborated remarkably well, using the agile practices and achieved good development results. However, one problem was that some of these volunteers had a central role in their previous component team, and their absence affected the work of those teams. Therefore, management decided to dismantle the pilot team after a few weeks and start a full-scale agile rollout with cross-component, cross-functional teams.

Full-scale Roll-out:

All European sites were involved in forming the teams. Line management set the frames for the new teams, and the coaches worked on developing guidelines. Team formation was discussed in several videoconference sessions involving the future team members. Based on these discussions, the teams were formed so that in Country Alpha the teams were either site-specific (in site A) or distributed within the country to be able to allocate experts on one specific component located at one of the sites (site B) to different teams. The other set of teams were created between Countries Beta and Delta to mix in highly experienced product architects and technical coaches from sites C and D (usually two persons from sites C and D per team) with experts on third party components from an external consultancy company at site E (around ten persons from site E per team). Altogether 10 teams were created.

Competence Pool:

However, this setup between Countries Beta and Delta had to be slightly adjusted as the optimal mixture of knowledge on different components depended highly on the specific feature to be developed. All features did not involve all components, thus how much knowledge on each component was needed in a team depended on the feature. Moreover, consultants had quite narrow focus areas, and the case organization did not see having them broaden their knowledge on other components as cost-efficient due to high attrition rate at the consultant company. Thus, the five quite large teams between Countries Beta and Delta were rearranged into four smaller teams of 7–9 core team members, while the rest of the consultants at site E formed a competence pool, from which suitable resources were chosen to teams according to the needs of the next feature, as illustrated in Fig.  6 . Teams at the other sites (sites A and B) remained the same.

Cross-component teams (between countries Beta and Delta) with a competence pool. People at site E who are not allocated to teams form the competence pool (19 persons)

The permanent cross-component teams were complemented with component-based Communities of Practices (CoPs). CoPs are groups of experts who share a common interest or topic and collectively want to deepen their knowledge (Wenger et al. 2000 ; 2002 ). In the case organization, the CoPs were open to anybody interested in the topic. The CoP culture was also dynamic. New CoPs were founded when an active individual took the initiative. When a CoP was not needed anymore, or had difficulty attracting participants, it ceased to exist. Most CoPs met on a regular basis, as well as had discussion forums, wiki pages etc. for communication. The usage of CoPs at Ericsson is described in more detail in (Paasivaara and Lassenius 2014 ). In the Component CoPs, the experts for different components collaborated across teams inside each component. Forming the CoPs was easy, as they consisted mainly of members from former component teams. Thus, most members had previously collaborated closely. The daily or weekly component meetings were replaced by weekly Component CoP virtual meetings. Most CoPs started to function well with the help of the coaches. The biggest problem was how to transfer the component-specific improvement items, e.g., refactoring, agreed in CoP meetings, to the team backlogs. In addition to Component CoPs, other CoPs on specific topics were formed, e.g., a CI CoP and a Coaching CoP.

While forming the permanent cross-component teams during the spring and summer of 2013, the organization was both hiring new team members externally and adding whole teams by moving them from another, still on-going project that had been using Agile for several years at site A. Thus, the number of teams grew quickly during this phase: from 10 teams in spring 2013 to 15 in fall 2013.

Specialization in Business Flows:

In the beginning of the transformation, the goal had been to create teams that would be both cross-component and cross-functional, and that any team would be able to implement any feature that happens to be at the top of the backlog. However, the organization soon learned that this would never work in practice.

The product included alarge number of components, many of them developed using different technologies, and each component required deep technical knowledge. To solve this problem, the case organization created teams specializing in use cases spanning several components, or business flows as they called them, with afew teams working in each business flow. This would not require the members to have deep knowledge on all the components of the product. Within the business flows each team could implement end-to-end functionality, from requirement to deployment. The most important of these were Service Exposure, SIM Footnote 3 and subscription management, Billing and Rating Services and Connectivity Services. This was the structure when our study ended. The features developed within these business flows were mainly done by one team each, however regarding big features several teams could collaborate. The size of the features varied from small ones that one team could implement in aweek to bigger ones that could take half ayear to develop. Before being called business flows, some managers referred to them as domains:

We have broken down the system into domains [business flows] now, different areas. The idea is to have aPO [Product Owner] for the domain, and this is also the product manager for the domain...and maybe the backlog should be for that domain only...It is five functional domains, and one cross-functional one.— Manager

4.2.3 Phase 2: Finding Common Ground Through Value Workshops

The development organization grew quickly from 10 (spring 2013) to 15 teams (fall 2013), while introducing agile development at the team level. Even though the goal had been to form predominantly site-specific teams, due to the knowledge differences between the sites, approximately half of the teams ended up as cross-site teams. There were lots of people who had never met. In addition, people at one site did not necessarily know what was happening at the other sites regarding the development and the transformation. There were clear borders between the sites:

I see site politics as one of the problems. It’s difficult to communicate between the sites. So we build up some kind of, us vs. them feelings. That hinders our way of working. We don’t have aperfect flow in the system. Because we don’t really trust each other. And that’s aproblem.— Coach

Moreover, management noticed that the organization lacked acommon direction, regarding both the future direction of the product, as well as the way of working, and there were site-based and history-based opposing views. Thus, management and coaches decided that the next step in the transformation journey would be to define acommon direction and build a“we spirit” to help people identify themselves with the single product organization rather than with their competing sites.

Why we have started with values, [...] is that we would have acommon baseline to continue further, [...] abaseline on which we build this common understanding and common direction. That we have something common to discuss together. Ihave seen as aproblem in this whole project that different sites and different people have taken abit different direction.— Manager

The work on the common organizational values started in early 2013. The first step was the Futurospective , a workshop where the agile coaches and managers created a vision for the organization a couple of years ahead. Based on the results of the Futurospective, the coaches wrote a Showcase , a fictional story of how the organization would look like and how it would work in two years time, after tight collaboration and joint creation of a success story. The idea of the values was born during a workshop on how to make the organization “more agile”. Thus, the values were based on the one hand on the ideas and principles of agile, and on the other hand on the three core values of whole Ericsson: professionalism, respect, and perseverance. The five core values were created in collaboration between the coaches, the management team and a few developers, and are: One organization , Step-by-step , Customer collaboration , Passion to win , and Fun .

To share the values with the whole organization, a series of Value Workshops were organized during winter 2013–2014.

The goal of the value workshops was twofold: 1) to create a common vision for the whole organization in the form of common values, and 2) to create contacts and collaboration, as well as building a “we” spirit across the sites by having people meet face-to-face.

The value workshops were held as two 2-day workshops at the biggest development sites, A and D, with around 20 people traveling from three other European development sites. The whole management team, all coaches, as well as a few team members traveled. The only site that did not have workshop participants was site E, the consultant firm, with the exception of a few consultants who were working on the sites where the workshops were arranged. The aim was that all team members from sites A, B, C and D would participate in one of the workshops, as well as meet all managers and coaches face-to-face. The results from the first value workshop organized at site A was shared with the other sites by having a videoconference call during the result presentations between the sites A, C, and D (site B participants were at site A already).

Besides meeting face-to-face, the goal of the value workshops was to jointly discuss and elaborate the values. Purposefully, the values were not defined beforehand, but the managers and coaches presented the values in both workshops using examples. What each value really means were discussed in small groups. In Table  3 , we have collected some examples of what these values could mean based on the Showcase, examples provided and the value workshop discussions.

The workshops included different kind of group activities and exercises: within the whole group, within individual cross-functional teams, as well as in highly mixed teams with people from different roles and from different sites. For example, in one exercise, the teams considered what the values would mean in practice in that specific team, and what kind of concrete behaviors they would lead to. The coaches from different sites planned and facilitated these workshops as a collective effort. For more detailed description of the activities during the value workshops see (Paasivaara et al. 2014b ).

The first impression of the value workshops was highly positive. In particular, participants felt that the organization took ahuge step closer to the goal of being asingle organization building acommon product. Especially, meeting with people from other sites and talking face-to-face was abenefit that all interviewed participants mentioned.

The value this event brings, that Isee, is that we are no longer just names and faces behind the screen. You see real people and talk to real people.— Team Member

Regarding the values, most workshop participants seemed to feel that the chosen values were good:

I completely agree with these values. [...] [the values are] not so easy as before to forget, or ignore in the daily work, Ithink that’s the main benefit of the workshop. — Team Member

Several interviewees agreed that they would personally act differently in the future and that the events had clarified the values and made them meaningful.

I will probably do alot of things differently. [...] I’m gonna try to collaborate more, between the teams. Because Ithink that’s one of the biggest flaws we have right now. — Team Member

Some participants worried that the values would be forgotten after the events, expressing that good intentions formed during the workshops are not enough to implement the values in the normal working environment. The plan to tackle this was to have the coaches help the teams work towards the common values and exhibit the behaviors they had planned. Many of our interviewees also suggested some kind of acommon follow up for these events after half ayear or so.

I would say afollow-up in maybe six months or something like that, just to have arecap of what has changed, what has happened, what Ihave done. Just akind of retrospective, just to see what is happening and what kind of next steps we can take. [...] All sites should be involved with that follow-up, [...] because we should fight for this one [name of the product].— Team Member

Even though the values were considered good and the workshops beneficial by all of the interviewed participants, some were still hoping to have an even more concrete vision than what the values and the showcase provided. Especially, a concrete product vision or roadmap was asked for. However, that was not a goal of these workshops this time.

4.2.4 Phase 3: Towards Continuous Integration and Deployment

The lack of continuous integration (CI) and test automation were major challenges on the way towards continuous deployment, as the integration and testing phase took several weeks before each release. The goal was to get rid of the integration and testing phase, and having the teams integrate and verify the system functionality immediately.

I think [that] the goal is that we should be able to...when something is ready...it should...pass through and be deployed directly into production. If we can deploy something...maybe the first user (story), Imean not acomplete thing and deploy it and test it with akey customer.— Manager

The work towards this goal started in fall 2013 by creating three new teams concentrating on implementing CI and test automation. Most team members came from another product developed by the same organization, and in which agile methods had been in use for several years. In that product CI and test automation had been a major and extremely successful effort. Thus, the teams had ample relevant knowledge and experience.

A future goal was to spread the CI knowledge, goals and mindset to the whole organization: from teams up to the management by Continuous Integration Road Shows arranged during spring 2014. These consisted of information events and trainings for the whole personnel, e.g., on the selected test framework.

One of the Lean principles (Poppendieck and Cusumano 2012 ), optimizing the whole, is behind the goal of end-to-end development. In this case, end-to-end development meant developing system functionality from a customer requirement to new functionality being part of the product and used by the customer. One way to shorten the lead time of end-to-end development is to develop each functionality in a single team. This removes extra handovers and non-value adding waiting. CI and automated testing aims to optimize the last part of the end-to-end flow before the release.

Another action the case organization took to optimize the flow was to involve the teams in the early phases, i.e., in planning and design. The idea was that the teams would themselves conduct initial studies on new features: Feature Investigations (FI) and Feature Concept Studies (FCS). The purpose of these studies was to quickly investigate whether a feature is doable, how much effort it might require and how it could be implemented. Previously, experts such as architects had conducted the studies during the planning phase of the waterfall model. However, now the aim was to perform less profound studies quickly whenever new feature requirements appeared. The expected benefits were threefold. First, as the studies are not that profound, quick feedback can be received. Second, when teams are involved they learn more about the features, thus speeding up implementation since no extra handovers or documentation are needed. Third, as the number of experts doing these studies was limited, reducing their work with FIs and FCSs would free them up to focus on more profound issues. At the time of our research, the studies were already assigned to the teams. However, in-team experts, e.g., architects or subsystem responsibles, normally took the main responsibility for conducting the studies.

At the end of our study period, the organization had six releases per year but the goal was that the teams would be able to deploy new features into production immediately when they are finalized.

4.3 Challenges and Mitigations

In this section we answer the last two research questions, RQ3: What challenges did the organization encounter? and RQ4: How did the organization mitigate the challenges?

Overall, our interviewees considered this agile transformation very successful: they had taken major steps towards their target—a unified agile organization having the capacity to deliver value continuously. However, the journey had not been without problems. Next, we discuss the major challenges encountered (see Table  4 ), as well as how the organization attempted to solve them. All challenges were not yet resolved by the end of our study period, however, the transformation journey continues as the organization continuously attempts to solve new challenges as they emerge and continuously improve their way of working, following their experimental approach to the transformation.

4.3.1 Change Resistance

The first initial attempts to start the transformation were in 2012, but they did not lead anywhere as the issue polarized the organization. Some did not want to change the way of working at all, and those willing to change had different views on how the transformation should be conducted. Initially, the leadership team was not willing to sacrifice deliveries in order to support the transition. Several leadership team members found it more important to deliver new features than to focus on amajor organizational change.

The top operative management was located in [site C], and they hadn’t adopted the Agile philosophy. There was so much resistance that it was absolutely impossible to drive the change from bottom up.— Team member

During summer and fall 2013, the leadership team was reorganized, and new members having previous experience in agile transitions and strongly supporting the transformation were added. After this change, the transformation was rolled out full-scale, with less resistance.

However, at the time of the interviews, there were still groups of people in the organization, who had not yet adopted agile thinking. For example, the product management had still aquite plan-driven mindset, as illustrated by the following quote:

In product management there’s still some belief that aplan is the truth and trying to fulfill that is agood thing.— Coach

The evidence related to change resistance was strong in both the sense that it was mentioned and discussed in depth by many respondents, as illustrated in the quotes above, as well as in the fact that it was the explicit reason for changing the membership of the leadership team.

4.3.2 Significant Technical Debt

One bottleneck that prevented the transformation was a high degree of technical debt in the system. Technical debt is a metaphor originally referring to “not quite right code which we postpone making it right” (Cunningham 1992 ) but that since has expanded to include a spectrum of issues from bad coding to architectural issues (Kruchten et al. 2012 )

The system was originally designed for a single customer. Additionally, the development in the previous organization had occurred within strict deadlines. Together, these two factors had resulted in a situation where lots of shortcuts had been taken in development, and the system was not stable enough to be scaled up for a larger pool of users. Improvements had to be made before new features could reasonably be implemented. Moreover, in the beginning, when working in component teams, adding new features had the highest priority, while the quality of the underlying system suffered. That happened partly because the overall architecture was not well understood by the new developers. All this led to increasing technical debt.

During 2012, many system improvements took place and a few components were replaced by Ericsson’s own components.

Furthermore, when working in component teams, management used to make the feature implementation decisions according to ever changing customer requirements. Feature prioritization could change constantly, causing major challenges in design, coding and testing. However, this was improved after establishing a common backlog and assigning subsystem responsibles and architects to the development teams.

The technical debt was a pervasive issue that despite its importance was raised only by few technical experts. However, the importance of dealing with it was reflected in the urgency of getting a working CI system in place to harness the product, and the fact that it required serious architectural changes to the components.

4.3.3 Lack of a Common Agile Framework

The organization had decided not to use any common agile framework guiding the teams’ day-to-day working practices. Instead, each team could itself decide how to work. The only commonalities between the teams were the common bi-weekly demos, coaches, and the use of Jira as a backlog management tool. In the common demo, usually one team demonstrated their achievements. This demo was open for everyone in the organization and it was organized as a video/audio-conference between the sites. The teams having finished something of interest to others would give a demo. Some Scrum trainings were arranged in the beginning, but participation was voluntary, thus not all participated. Some teams and team members had already agile experience from their previous project, some not. Thus, taking agile into use at the team level was not systematically organized.

Many interviewees expressed that starting with acommon agile framework that teams could later on tailor to their needs would have been preferable, as that was how it was done for example in another still on-going agile project at site A, from where many managers, coaches, and team members had been moved to this project. Several interviewees commented that having acommon framework, like in that previous project, would have been abetter solution to this project as well.

I think it’s good to start with acommon [framework], like start with Scrum or anything. That’s where you start, and everybody has to go through that or whatever and then you can go from that. But now it’s really difficult. [...] We have to really go back to [the basics] so it’s really difficult to do coaching or advice because we are, Idon’t know where we are. Iagree it’s kind of aproblem.— Coach

Many interviewees from teams even commented that their team had some agile practices in use, but not aspecific process to follow. For example, most teams did not use sprints and many teams did not have regular retrospectives or planning meetings. At the time of our study, each team had their own ways of working, often combining Scrum and Kanban, e.g., all teams had aScrum or Kanban board to visualize their workflow.

I came from acompany where we followed Scrum exactly, but here Ifeel that we are doing things, but we have no process to follow.— Team Member

I think Scrum is avery good start, and when you know Scrum then you can shift into other stuff. My feeling here is that we are kind of trying to take ashort cut and doing other stuff immediately, so some of these ground pieces are actually missing in quite many teams.— Coach

A few interviewees suggested having acommon pulse for the organization:

I think we need apulse in [name of the project]. We should have, like, every second week we could have acommon planning, acommon retrospective, and Ireally miss that. [...] It’s actually on our [Coaches’] Kanban board to start up this pulse, this heartbeat.— Coach

Some sort of timeboxing could help to push us to work harder and to help us to prioritize our work so that it is done in the right order.— Team Member

The common demo every second week was a start for this pulse and our interviewees found it useful. However, they did not consider this sufficient.

A few interviewees explained that one reason for not starting with acommon agile framework was, surprisingly, due to that above mentioned still on-going agile project at site A. This other project had started their agile transformation afew years back with strict Scrum that they later modified towards Scrumban and gave the teams alot of freedom to choose their ways of working. As part of the personnel from that project had moved to the case project, some interviewees suspected that the managers and coaches moving from that project did not consider it necessary to go back and start with acommon Scrum framework and Scrum trainings, as they had done that and were “past that phase”. They explained that the persons probably assumed that the rest of this project would be as mature in agile as their old one, making it possible to directly apply the same kind of practices and thinking.

So they probably tried to short-cut this path through Scrum. So they kind of tried to start where the old organization was.— Coach

However, in practice this was not possible, as a large part of the personnel in this new project was new to agile or had little familiarity with agile, and thus needed basic training and a framework to start with, before they could start modifying it. Interviewed developers that had moved from that other project to the case project, found having a common agile framework with common Scrum trainings a much better way of starting the transformation than giving quite free hands to the teams.

As the new organization was composed of persons from several internal organizations and sites, none of the groups actually wanted to say that “this is the way we should work”. Instead, they tried to come to a joint understanding and a way of working. However, achieving such an understanding takes time. Actually, the managers and coaches coming from that other on-going agile project at site A explained to us that they did not want to “push” too much the ways of working in their previous project, as in the beginning they had done that, but the other sites clearly did not like it, but instead always answered in style “but this is a totally different kind of product”. Thus, instead of following the good practices from the previous project, they decided to find together a common way of working for this project.

A major step towards this goal was the creation of across-site Coaching Community of Practice (CoP). Having aCoaching CoP that meets regularly aims at helping coaches to establish acommon way of coaching and to guide the teams to work in similar ways across the sites. This would be helpful also for people changing teams, e.g., the floating resources in the competence pool.

I think that’s [Coaching CoP] really important. And it must be cross-site, so that we can coach in the same direction, at the same time and have the same view on coaching and the ways of working. So, instead of going into control mode we should coach in the same way. And say the same things about what’s good and bad.— Coach

The evidence regarding the problems related to the lack of a common agile framework came from a few respondents, who had participated in an earlier agile transformation within Ericsson. While small in the number of respondents, their insights were deep, and they discussed the issue at depth in our interviews. They very strongly recommended that a common framework should be used instead of giving teams too much autonomy too soon.

4.3.4 Lack of Coaching and Coaches

At the time of our interviews, the organization had both team and organization level coaches. Approximately athird of the teams had their own team coaches. The organizational coaches supported the rest of the teams, each having several teams to coach. However, they were also responsible for helping with agile issues at the organizational level and developing the whole organization and its way of working further. Thus, the coaches lacked time to concentrate on helping individual teams. For example, they could not always participate in their teams’ daily meetings or retrospectives. The interviewees found coaching they had received extremely useful, but thought that the number of coaches was not sufficient.

Last week the coach participated in our daily meetings only once. And during the previous week maybe twice. [The coach] wasn’t involved in other things. — Team Member

Currently we have so many teams and there’s only afew of us, so we are not able to support teams very well.— Coach

During our study period, the organization slightly increased the number of both organizational and team coaches. As the number of teams grew at the same time, the situation improved only slightly.

The data related to the lack of coaching and coaches came from a few coaches and a few team members, and is not as strong as for the previous categories. While coaching is important, the lack of it did not seem to be one of the most important challenges in this case, as coaches were available.

4.3.5 Lack of Agile Training

The agile knowledge was not yet at a sufficient level despite the fact that the organization had experienced people with knowledge on agile methods. The level of agile knowledge varied a lot from person to person, as some had used agile in their previous organizations while some had never used agile. Even though a few agile trainings had been organized, not all employees had participated in these, as participation had been voluntary and they had prioritized other tasks. The knowledge of agile experts was not spreading as well as it could have been.

A few interviewees even mentioned that the basic terms, such as feature , story or definition of done were not known or understood similarly by all, which is abasic requirement for working together in an agile way.

Sometimes Isend out mail or call people and discuss these, what Ifeel is basics. And then, for example, Italked to somebody about definition of done. But then, yeah they kind of agreed some of them, but acouple days later you get back some questions, “What is the definition of done?”. And then you realize, okay. We have to really go back to, so it’s really difficult to do coaching or advice because Idon’t know where we are. Iagree, it’s kind of aproblem.— Coach

The organization had plans to arrange trainings on a need basis. Moreover, the collaboration of coaches across sites and unifying the coaching would in time increase the agile knowledge in the teams.

The evidence related to the lack of agile training came from a few respondents, in particular coaches. Many people in the organization had already earlier received agile training, but the coaches noted clear differences in the knowledge, e.g. across site borders. While the data supports the importance of agile training, the lack of it was not one of the main concerns in the organization.

4.3.6 Cross-Site Teams

Even though one of the principles when forming the cross-component agile teams was to build site-specific teams, ca 50% of the teams were distributed between two or three sites at the end of our study period. Many interviewees commented that this was not agood solution for high quality team work. However, due to knowledge asymmetries between the sites this structure was deemed necessary.

Q: Do you feel that you are really ateam? A: No, Idon’t. Iam ateam player and Ilike working in teams, but Idon’t feel that we have ateam spirit. And, Iguess it’s hard, when you have multiple sites. As long as you don’t know the people, you can’t possibly care for them either.— Team member

It would be nice if we could work with local teams, if we didn’t have any dependencies, for example. [...] But we do have dependencies between each other, so in that case it’s better to have distributed teams, even though it is less efficient on the team level.— Coach

This distribution was mitigated by site visits, e.g., single team members located at site B visited the rest of their team at the site A at least once a week. From site E, there were visiting engineers constantly working with teams at sites A and D, as the “eyes and ears” of the site E.

Moreover, high quality videoconference equipment was used between sites A, B, C and D for most meetings. The videoconference connection between the distributed team members at sites A and B, was mentioned to be open sometimes all day to enable ad-hoc communication. Unfortunately, site E, a consultancy company, did not have compatible videoconference equipment. Thus, personnel at that site usually participated in using only audioconferencing.

Many interviewees emphasized that the team members should travel even more, and that they should arrange exchange visits and work co-located, at least for short periods.

We don’t talk to each other that much. So you do not trust each other. If you don’t know somebody, it’s difficult to trust them. [...] My solution is to travel more. To actually see each other. The teams [should travel]. The ones who really should cooperate. [...] Once you have met each other and worked together for awhile, then it’s much easier. And that sticks for awhile.— Coach

One goal of the value workshops was to increase trust, and make people know each other to lower the threshold for contacting. However, most cross-site teams spanned sites E and C and/or D, and as team members from site E, the consultancy company, did not travel to the workshops, they did not help with building team cohesion as much as they could have.

The use of cross-site teams with members from organizations that had not been tightly integrated before arose as one of the major problems in the case project. It was mentioned by most respondents, and also was the reason for arranging the value workshops.

4.3.7 Working as “A Real Team”

All cross-component teams had experts from several components. As each expert had deep knowledge on his or her component only, some of the interviewed team members felt that all teams were not yet working as “real teams”. The global distribution of many teams made this even worse.

Q: You said that you do your tasks mainly all alone so, what do you do with the other team members? A: Idon’t do anything with them. Idon’t work... Q: So you don’t have any collaboration? A: Sometimes they come with questions, and Itry to answer.— Team member

Due to the deep technical knowledge required team members could not really collaborate, e.g., help other team members working with other components when done with their own tasks. Thus, at times some team members had a too high workload, while others might not have work at all. During one of the value workshops, one team member worked on a task, while the rest of the team participated in the workshop. The team members explained that this individual was doing a critical task that no-one else from the team had knowledge of and thus could not help with. They explained that otherwise the whole team would be solving the problem together instead of participating in the workshop.

One of the goals the organization had was to broaden team member’s knowledge on other components, e.g., by working as a pair with an expert of another component in the own team. The goal was to add collaboration between the teams, e.g., pairing teams, so that they could learn from each other. Moreover, an exchange program across the sites was suggested to enable team members and teams from different sites to learn from each other. Exchanges were going on at the time of our study, even though it was not systematic.

Many components were quite complex, requiring significant effort to learn. This learning was not structured or organized, leaving it mainly to individuals to organize their familiarization.

Teams distributed between sites C, D and E had a couple of very experienced members, e.g., subsystem responsibles, sub-system architects or technical coaches from sites C and D, while the rest of the team was located at site E. As site E was located in Asia, and sites C and D in Europe, there were significant cultural differences between the sites. At the time of this study the technical coaches had taken the role of team leaders and the rest of the team performed individual tasks. These teams seemed to have a long way to go before turning into real agile teams.

The problem related to part of the teams not being “real” teams was mentioned in particular by coaches and line managers, working with teams with members on site E. This can be explained by the fact that we did not interview team members at site E (the consultancy company). The significance of the problem was evidenced by the fact that the organization actively planned for how to make the project succeed without site E.

4.3.8 Any Team Cannot Implement any Feature

The initial goal was to have fully cross-functional and cross-component teams that could implement any feature from the top of the backlog. However, the organization realized that this might never work in practice, as the different components required very specialized knowledge that would take long time to learn.

For at least half ayear ago they said that one team should be able to do any feature, end-to-end. That’s impossible. [...] Idon’t think we will ever get one team who can do end-to-end of all features.— Coach

It’s proved that it’s almost impossible to have across-functional team that could do any features. We don’t have asituation where developers would have competences of many components, and that’s why it’s easier for teams to focus on aspecific area. — Product Owner

We work alot with third-party products. And Icannot possibly help someone else working on another platform. And the other way around. They can’t help me, so there’s not really any point in having cross-functional teams in that sense. — Team member

Thus, the initial idea of fully cross-component and cross-functional teams was discarded, as it was not seen reasonable that any single team could be able to implement just any feature from the backlog, not even after some time of working and broadening the knowledge. At the end of our study period teams started to focus on specific business flows, which would not require knowledge on all the components of the product, but only from a few. Within these business flows, teams would still be cross-functional and able to develop end-to-end features.

The fact that the agile ideal of any team being able to implement any feature was impossible to meet in this project turned out to be one of the main problems, which explains many of the organizational changes done. The evidence for this is strong both as it came up in many interviews, and in the visible actions taken trying to deal with it. Indeed, it can be considered one of the main findings of our study that there can be cases in which trying to meet this agile ideal might not be feasible.

4.3.9 Lack of Continuous Integration and Test Automation

At the time of our first interviews, most of the testing was still manual, as appropriate CI and test automation systems had not been implemented. Therefore, the development teams had only three to four weeks for implementing new features until the code freeze, when the integration and verification team would start testing it. The testing phase took three to four weeks, after which it took approximately three weeks until the system could be released.

One thing that is in heat, that is due to that we don’t have this CI and the setup. We’re living in this waterfall mechanism so four weeks before we go into deployment, then we’re more or less locking the code, the mainstream.— Manager

As the organization was building CI and test automation, this challenge would be mitigated. However, the initial effort to build the systems had required a huge effort: three teams focusing on it for several months. The next major effort, Continuous Integration Road Shows for the whole organization took place at the end of our study period. The aim of this effort was to train the personnel in CI practices, as well as build a CI mindset in the whole development organization.

The lack of continuous integration and test automation was mentioned in particular by managers and coaches, as well as the active team members. The organization viewed the existence of a strong CI pipeline as a major facilitator of agile, and its importance can also be seen in the resources dedicated to building it, as well as in the actions taken to spread the understanding.

4.3.10 Agile Teams in a Waterfall Organization

A few interviewees commented that the most of the organization was still in awaterfall mode—only the development teams were agile: product management, release management and integration and release testing were seen as working in awaterfall mode.

We have teams that try to work in agile, but the rest of the organization is not that agile. We have this, release management, Idon’t see this as an agile setup actually. — Manager

We still have too much waste. We’re still doing waterfall. We have different phases, we have to have PowerPoint slides, we have different checkpoints and meetings, before we can move on.— Team Member

Product line management is still quite strongly in the waterfall world, that everything should be planned beforehand, and they expect that the feature they ordered will come out as such.— Manager

This was quite true, as the organization had only recently started to involve teams in the early planning activities and the integration and release verification activities took a long time at the end of each release cycle. The organization had recognized this challenge, and actions to remove the rest of the waterfall had already been taken, e.g., building the CI and automated testing systems, and involving teams in the early planning activities: feature investigation and feature concept studies.

The challenges related to product management not being agile, and the need to have teams involved more in the upfront activities were mentioned mainly by managers and a few enlightened team members. Actions to solve these problems were in the early phases, and this did not strike us as one of the main problems in the project. On the other hand, people strongly commented on the need to reduce the release verification time, and as far as possible integrate that activity in the development cycle.

4.3.11 Challenges in Defining the Product Owner Role

Defining the Product Owner (PO) role has not been straightforward. During our first interviews POs were not responsible of the backlog, nor did they participate in backlog prioritization. Instead, the product line organization took care of that.

We have aseparate prioritization meeting where it (backlog) is prioritized. [...] And I’m not sure who are participating in that, but [the] POs aren’t there. — Product Owner

Moreover, afew interviewees complained that the POs did not know enough about the new features to be able to answer the team member’s questions. Instead, they were more like messengers.

It is pretty hard to explain [the role of aPO], but we have had aportfolio manager on one site, who has been sitting on the backlog and is responsible of it. But on the other hand, we have this kind of PO function. And these POs have been more like technical coordinators and messengers of the product management, so they have not been able to do independent prioritization decisions.— Developer

The situation improved during our study period, when a new PO team, called the PO Cloud was established. The PO Cloud comprised all POs, a portfolio manager, a test manager, and a user experience lead. The PO Cloud has an end-to-end understanding of the system, making it possible to develop clear functional requirements for the teams based upon a deep understanding of the business requirements from the customers’ point of view. Moreover, a workshop was arranged in which the responsibilities of the POs and the product management organization were clarified.

In addition to the PO role, there were many other roles, partly overlapping with the PO role, such as sub-system responsibles and sub-system architects. To our interviewees it was not clear what the responsibilities of these different roles were. Even persons holding these roles complained that the roles and responsibilities were not clear.

We have way too many overlapping roles, we have architects, POs, portfolio management and others. [...] There’s too much discussion that’s preventing us to get forward. — Developer

Even though Scrum does not recognize an architect role, the rapidly growing organization with a complicated product considered it important to have persons responsible for the sub-systems and their architecture. At the time of our interviews, these persons were located in the teams, and some sub-system responsibles and sub-system architects took care of the team coach role, as well. At the end of our study period, there was on-going discussion, on how to clarify the PO and architecture roles, as well as the responsibilities of these roles in the new team structure based on business flows.

The evidence related to the Product Owner role problems came in particular from the Product Owners, sub-system architects and the sub-system responsibles, i.e., the people who felt that their roles and responsibilities were unclear. The issue was addressed during the study, indicating the importance of having well-defined and understood roles.

4.3.12 Challenges in Breaking Down the Requirements

The organization was still learning how to break down the requirements small enough to implement within one release by one or acouple of teams. At the time of our interviews, most features still took over one release to implement. Starting abig feature, that would require over one release cycle to implement was challenging according to our interviewees, as that team or teams would no contribute to the next release.

We have been struggling when we have something that is very big and we can see that this is not fitting into our next release. Then it’s too big to start and then it’s difficult to start.— Manager

The organization had started a discussion on minimum marketable features, but this idea had not yet been implemented in practice.

At the team level the interviewees found it challenging to split the features into user stories small enough to be implemented in atwo week sprint.

The ability to chew it [feature] into smaller subareas, so that we could do something visible in two weeks is still quite bad.— Manager

Now they [user stories] are huge to implement. Iwish they could be smaller, so that they could be implemented during one sprint, preferably even afew stories [per sprint].— Team Member

Moreover, as different team members still had quite specialized knowledge, the teams often had to start several stories at the same time so that each team member would have work that would fit his or her competences. This indicates that teams worked hard on optimizing resource usage, i.e. minimizing developer downtime rather than optimizing the flow.

While maybe conceptually a serious problem, the fact that the organization was unable to create user stories small enough to be finished in a single sprint did not seem to cause many problems. Interestingly, it seemed rather to be a minor nuisance that would be nice to solve than a major issue. Except for thinking about the concept of a minimum viable product (MVP), no clear actions were taken related to this issue.

4.3.13 Backlog Challenges

A common backlog was considered as one of the most important improvement targets. Thus, it was one of the first improvement actions taken. It was expected to support the new agile way of working, to help streamline the end-to-end flow, to improve visibility and to help to define the lead time of new requirements.

Earlier, several different backlogs had been in use: an electronic backlog management tool was used for issue tracking, and different stakeholders had their own spreadsheets for managing requirements, features and improvements. This led to poor transparency, and made it impossible to define the cycle time of a single requirement and to see the whole end-to-end flow.

Building a common backlog started in early 2013 and was finished in summer 2013. At the time of the interviews, every new feature and improvement was to be added to this single backlog. The common backlog was for high-level features and improvements. Each team had their own backlog where chosen features and improvements were split into user stories.

Our interviewees expressed favorable opinions about the common backlog:

The good thing is that we have acommon backlog.— Manager

However, some challenges were seen, as well. The common backlog was big, i.e., it had alot of items. In addition, the original idea that any team could pick the next item from the top of the backlog was not seen feasible.

I don’t like this common backlog because it’s just abin of ahuge amount of features and improvements. [...] Ithink they have cut it down to 200 (features) now. So they have to wait afew years to get it out.— Manager

We actually had problems as someone says that we have acommon backlog, but when ateam starts going through the first items of it, they couldn’t understand anything. They simply don’t have the right competences. An item they were able to do was about the twentieth on the list and they were told that they aren’t allowed to do that yet. — Product Owner

As mentioned, the reason for this difficulty was the lack of often very specialized knowledge needed to implement a specific backlog item. To help solve this, teams were starting to specialize in specific business flows, and the idea was to have business flow based backlogs, and each business flow having a few teams.

4.3.14 Constant Change

The journey towards agile had been challenging and stressful for everyone as avast number of changes had been implemented, while working under high pressure from the customers who continuously expected and demanded new features. The product structure, team structures and the process had been changed in parallel with the rapid organizational growth. Moreover, the development organization was globally distributed to five sites.

From my point of view, we’re currently shooting at amoving target, constantly ... It means that, we try to, or someone changes the organization, in order for it to work better, in alean and agile way. And after acouple of months, they realized that it didn’t really work. So they make another change, and so on.— Team member

Moreover, activities not directly contributing to feature development, like the development of the CI and test automation systems, had tied up several teams, leaving fewer resources to work on new features. As the organization aims to constantly improve its way of working, the constant change might never be over, even thought the biggest changes towards agile adoption seemed to be almost done.

The fact that change was constant came up in most interviews, and was thus strongly supported. However, most respondents did not consider it a big issue, and preferred to focus on the fact that the constant change mostly brought improvements to their work.

5 Discussion

In this paper we presented motivation, phases, and challenges and mitigations related to a large-scale agile transformation in a single case organization. As the first in-depth study of an agile transformation, we think that the case study adds significant value both to research and to other organizations with a similarly challenging set-up, needing to customize agile. Next, we discuss our main findings and lessons learned.

5.1 Motivation for Agile Transformations

In this section we discuss the first research question, RQ1: Why did the organization initiate an agile transformation?

The organization had three main motivations for the transformation: alignment with the corporate strategy, dissatisfaction with the current way of working, and a need to enable rapid end-to-end deliveries of features and continuous deployment.

The two last motivations have been widely reported in the literature as well. Several cases discuss problems and dysfunctions with their old processes as a motivator for adopting agile, (e.g., O’Connor 2011 ; Chung and Drummond 2009 ; Vlaanderen et al. 2012 ; Hansen and Baggesen 2009 ; Murphy and Donnellan 2009 ). The need for rapid deliveries and continuous deployment were related to a need of getting new features to the market faster, i.e. reduce the time-to-market, reported previously (e.g., Gat 2006 ; Goos and Melisse 2008 ; Greening 2013 ; McDowell and Dourambeis 2007 ; Prokhorenko 2012 ; Silva and Doss, 2007 ).

The corporate strategy to adopt agile, naturally had an impact on the program, and helped make the decision to adopt agile. While we think this motivation is becoming increasingly common, in particular with the popularization of ”Enterprise Agile”, we did not find cases in the literature that explicitly reported this.

5.2 Large-Scale Agile Transformation Phases

In this section we discuss our second research question, RQ2: How did the transformation proceed?

The transformation started with a pilot phase with volunteers working in an agile team. This worked remarkably well, which was not unexpected, as the importance and benefits of piloting in agile transformations has been reported by several authors (e.g., Berczuk and Lv 2010 ; Chung and Drummond 2009 ; Fecarotta 2008 ; O’Connor 2011 ). The pilot team was dismantled and a full-scale transformation was started after only a short time for two reasons: the team quickly was able to show that agile could work well in the organization, and the other parts of the organization started to suffer. The volunteers for the pilot were highly skilled and active developers, and their absence from their component teams was dearly felt, as they now became an ”all-star” team, which was not optimal from the organization’s point of view. This pilot related problem has been discussed in (O’Connor 2011 ).

Due to the distributed nature of the organization, different sites had diverging views regarding both the future of the product and the way of working. Thus, there was a need to align the various parts of the organization to make agile work, and to create a strong product and organizational identity. To this end, the organization arranged ”value workshops”, in which common organizational values were discussed, and people from the various sites were able to meet face-to-face. These value workshops were considered critical from the point of view of transformation success. We are not aware of other reports discussing how to align various parts of a large, distributed organization in relation to, or as part of, an agile transformation.

Continuous integration is a cornerstone of agile, and particularly important for scaling (Gat 2006 ; Moore and Spens 2008 ). Implementing CI became the main focus after the value building work. The organization had three dedicated teams working on implementing CI, a known good practice reported in other large-scale agile transformations (Beavers 2007 ; Fry and Greene 2007 ; Gat 2006 ). This amounted to a significant investment in getting CI working, also reported in (Gat 2006 ; Moore and Spens 2008 ; Rodríguez et al. 2013 ). As implementing CI requires not only suitable tools, but also a change in the mindset of developers, e.g., to start implementing automated tests for new code, a series of CI roadshows were organized. We are not aware of other reports on how to get developer buy in and change the mindset in a full-scale CI rollout.

5.3 Challenges and Mitigations in Large-Scale Agile Transformations

In this section we discuss the third and fourth research questions, RQ3: What challenges did the organization encounter? and RQ4: How did the organization mitigate the challenges?

During the transformation, the organization encountered several challenges that they tried to mitigate. Next, we discuss the challenges and mitigations according to the challenge classification by (Dikert et al. 2016 , Table 11, p. 95) to facilitate easy comparison with the literature.

The first category, “change resistance”, a common problem in large-scale agile transformations (Dikert et al. 2016 ), was also visible in our case. The transformation had challenges in the beginning, as all members of the leadership team did not fully support going agile, and wanted to focus on deliveries rather than transforming the organization. The situation was resolved by reorganizing the leadership team to involve more people with agile experience.

The category “lack of investment”, contains the items lack of training, lack of coaching, too high workload, old commitments kept and challenges in rearranging physical spaces. In the current case, we identified lack of training, lack of coaches and coaching, as well as trying keep existing commitments, all of which have been previously reported by other organizations. However, the workspaces had already been completely renovated to support agile development, which explains why we saw no problems related to that.

The category “Agile difficult to implement”, contains the items misunderstanding agile concepts, lack of guidance from literature, agile customized poorly, reverting to the old way of working, and excessive enthusiasm. In our case, the organization mentioned the lack of guidance from the literature. Similarly to (Benefield 2008 ), the organization struggled with finding a good balance between control and autonomy, giving teams too much freedom, as a common agile framework was not emphasized.

According to the literature, the category “Coordination challenges in a multi-team environment” contains items like interfacing between teams difficult, autonomous team model challenging, and global distribution challenges. Cross-site teams posed problems in our case, as half of the teams were distributed between two or even three sites. Surprisingly the case did not experience significant problems with coordination between the teams. This might be partly explained by the existence of the PO team, in which the product owners closely collaborated, well-functioning communities of practice, and the team specialization into business flows.

A particularly prevalent category of issues in our case was “Different approaches emerge in a multi-team environment”. The two main issues in this category, according to (Dikert et al. 2016 ) are that the interpretation of agile differs between teams, and problems in using both old and new approaches side-by-side. The lack of a common framework led to a situation in which teams had different practices, making it difficult to switch teams. Moreover, the surrounding organization was still in a “waterfall mode”. For example, product management and release engineering was done mostly in a traditional way. For product management, this was much of a mindset issue. In release engineering the lack of agility could partly be explained by the lack of a working CI system in the early phases of our study. However, the situation improved during our study period when investing in building functioning CI and automated tests. Furthermore, there were challenges in defining the Product Owner role, as product management was unwilling to give the POs the power to actually prioritize features. This made the POs feel like messengers between product management and the development teams rather than real POs. This situation improved with the implementation of the PO team, and maturation in the understanding of agile in product management.

We were, perhaps surprisingly given the organization’s age and business, not able to identify any clear issues related to the category “Hierarchical management and organizational boundaries”. Items in this category include the role unclarity for middle managers in agile, management remaining in waterfall mode, keeping the old bureaucracy, and keeping internal silos. Many of these issues were encountered and solved at the biggest site (site A) already during an earlier large-scale transformation.

The category “Requirements engineering challenges” was, not unexpectedly quite visible in the case. The literature study mentions problems with high-level requirements management, challenges of refining requirements, difficulty of defining and estimating user stories, as well as a gap between long and short term planning. In our case, most salient was the challenge of breaking down large features into suitably sized epics and user stories. In the beginning, the organization did not have a common backlog, but several largely independent ones. This issue was resolved in the early phases of the transformation by rolling out a common tool and implementing a single backlog for the whole organization. From the requirements engineering point of view, a large technical debt created problems, as work on it had to be prioritized against development of new features. The common backlog helped to alleviate this problem, as well.

Regarding “Quality assurance challenges”, which refers to items accommodating non-functional testing, lack of automated testing, and requirements ambiguity affects QA, our organization faced significant challenges. In the beginning, the lack of test automation and CI created problems, as a huge amount of manual testing had to be done, which reduced the time available for actual development in each iteration. The mitigating actions included serious investment in building a working CI system, as well as CI roadshows to raise awareness about CI and help instill the right mindset in the teams.

In the category “Integrating non-development functions”, we have the items other functions unwilling to change, challenges in adjusting to an incremental delivery pace, challenges in adjusting product launch activities, and rewarding model not being teamwork centric. Our organization did not report big issues related to this category. One reason might by that the quite frequent delivery cycle remained the same during the whole transformation.

One particular problem that we identified that we did not find reported in the literature was the fact that the organization was unable to attain the agile ideal of any team being able to work on any item. In addition, teams in the case organization found it difficult to work as ”real teams” as they were formed of experts of different components, and learning to work on new components would take a long time. They were gradually mitigating this problem by broadening the knowledge of team members to other components by pair work. Moreover, both of these issues were mitigated by letting teams specialize in specific business flows.

5.4 Lessons Learned

In this section we have collected four lessons that we can learn from this case organization.

5.4.1 Lesson 1: Experimental Transformation Approach

The case organization espoused an “agile mindset” in their experimental transformation approach. The reason for this was that it was difficult to determine up front how to perform the transformation, despite the fact that part of the organization had previous experiences in transforming a large product development program from waterfall to agile.

In this case, the situation was different from the previous experience: The R&D product development program was not developing a traditional telecom product for operators, but a XaaS platform and services that the customers would not buy, but use as a service. The system consisted of several components, and the organization developing it was new, rapidly growing and highly distributed. In comparison, one previous transformation in the same case company (Paasivaara et al. 2013 ; Hallikainen 2011 ) was for a traditional, over ten years old telecom product developed at two sites with a stable organization size. Thus, the set up was quite different. For this reason, the organization felt they could not follow the steps of any previous transformation.

In practice, the experimental approach meant that the organization open-mindedly tried solutions to see if they would work in their setting. If something did not work, it was quickly changed. For example, the organization tried different team set-ups and made changes quickly when problems occurred.

The organization had a mindset that it is good to try and ok to fail , since that is the only way to learn. This mindset was pervasive and what we consider an agile way of implementing agile . We believe that this is an important aspect of succeeding in large-scale transformation that is widely transferrable to different contexts. The literature review supported this approach (Dikert et al. 2016 ) as several companies reported that customization of the agile approach is an evolutionary process, see e.g. (Rodríguez et al. 2013 ; Ryan and Scudiere 2008 ).

While the literature contains little empirically based guidelines for large-scale agile transformations, the literature on lean and lean software development contain some prescriptive guidelines, e.g. in (Poppendieck 2007 ; Hibbs et al. 2009 ; Womack and Jones 2010 ). Looking at Ericsson’s approach, it seems to embody several of the principles suggested by this literature. In particular, the focus on mindset and experimentation is well in line with the suggestions of the proponents of lean.

Mirroring the discussion about this, while this lesson here was learned in the context of large-scale adoption, as evidenced e.g., by the discussion above about the lean principles, it is likely to be valid also in other, i.e., small organization contexts.

Lesson 1: Consider using an agile mindset and taking an experimental approach to the transformation.

5.4.2 Lesson 2: Stepwise Transformation

As a large-scale lean and agile adoption is a big undertaking, our case organization performed it step by step. Instead of trying to change everything at once, they focused on one change at a time. First, they focused on teams: they experimented to find out a working team set-up and get all agile teams to work well. Second, they aimed to unify the highly distributed organization and to find a common direction by creating and working with common values. Third, they invested in building CI and test automation systems, as well as training the whole organization to be able to contribute to this new way of working.

A big bang transformation approach would probably not have worked well in this case, as the organization had to continue delivering releases to the customers at the same pace as previously during the transformation. Thus, the gradual adoption of practices and structures was considered as a necessity. In this case the step-by-step approach was clearly a successful choice, as it facilitated adoption as everything could not be planned beforehand. The stepwise approach is closely related to the experimental approach, as when starting the transformation they did not have a plan of the future steps. Instead, they reacted and experimented when changes were needed.

The literature contains reports of both big bang and step-by-step transformation approaches, with step-wise being more commonly used. Often, step-by-step transformations started by piloting, which was reported as one of the success factors (Dikert et al. 2016 ). Piloting was the first concrete action in our case project, even though it was used for a shorter duration than expected, due to the problems experienced in the rest of the organization, as the component teams lost too many central persons to the pilot team. Still, it was seen as a necessary step in the transformation.

We observed clear high-level transformation steps in our case organization. However, in the literature review, besides piloting, we did not identify clear steps that would be common to all transformations. Thus, this could be an interesting topic for future research.

It could reasonably be argued that stepwise organizational transformation is a widely useful strategy for all kinds of transformations and process improvements initiatives, and indeed, even the venerable CMM(I) takes such an approach. Thus, it is likely that this idea of stepwise improvement is widely applicable, and this case clearly seems to validate such a statement through the success seen here.

Lesson 2: Using a stepwise transformation approach is good in complex large-scale settings, where the transformation takes place during an ongoing development effort. Concentrating on one major topic at a time keeps the attention on the most important change topics.

5.4.3 Lesson 3: Limited Team Interchangeability

In the beginning of the transformation the case organization had a goal that any agile, cross-functional and cross-component team would be able to implement any feature from the top of the common backlog. However, they soon noticed that this was infeasible, due to the product complexity and the asymmetry of competences. The product was composed of several components, each requiring deep technical knowledge. Component specialists were not distributed evenly to different sites. Moreover, each feature would not touch all the components, but only a limited set. Of course, agile teams and individuals can and should broaden their knowledge, but there are limits to what is reasonable and doable.

We believe that also other large organizations implementing agile might find it useful to take into account that the goal of “any agile team being able to implement any feature on top of the backlog” might not be fully feasible.

The solution our case organization identified was to have teams specializing in use-cases spanning several components, or business flows as they called them, with a few teams working in each business flow. Within the business flows, each team could implement end-to-end functionality, from requirement to deployment. This was seen as very important for achieving a fast product development flow, and the end-to-end flow was not compromised. The teams would not need to have deep knowledge on all the components, as the features in a business flow did not touch all components. This solution seemed to work well. Unfortunately, the change took place close to the end of our study period, thus we could not observe whether any further improvements to the setup were needed.

Practitioners have suggested the division of large products into product areas , in which teams can specialize (Larman and Vodde 2010 ). Our previous research has confirmed this (Paasivaara et al. 2013 ). In this case, however, the difference is that the components in a way formed logical product areas, whereas the use-cases could better be specified into business flows, crossing several product areas. One can think of this as a matrix structure, as illustrated in Fig.  2 .

Lesson 3: In a large-scale complex product any cross-functional team might not be able to work on any item from the product backlog, instead team specialization might be needed.

5.4.4 Lesson 4: Lack of a Common Agile Framework

The organization gave the teams a lot of leeway in how they implemented agile—perhaps too much. The organization started by opting for Scrum, and arranged trainings that, however, everybody did not participate in. The agile background of the project members varied both between and inside distributed sites, as some had participated in trainings and agile projects before, while others had not.

Despite the fact that Scrum was chosen as the basic framework for all teams, only a few actually implemented the majority of the Scrum practices. For example, most teams were not using Sprints, but many did have daily Scrums. As there was a lack of coaches, nobody “forced” the teams to think about the best way for them to work in an agile way. This led to a situation in which some teams, having strong “agilists”, conformed quite well to Scrum, but others with less agile experience did not, focusing more on implementation tasks and more or less ignoring the process. Moreover, as people from different sites had not worked together before, and came from different cultures, they did not feel comfortable suggesting: “let’s work our way”.

Part of the interviewees had experience from another, still ongoing, project at one of the sites (reported in (Paasivaara et al. 2013 )). There, the agile transformation had started a few years earlier with heavy support from an external consulting company with common trainings for all, as this was the first agile project at that site. A common Scrum framework was used by all in the beginning, and later on modified towards Scrumban. After the common start the teams got more freedom and took responsibility also in customizing their own way of working. Thus, persons coming from this background to our case project, like many of the coaches and managers, knew that pure Scrum needs to be customized. Moreover, as part of the team members had some agile knowledge already, the teams were given quite free hands to customize, which however did not lead to perfect results.

Close to the end of our study period the coaches were planning to implement similar ways of coaching between the teams and sites, as that would, e.g., make collaboration and changing team members between the teams easier. Thus, they aimed to encourage creating similarities of ways of working in different teams.

Literature emphasizes team autonomy in the way team implements agile practices. Allowing teams to self-organize was one of the success factors of large-scale agile transformations (Dikert et al. 2016 ). On the other hand, Conforming to a single approach was mentioned as a success factor as well (Dikert et al. 2016 ). Finally, common trainings and open events were suggested for delivering the same message to everybody to ensure that agile understanding across the organization was consistent (Dikert et al. 2016 ).

When comparing the literature findings to our case, we may hypothesize that the lack of common trainings across the sites, the lack of sufficient and unified coaching and the lack of a clear common approach led to a lack of unified agile mindset and understanding. Thus, giving teams autonomy without enough coaching led to a suboptimal agile implementation in the teams. Interviewees with background from the other transformation within Ericsson, asked for a common framework, as they thought that model had worked well in the previous transformation. Such a framework with common and similar trainings across the sites could have supported the organization in finding a common direction in agile, and thus providing a common ground for teams to customize the practices later on.

In retrospect, starting with a common agile framework and common trainings seems rather self-evident, and indeed that seems to be the presumption behind any agile implementation, for both large and small organizations. However, the fact that our case organization did not do this, and subsequently run into problems seems to validate this idea, which is increasingly important as the organization grows, as inter-team coordination otherwise becomes very difficult or impossible.

Lesson 4: A lack of common agile framework to start with, a lack of common trainings across sites, and a lack of sufficient and unified coaching may lead to a lack of common direction in the agile implementation.

6 Conclusions

In this paper, we described the large-scale agile transformation of an Ericsson product development program developing a XaaS platform and a set of services towards their future goal of continuous feature delivery. We presented the steps taken, the challenges faced, and the mitigating actions taken, as well as four lessons learned that we think could be applicable to other organizations.

As noted in (Dikert et al. 2016 ), large-scale agile transformations are seldom easy, and literature provides little advice on how to successfully proceed. Thus, case studies like this one can help provide a basis for a deeper understanding of agile transformations in various contexts that can be used for synthesizing, theory building research.

There is little systematically conducted research on large-scale agile adoption (Dikert et al. 2016 ). Practitioner literature suggests several scaling frameworks that are actively promoted by their developers. However, independently documented experiences on the usage, customization and benefits of these frameworks is still lacking. Thus, finding validated solutions on what the end result of a transformation should look like or what steps to take is difficult.

As the current agile approaches do not provide good blueprints for what a scaled agile organization should look like, and the recent scaling frameworks are largely unvalidated, there seems to be a need for the organization to tailor its agile approach to fit its own organizational, business and product context. In our case study, for example the various approaches to team organization and the introduction of business flows can be viewed as successful customizations.

This need to customize the agile approach has been reported by other organizations adopting agile in-the-large — successful customization of the agile approach was mentioned as one of the top success factors in an SLR on agile transformations (Dikert et al. 2016 ).

While all organizations might feel the need to customize their agile approach, issues related to the surrounding organization, the complexity of a large product and the need for specific competences seem to increase the need for method customization. Thus, we think this need is specifically salient in large-scale agile contexts.

For future research, we suggest to conduct additional case studies on large-scale agile transformations, as research in this area is scarce. As the literature review showed (Dikert et al. 2016 ), only a few case studies exist, even though the topic seems to be highly relevant to large software development organizations moving to agile. Especially, tailoring and customizing of an agile approach to suit different kinds of large-scale organizations would be interesting. In addition, the usage of agile scaling frameworks, such as SAFe, LeSS and DAD, suggested by consultants, interest companies. However, almost no scientific studies on their usage or suitability to different environments exists.

XaaS: “anything as a service” or “everything as a service” The acronym refers to an increasing number of services that are delivered over the Internet rather than provided locally or on-site. (Banerjee et al. 2011 )

A different case project from ours

subscriber identity module

Abdelnour-Nocera J, Sharp H (2007) Adopting agile in a large organization: balancing the old with the new. Tech. rep. The Open University. Faculty of Mathematics and Computing , Department of Computing

Google Scholar  

Abdelnour-Nocera J, Sharp H (2008) Adopting agile in a large organisation. In: Agile processes in software engineering and extreme programming, proceedings, LNBIP, vol 9, pp 42–52

Ambler SW (2012) Disciplined Agile Delivery: a practitioner’s guide to agile software delivery in the enterprise. IBM Press

Banerjee P, Friedrich R, Bash C, Goldsack P, Huberman B, Manley J, Patel C, Ranganathan P, Veitch A (2011) Everything as a service: powering the new information economy. Computer 44(3):36–43. https://doi.org/10.1109/MC.2011.67

Article   Google Scholar  

Beavers P (2007) Managing a large “agile” software engineering organization. In: Agile Conference (AGILE), 2007 pp 296–303

Benefield G (2008) Rolling out agile in a large enterprise. In: Hawaii International Conference on System Sciences, Proceedings of the 41st Annual, p 461

Berczuk S, Lv Y (2010) We’re all in this together. Software, IEEE 27(6):12–15

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

Chung MW, Drummond B (2009) Agile at yahoo! from the trenches. In: Agile Conference, 2009. AGILE `09., pp 113 –118

Cunningham W (1992) The wycash portolio management system. In: Proceedings of OOPSLA

Dikert K, Paasivaara M, Lassenius C (2016) Challenges and success factors in large-scale agile transformations: A systematic literature review. J Sys Softw

Dingsøyr T, Moe N (2013) Research challenges in large-scale agile software development. SIGSOFT Softw Eng Notes 38(5):38–39

Dingsøyr T, Moe N (2014) Towards principles of large-scale agile development. In: Dingsøyr T, Moe N, Tonelli R, Counsell S, Gencel C, Petersen K (eds) Agile Methods, Large-Scale Development, Refactoring, Testing, and Estimation, Lecture Notes in Business Information Processing, vol 199, Springer International Publishing, pp 1–8, https://doi.org/10.1007/978-3-319-14358-3_1

Dybå T, Dingsøyr T (2008) Empirical studies of agile software development: a systematic review. Inf Softw Technol 50(9-10):833–859

Fecarotta J (2008) Myboeingfleet and agile software development. In: Agile, 2008. AGILE `08. Conference, pp 135 –139

Freudenberg S, Sharp H (2010) The top 10 burning research questions from practitioners. Software, IEEE 27(5):8–9

Fry C, Greene S (2007) Large scale agile transformation in an on-demand world. In: Agile Conference (AGILE), 2007, pp 136 –142

Gat I (2006) How bmc is scaling agile development. In: Agile Conference, 2006, pp 6–320

Goos J, Melisse A (2008) An ericsson example of enterprise class agility. In: Agile, 2008. AGILE `08. Conference, pp 154–159

Greening D (2013) Release duration and enterprise agility. In: System Sciences (HICSS), 2013 46th Hawaii International Conference on, pp 4835–4841

Hallikainen M (2011) Experiences on agile seating, facilities and solutions: multisite environment. In: Global Software Engineering (ICGSE), 2011 6th IEEE International Conference on, pp 119–123

Hansen M, Baggesen H (2009) From cmmi and isolation to scrum, agile, lean and collaboration. In: Agile Conference, 2009. AGILE `09., pp 283–288

Hanssen G, Smite D, Moe N (2011) Signs of agile trends in global software engineering research: a tertiary study. In: Global Software Engineering Workshop (ICGSEW), 2011 Sixth IEEE International Conference on, pp 17–23, https://doi.org/10.1109/ICGSE-W.2011.12

Hibbs C, Jewett S, Sullivan M (2009) The art of lean software development: a practical and incremental approach. Theory Prac, O’Reilly Media, https://books.google.fi/books?id=sBy4OrfZyYsC

Highsmith J, Cockburn A (2001) Agile software development: the business of innovation. Computer 34(9):120–127

Holmstrom H, Fitzgerald B, Agerfalk PJ, Conchuir EO (2006) Agile practices reduce distance in global software development. Inf Syst Manag 23(3):7–18. https://doi.org/10.1201/1078.10580530/46108.23.3.20060601/93703.2

Hossain E, Babar MA, Paik Hy (2009) Using scrum in global software development: a systematic literature review. In: Proceedings of the 2009 Fourth IEEE International Conference on Global Software Engineering, IEEE Computer Society, Washington, DC, USA, ICGSE `09, pp 175– 184

Jick TD (1979) Mixing qualitative and quantitative methods: triangulation in action. Adm Sci Q 24(4):602–611

Korhonen K (2012) Evaluating the impact of an agile transformation: a longitudinal case study in a distributed context. Softw Qual J 21(4):599–624

Kruchten P, Nord R L, Ozkaya I (2012) Technical debt: from metaphor to theory and practice. IEEE Software 29(6)

Larman C, Vodde B (2010) Practices for scaling lean & agile development: large, multisite, and offshore product development with large-scale scrum. Addison-Wesley Professional Boston. MA, USA

Larman C, Vodde B (2015) Less framework. http://less.works/

Leffingwell D (2007) Scaling software agility: best practices for large enterprises. Addison-Wesley Professional

Leffingwell D (2015) Scaled agile framework. http://scaledagileframework.com/

Lindvall M, Muthig D, Dagnino A, Wallin C, Stupperich M, Kiefer D, May J, Kahkonen T (2004) Agile software development in large organizations. Computer 37(12):26–34

Livermore JA (2008a) Factors that significantly impact the implementation of an agile software development methodology. J Softw 3(4):31–36

Livermore JA (2008b) Factors that significantly impact the implementation of an agile software development methodology. J Softw 3(4):31–36

Long K, Starr D (2008) Agile supports improved culture and quality for healthwise. In: Agile, 2008. AGILE `08. Conference, pp 160 –165

McDowell S, Dourambeis N (2007) British telecom experience report: Agile intervention - bt’s joining the dots events for organizational change Agile processes in software engineering and extreme programming, proceedings, LNCS, vol 4536, pp 17–23

Moore E, Spens J (2008) Scaling agile: Finding your agile tribe

Murphy P, Donnellan B (2009) Lesson learnt from an agile implementation project Agile processes in software engineering and extreme programming, LNBIP, vol 31, pp 136–141

O’Connor C (2011) Anatomy and physiology of an agile transition. In: Agile Conference (AGILE), 2011, pp 302 –306

Paasivaara M, Lassenius C (2014) Communities of practice in a large distributed agile software development organization – case ericsson. Inf Softw Tech 56 (12):1556–1577. https://doi.org/10.1016/j.infsof.2014.06.008 , http://www.sciencedirect.com/science/article/pii/S0950584914001475 , special issue: Human Factors in Software Development

Paasivaara M, Lassenius C, Heikkila V, Dikert K, Engblom C (2013) Integrating global sites into the lean and agile transformation at ericsson. In: Global Software Engineering (ICGSE), 2013 IEEE 8th International Conference on, pp 134–143, https://doi.org/10.1109/ICGSE.2013.25

Paasivaara M, Behm B, Lassenius C, Hallikainen M (2014a) Towards rapid releases in large-scale xaas development at ericsson: A case study. In: Global Software Engineering (ICGSE), 2014 IEEE 9th International Conference on, pp 16–25, https://doi.org/10.1109/ICGSE.2014.22

Paasivaara M, Väättänen O, Hallikainen M, Lassenius C (2014b) Supporting a large-scale lean and agile transformation by defining common values. In: Proceedings of the Workshop on Principles of Large-Scale Agile Development (in press)

Patton MQ (1990) Qualitative evaluation and research methods, 2nd edn. Sage Publications, Newbury Park, Calif

Petersen K, Wohlin C (2010) The effect of moving from a plan-driven to an incremental software development approach with agile practices. Empir Softw Eng 15 (6):654–693

Poppendieck M (2007) Poppendieck, T. From concept to cash. Pearson Education, Implementing lean software development

Poppendieck M, Cusumano M (2012) Lean software development: A tutorial. Software, IEEE 29(5):26–32. https://doi.org/10.1109/MS.2012.107

Prokhorenko S (2012) Skiing and boxing: coaching product and enterprise teams. In: Agile Conference (AGILE), 2012, pp 191–196

Ranganath P (2011) Elevating teams from `doing’ agile to `being’ and `living’ agile. In: Agile Conference (AGILE), 2011, pp 187–194

Rodríguez P, Mikkonen K, Kuvaja P, Oivo M, Garbajosa J (2013) Building lean thinking in a telecom software development organization: strengths and challenges. In: Proceedings of the 2013 International Conference on Software and System Process, ICSSP’13, pp 98–107

Rodríguez P, Haghighatkhah A, Lwakatare LE, Teppola S, Suomalainen T, Eskeli J, Karvonen T, Kuvaja P, Verner JM, Oivo M (2016) Continuous deployment of software intensive products and services: a systematic mapping study. J Syst Softw

Ryan J, Scudiere R (2008) The price of agile is eternal vigilance. In: Agile, 2008. AGILE `08. Conference, pp 125–128

Schwaber K, Beedle M (2002) Agile software development with scrum. Series in agile software development, Prentice Hall

MATH   Google Scholar  

Silva K, Doss C (2007) The growth of an agile coach community at a fortune 200 company. In: Agile Conference (AGILE), 2007, pp 225–228

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

VersionOne Inc (2016) 10th annual “state of agile development” survey. https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf

Vlaanderen K, Van Stijn P, Brinkkemper S, Van De Weerd I (2012) Growing into agility: process implementation paths for scrum. In: Product-focused software process improvement, proceedings, LNCS, vol 7343, pp 116–130

Wenger E, McDermott R, Snyder WM (2000) Communities of practice: the organizational frontier. Harvard Business Review (Jan-Feb):139–145

Wenger E, McDermott R, Snyder WM (2002) Cultivating communities of practice harvard business review press. MA, Cambridge

Womack JP, Jones DT (2010) Lean thinking: banish waste and create wealth in your corporation. Simon and Schuster

Yin RK (2009) Case study research: design and methods, 4th edn. SAGE Publications, Thousand Oaks, CA, USA

Download references

Acknowledgements

The authors would like to thank Ericsson and in particular the interviewees for participating in the study. This work was supported by TEKES as part of the Need for Speed (N4S) SHOK program.

Author information

Authors and affiliations.

Department of Computer Science, Aalto University, P.O. BOX 19210, FI-00076, Aalto, Finland

Maria Paasivaara, Benjamin Behm & Casper Lassenius

Oy LM Ericsson Ab, Hirsalantie 11, FI-02420, Kirkkonummi, Finland

Minna Hallikainen

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Maria Paasivaara .

Additional information

Communicated by: Hakan Erdogmus

A Interview Guide - Round 1 - Transformation Journey

2.1 a.1 general questions.

Interviewee background (e.g., role and tasks in the organization, history in the organization)

Overview of the transformation (e.g., reasons for transformation, goals of the transformation, starting the transformation, agile trainings and coaching, transformation steps)

Agile methods and practices (e.g., agile principles followed, agile methods used, agile practices used, your personal opinion about agile)

Communication and collaboration (e.g. division of work, inter-team communication and collaboration, collaboration with other sites, interaction with other people in the company, knowledge sharing, Scrum-of-Scrums, communities of practice, successes and challenges in communication and collaboration)

Testing and continuous integration (e.g. testing practices, testing levels, test environment, CI goals and practices, releases, release practices, challenges and successes in testing/CI)

Challenges and solutions (e.g., biggest challenges of the transformation, solutions implemented/tried, challenges remaining at the moment, solution suggestions)

Successes and drawbacks (e.g., successes achieved, benefits of the transformation, benefits of agile, possible drawbacks of agile)

Plans for the future (e.g., plans for the next steps, your opinions on what should be done, possible stumbling blocks)

Final comments (e.g., anything you would like to comment or add)

2.2 A.2 Role Specific Topics and Questions

2.2.1 a.2.1 managers.

Overview of the organization (e.g., history of the organization, organization structure earlier, current organization structure)

Planning the transformation (e.g., how the transformation was planned, how did you participate in planning / executing the transformation, roadmap for transformation)

2.2.2 A.2.2 Product Owners

The role of a Product Owner (e.g., tasks and duties, collaboration with the teams, your role as a Product Owner for remote teams, interaction with other people in the company)

Feature handling (e.g., the flow of requirements, interaction with customers or users, interaction with product line, working with backlog, prioritization)

2.2.3 A.2.3 Coaches

The role of an agile coach (e.g., how do you work with teams / the rest of the organization, how much time do you spend with teams, how much help teams ask from coaches, how do you promote learning, innovation, and self-organizing, how do you motivate teams)

Agile teams (e.g. team formation)

Agile methods and practices (e.g., Are teams using text-book Scrum or have you modified Scrum practices to fit better to teams’ needs? Are teams allowed to select frameworks they use (e.g., between Scrum and Kanban)?)

Coaching Product Owners (e.g., how do you support Product Owners as a coach, how much time do you spend with Product Owners, how much help Product Owners ask from you)

Organizational coaching (e.g. how do you participate in organizational coaching, what do you personally do to build a uniform agile the organization, what are the challenges in adopting organization wide agile)

Collaboration with other coaches (e.g., what, why, how, how often)

2.2.4 A.2.4 Architects

The role of an architect (e.g. tasks and duties, collaboration with development and testing, collaboration with the rest of the organization)

The role of architecture (e.g., how is architecture seen in your organization, how is architecture created in practice, how much effort is used to it)

2.2.5 A.2.5 Product Managers

Backlog and release (e.g., requirements handling, who makes the decisions of the content of backlogs, backlog prioritization, how do you decide what to include in a release)

Relationship with Product Owners (e.g., the division of responsibilities between product manager and Product Owners, collaboration with Product Owners, challenges, good practices, improvement suggestions)

Releasing (e.g., release management process in the organization, release frequency, release practices, release team, challenges and successes, improvement goals, improvement suggestions)

2.2.6 A.2.6 Developers

Transition to agile (e.g., biggest changes to you as a developer)

Agile team (e.g., your teams’ tasks/responsibilities, describe your team, team structure, is you team self-organizing, how is your team taking responsibility, team collaboration, team space, trust among team members)

Coaching (e.g., help/coaching received, do you / your team get enough support from the coaches, improvement suggestions)

Meetings (e.g., meetings that you have / meetings that you or your team members participate, usefulness of the meetings, improvement suggestions)

Inter-team coordination (e.g. how it is done, who, when, how often, visibility to what other teams are doing, challenges, successes, improvement suggestions)

2.3 B Interview Guide - Round 2 - Value Workshops

Beforehand knowledge about the values (e.g., What did you know about values before the value workshop? Do you know why the value workshops were arranged? Do you know where the values come from?)

Value workshops (e.g., What do you think about this event? The contents, the way it was arranged, what was good / not good, what could be improved / done differently, benefits of the value workshops for you))

Values (How do you feel about the values? Good / bad)

After the value workshops (Are you going to do something differently? What should be done after the workshops?)

Rights and permissions

Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Reprints and permissions

About this article

Paasivaara, M., Behm, B., Lassenius, C. et al. Large-scale agile transformation at Ericsson: a case study. Empir Software Eng 23 , 2550–2596 (2018). https://doi.org/10.1007/s10664-017-9555-8

Download citation

Published : 11 January 2018

Issue Date : October 2018

DOI : https://doi.org/10.1007/s10664-017-9555-8

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 software development
• Large-scale agile
• Adopting agile
• Enterprise agile
• Scaling agile
• Find a journal
• Publish with us
• Track your research

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

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

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

Case Study: ‘Getting the board on board’: The Secret of Saba’s Agile Success!

Elavon Europe - It's not about Agile

Presentation from the Agile Business Awards Conference 2023

Vodafone - Mission Impossible? A complex yet exciting journey

All case studies.

Capgemini: What happens when a large company starts drinking its own champagne

Roads and Transport Authority - Dubai: The Path to A Future Proof organization is one that Builds Agility Into its DNA

RHB Banking: Agile - Marathon in Sprints

NewsUK: The Real-Life Transformational Fairytale

Change the game: Bold. group's transformation into an Agile Marketing Agency!

Save the Children UK: An Agile Marketing Transformation - the ever evolving journey

NatWest Group: What IS Agile?

From “Infrastructure” to “Mobility”: making Agile Marketing work at Saba

bp: From Ambition to Action

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.

Agile Project Management

Download and customize this and 500+ other business templates

Start here ⬇️

Voila! You can now download this Presentation

Has the traditional linear approach to project management left you over budget with an under-developed product and dragged out time-to-market? An agile approach provides greater flexibility, transparency, and accountability for managers with complex projects that require multiple phases of feedback and revision. With this Agile Project Management deck, focus on customer needs with an iterative approach to maximize project success.

25 questions and answers

How does the agile approach facilitate team collaboration in project management?

The agile approach facilitates team collaboration in project management by providing greater flexibility, transparency, and accountability. It allows for multiple phases of feedback and revision, which encourages continuous communication and collaboration among team members. This iterative approach focuses on customer needs and maximizes project success.

What are the best practices in agile project management?

Some of the best practices in agile project management include: focusing on customer needs, using an iterative approach, incorporating feedback and revisions at multiple stages, maintaining transparency and accountability, and providing flexibility in managing complex projects.

How does the agile approach help in managing project risks?

The agile approach helps in managing project risks by providing greater flexibility, transparency, and accountability. It allows for multiple phases of feedback and revision, which can help in identifying and mitigating risks early in the project. It also focuses on customer needs, which can help in ensuring that the project is aligned with the expectations and requirements of the customer, thereby reducing the risk of project failure.

Slide highlights

In the agile development process, a manager receives requirements and project constraints, and the team develops possible solutions and releases multiple iterations until final approval or product launch. (Slide 7)

Scrum is a commonly used agile methodology. The team roles of scrum can be classified as an organizational chart to detail the key stakeholders and person-in-charge on the project management team. (Slide 9)

Kanban boards are essential to workload management and progress tracking. Its visualizations can be used in agile management to limit work in progress, manage workflows, and create positive feedback loops. (Slide 12)

How does agile project management help in managing complex projects?

Agile project management helps in managing complex projects by allowing for flexibility and adaptability. It breaks down the project into smaller, manageable parts called iterations. These iterations are developed and tested in short cycles, allowing for regular feedback and adjustments. This approach ensures that any issues or changes can be addressed promptly, reducing the risk of project failure. Agile methodologies like Scrum and Kanban further aid in project management by defining team roles and managing workflows respectively.

What are some best practices for implementing agile project management?

Some best practices for implementing agile project management include: \n\n1. Regularly receiving requirements and project constraints from the manager and developing possible solutions. \n2. Releasing multiple iterations until final approval or product launch. \n3. Using Scrum, a commonly used agile methodology, and clearly defining team roles. \n4. Using Kanban boards for workload management and progress tracking. They help limit work in progress, manage workflows, and create positive feedback loops.

How does agile project management help in reducing time-to-market?

Agile project management helps in reducing time-to-market by allowing for continuous improvement and iteration of the product. This means that instead of waiting for the entire product to be completed before it is launched, parts of the product or service can be released and tested in the market. Feedback from these tests can then be used to improve the product, and this cycle continues until the final product is ready. This approach ensures that the product is always improving and can be launched in the market as soon as it meets the minimum viable product (MVP) criteria.

The agile method of project management can be used by organizations of any size. For large organizations with a legacy issue, agile could especially lead to a more efficient workflow than the traditional waterfall model. With agile, managers can take an iterative and collaborative approach to product development and project organization. Agile's focus is on customer needs and minimizes the resources and overhead needed to create a product with true market-fit. The increased flexibility and rapid pace also create faster turnaround times — the ultimate plus for project managers.

How does the agile method contribute to efficient workflow?

The agile method contributes to efficient workflow by allowing organizations to take an iterative and collaborative approach to product development and project organization. It focuses on customer needs and minimizes the resources and overhead needed to create a product with true market-fit. The increased flexibility and rapid pace also create faster turnaround times, which is a significant advantage for project managers.

What are the key steps in implementing the agile method in an organization?

The key steps in implementing the agile method in an organization include: 1. Understanding the agile principles and values. 2. Training the team on agile methodologies. 3. Setting up an agile team and assigning roles. 4. Creating a product backlog. 5. Planning and executing sprints. 6. Reviewing and adapting the process.

How does the agile method align with customer needs?

The agile method aligns with customer needs by focusing on them during the product development and project organization. It minimizes the resources and overhead needed to create a product with true market-fit. The increased flexibility and rapid pace of the agile method also create faster turnaround times, which can be beneficial for customers.

Application

Methodology.

We begin with an overview of the agile methodology and how it is used in project management. Agile Method for Digital Product was originally developed as a newer approach to software development, but its ethos has been translated and applied to project management, product development, and even organizational management. For any team to be responsive and quick to adapt, agile can be a much stronger method to follow as opposed to the traditional, waterfall method where tasks are accomplished in a linear sequence.

What are the future trends in the agile methodology in project management?

The future trends in agile methodology in project management include a greater emphasis on customer experience and user-centric design, increased use of AI and automation in project management, and a shift towards distributed and remote teams. There is also a trend towards more holistic and integrated approaches, combining agile with other methodologies like Lean and DevOps. Furthermore, there is a growing recognition of the importance of 'soft skills' like communication and empathy in agile project management.

How does the agile methodology help in managing changes in project management?

The agile methodology helps in managing changes in project management by making teams more responsive and quick to adapt. Unlike the traditional waterfall method where tasks are accomplished in a linear sequence, agile allows for flexibility and adaptability, making it easier to manage changes.

What are the training and certifications available for the agile methodology in project management?

There are several training and certifications available for the agile methodology in project management. Some of the most popular ones include Certified ScrumMaster (CSM), Certified Scrum Product Owner (CSPO), Certified Scrum Developer (CSD), Project Management Institute-Agile Certified Practitioner (PMI-ACP), and SAFe Agilist (SA). Each of these certifications has its own set of requirements and benefits, and they can help you gain a deeper understanding of the agile methodology and enhance your skills in managing agile projects.

Between traditional and agile project management methods, there are some key differences. Agile is very customer-centric, as it focuses product development on the end-user via multiple rounds of feedback and revisions. It is also flexible, which is a key point that separates it from the sunk cost fallacy that can happen in traditional models. This is where managers think just because a plan was made, it has to go through even if red flags show up in the process. Agile, on the other hand, gives stakeholders and participants the chance to pivot as appropriate, and either come up with a new iteration or start from scratch. The traditional method also focuses on documentation and time-consuming administrative details that team members feel compelled to complete but can require costly overhead. This can easily take valuable hours away from productive execution tasks.

Agile looks for working solutions and maximum business value in the least amount of time. Projects that are managed with an agile approach typically have shorter release cycles, which expedites the time-to-market. That's why agile is especially applicable to product or product feature development. (Slide 3)

Next, we move on to some key advantages of agile, which include better management of priorities, improved project visibility, higher team morale, better alignment between business needs and IT, boosted productivity, and faster time-to-market. The percentages here are editable graphs a project manager can use to assess how these key areas have improved after the switch to agile. (Slide 4)

The agile project management process can be viewed in stages: the prework, the start of the project with the initial set of requirements (let's group them as requirements A here), feedback for this first set of requirements and requirements B, then feedback and requirements C. The project requirements are sometimes also known as tasks to be completed during each stage.

The prework stage is not exclusive to agile. Every project needs a blueprint to kick off regardless of its management methodology. The prework stage could be where managers define product vision, what the project entails, main tasks required, contractual agreements with external stakeholders, and a proposed release plan. Because the whole point of agile is to allow pivoting, the original release plan is more like a general blueprint of where you can go but can be adjusted.

For example, you want to add a livestream shopping feature to an e-commerce site. The prework would be the development of the product vision and how it will integrate with your existing website and user base, the preliminary contractual agreements with talent that will be involved in the first wave of live stream content that will launch with the product, and your original release plan and features.

Now you start the agile process and set out to accomplish the project's "Group A" requirements. For this Livestream feature, let's say your Group A requirements are to come up with a low-fidelity wireframe of how the user interface will work. In the wireframe development, you'll need to create three possible versions, then develop a low fidelity prototype for a few users to test.

After you gather feedback from your test group, it's time to implement it into the "Group B" requirements to create your next iteration. One of your first tasks at this point could be to analyze and synthesize study results and make sense of them. Another could be to discuss UX changes with the software team, modify the lofi prototype, and create hifi mockups for another round of feedback. Schedule another user group to come in for feedback, then synthesize and implement their input into "Group C" requirements to rinse, repeat, and release.

Now, for comparison, what would this project look like if it followed the traditional model, and not Agile? Your development team would sketch the user interface, come up with a high fidelity prototype, send it off to the dev team to create the perfect version, and launch it fully formed only to discover it confuses the users. At this point, it is much harder and slower to make changes because so many links in the chain have already come together. For every little change, a whole cascade of other changes could be involved. This is why agile can often be more successful and catch mistakes before they become more irreversible.

Process details

A more detailed agile process breaks down the personnel involved in the lifecycle. The project begins with the stakeholders, which could be both internal and external, an executive or investor, or even a user persona with a development request. Their demands are communicated and then translated into project specs. The project specs are then managed by the project or product owner. This team leader prepares reports that will be used to manage the backlog of requirements to be developed and dispatched. In this example, there are three main versions. After each version's release, there will be a backlog of areas for improvement (based on feedback) to implement before the next release. (Slide 6)

Scrum is a common method of agile project management. The Scrum Process has six key elements. The first one is the product backlog, or the list of requirements that are prioritized and often divided into work packages. Another element of scrum is sprints, which divides work into fixed duration (usually a few days) that hyper-focuses on a specific work package for a functional result.

These sprints are then reviewed in a meeting where the team presents the result for feedback that is implemented into the next sprint. A sprint backlog is then used to split the work into smaller packages or allocated to smaller teams and document the remaining work for each package. The idea is to shape the product in increments of improvement so that each sprint accomplishes some level of potentially shippable functionality. Finally, daily scrum meetings, often lead by the scrum master, confirm everything is going the right way.

To segment by psychographic profile, break down your customers by lifestyle, personality, values and interest. For instance, let's say your target customers follow the lifestyle of an urban professional. Their personality is curious with a love for new innovations and the latest gadgets. They value stability, fluidity and ease of use, and they have an interest in everything from arts and entertainment to tech. However, their unifying interest is to accomplish daily tasks easier.

Let's say you want to use this visualization as part of your daily scrum meeting. You can actually edit this information to list the details you want to review under each element. For instance, under product backlog, you can replace the bullet points with the requirements that still need to be implemented. Under sprint, you can summarize the current status of the sprint. Your Sprint backlog card will cover what still needs to be accomplished. (Slide 8)

Another useful agile method is Kanban. Kanban Methodology visualizes a lean workflow in a notecard format, with columns that correspond to steps of the development process and cards assigned for individual tasks. Kanban makes policies explicit with a collective definition of the process and agreed-upon guidelines, and naturally creates a feedback loop for continuous improvement through regular meetings. Also, Kanban makes it easier to manage workflows through the reduction of bottlenecks since everyone can see where the hold-up in the chain is. And because it limits the ongoing work to prevent multitasking, Kanban doesn't overburden team members.

You can use the colors to represent individual team members and the tasks they are assigned. The Kanban board is made up of a backlog of tasks, tasks that have been accepted, and tasks that are to be implemented, tested, and then completed.

With our livestream shopping feature, the backlog would be all the tasks that we previously defined, like the wireframe development, the UX features, and any coordination with talent or test groups that needs to be managed. As the project manager, you will take tasks from the backlog and assign them to individual team members. As you can see, maybe the main software developer is light green. Here they have three tasks in their to-do and one in progress. The partnerships coordinator, who is in charge of managing talent, is in dark green. In this case, all of their talent acquisition-related tasks are done, as the contracts have all been signed with the influencers who will test and provide feedback then release content at launch. (Slide 11)

An agile roadmap can be used as a project timeline to track progress across multiple years. In this visualization, three different workstreams can be tracked across the years and are color-coded by project risk level. Project Risk Management is important as there can be uncertain events or conditions that disrupt a project's process. Awareness of possible outcomes or possible disruptions better prepares both manager and stakeholder.

For projects or tasks that are high risk, you can see where to focus your attention, or adjust task priorities so another key task isn't entirely contingent on the success of a high-risk task. Ideally, a task that follows a high-risk task can be carried out despite the success or failure of the high-risk task.

In the case of our live stream shopping feature, a delay to sign up content creators could lead to a weak launch with not enough content to keep your user base engaged, or even know how this new feature works. Another high-risk task could be the creation of the creator dashboard where creators upload their content. If this backend is not set up properly, no one will be able to upload their content or watch livestreams, which would effectively kill your launch. (Slide 13)

Alternatively, an agile release plan is another type of roadmap project managers can use to track timelines across different versions and releases. It's more of a phase-based visualization that tracks tasks and progress across iterations, which can be helpful variation depending on what information you need to track or communicate with key stakeholders at various stages of the project. (Slide 15)

Case Studies of Agile Enterprise Transformation

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

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

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

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

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

Ready for Your Last Agile Transformation?

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

Popular searches

Design Thinking

Customer Experience

Finance Services

View all Categories

Editorial Articles

View all insights

Agile Methodology Examples and Case Studies

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

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

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

Who uses Agile Methodology?

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

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

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

Agile Strategy examples

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

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

Agile Transformation

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

Agile Methodology

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

Case Studies

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

Case Study Government

Case Study Mining

Case Study Financial Service

Agile Examples

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

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

Get in touch now to find out more

US Headquarters

695 Town Center Dr, Suite 1200

Costa Mesa, CA 92626

+1 424 543 2623

[email protected]

AUSTRALIA & NEW ZEALAND

Simpson House, Level 5, 249 Pitt Street

Sydney NSW 2000

+61 2 7200 2530

L7, North Tower, 276 Flinders St

Melbourne VIC 3000

Auckland ( Tāmaki Makaurau)

Level 4, ACS House, 3 Ferncroft Street,

Grafton, Auckland 1010

New Zealand

3 Temasek Avenue #18-01 Centennial Tower

Singapore 039190

+65 98348486

ul. Czackiego 15/17 street

00 -043 Warszawa

+48 505 626 416

110 Cumberland Street Suite # 307

Toronto Ontario M5R 3V5

+1 647 631 1205

5th Floor, 167-169 Great Portland Street

London W1W 5PF

+44 20 3603 1662

How we work

Case studies

©2022 ADAPTOVATE. All rights reserved

Privacy Policy |  Corporate News | Sitemap

We are back in Europe and hope you join us!

Prague, Czech Republic, 15 – 17, May 2023

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

• SAFe Contributors
• Extended SAFe Guidance
• Community Contributions
• SAFe Beyond IT
• Books on SAFe
• Download SAFe Posters & Graphics
• Presentations & Videos
• FAQs on how to use SAFe content and trademarks
• What’s new in the SAFe 5.1 Big Picture
• Recommended Reading
• Learn about the Community
• Member Login
• SAFe Implementation Roadmap
• Find a Transformation Partner
• Find a Platform Partner
• Customer Stories
• SAFe Training

CASE STUDY: LEGO Digital Solutions

LEGO ® applies its own approach of “systematic creativity” to adopting SAFe

UPDATE January, 2017 : A year after Henrik Kniberg and Eik Thyrsted shared the first phase of LEGO’s SAFe journey, they are back with the next chapter of their story. Their efforts to nip and tuck SAFe for optimal results run the gamut from large edits to small tweaks, and their learnings and outcomes are captured in a 36-page in-depth summary that is full of candid commentary and describes the thought process behind each decision. You can download it below.

Download LEGO Case Study Update

“ … this has ​improved the motivation​ of the team members. Going to work is more fun when there’s less confusion and less waste. And motivated people do better work, so it’s a positive cycle! Another impact we’ve seen is that other parts of LEGO visit the meeting, get super inspired, and start exploring how to implement some of these principles and practices in their own department. In fact, agile is spreading like a virus within the company, and the highly visible nature of the PI planning event is like a a catalyst. ” —Henrik Kniberg and Eik Thyrsted

One of the world’s leading manufacturers of play materials, The LEGO Group is still owned by the Kirk Kristiansen family who founded it in 1932. With headquarters in Billund, Denmark, and main offices in Enfield, USA, London, UK, Shanghai, China, and Singapore, the company employs more than 15,000 people worldwide.

In 2014, LEGO Digital Solutions turned to SAFe to improve their collaboration model and seek out what they like to refer to as the “Land of Awesome.” Their story of transformation was presented at LKCE (Lean Kanban Central Europe) by LEGO’s Head of Project Management, Eik Thyrsted Brandsgård and Lean/Kanban Coach, Mattias Skarin from Crisp.

Much like creating something from LEGO ® bricks, they built their transformation one piece at a time, starting with inviting 20 managers to a 2-day Leading SAFe class. From there, they began training the teams; first one, then another until they had 20 teams trained in SAFe. They approached every step as a learning journey, allowing for creativity along the way. When something didn’t seem like a good fit, they weren’t afraid to experiment. Taking results from Inspect and Adapt, they tweaked SAFe to their needs with a simple guiding principle, “Keep the stuff that generates energy.”

“The combination of a structured system, logic and unlimited creativity encourages the child to learn through play in a wholly unique LEGO fashion.” —The LEGO Group

Their first PI Planning event—which they now refer to as their “center of gravity”—went better than expected, with the teams eager to take what they learned and apply it.

“You just can’t replace face-to-face communication, and PI planning is just a fantastic way to do that.”

Their presentation includes insights and lessons learned, such as:

• You need critical mass
• They can now better manage expectations
• Don’t be afraid to experiment
• To become good at something you need to practice it
• Experimenting your way forward matters more than your selection of path

SAFe’s creator, Dean Leffingwell, calls their presentation, “One of the most insightful applications and presentations that I’ve yet seen on SAFe.” You can view their 45-minute video below.

Many thanks to Mattias and Eik for sharing their inspiring story!

Privacy Overview

Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.

Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.

Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.

Recorded Case Study Presentation

• Mcs case study pr...

08 Feb 2021  James  7 mins read.

Case Study Diagrams/Pre-Read

Presentation transcript, video index, zoom chat log.

The Twin Cities LeSS Meetup leadership team graciously extended an opportunity for me to discuss my experience coaching a LeSS-like transformation within a division of a multi-national networking hardware company. The event listing can be found here . The recorded Zoom meeting and relevant pre-read handouts are available below.

The pre-read handout contains a complete copy of every figure and associated caption in my case study so far, as well as some useful introductory context.

• Pre-Read Handout in Online Format
• Pre-Read Handout in PDF Format

I have manually created an edited transcript file for YouTube’s closed captions. With all the deep thoughts, and false starts, the manually edited closed captions make it a little easier to follow the dialogue.

You can also download the manually edited transcript . You can skim the transcript to discover the parts you find most interesting, and use the video index below to quickly find the relevant portions of the video.

00:00:00 - Event Banner

00:00:12 - Introduction

00:03:56 - Overview

00:52:33 - Discussion Starts

00:52:48 - Question (Julian): How did this team structure evolution tie in with the training of the BIOS teams?

00:55:52 - Question (David): What were the motivational factors that made you appreciate James’s approach with LeSS? What problems or team dysfunctions did you see?

01:04:39 - Question (Joel): I’m curious what kind of training teams get before they change into a LeSS-like way of working?

01:12:17 - James discusses the importance of avoiding the contract game. (Tangent related to the training question.)

01:16:23 - Jerry comments on the importance of leadership buy-in.

01:18:24 - James and Mitya discuss leadership failures affecting the case study.

01:21:15 - Question (Samuel): Were there any key economic elements that could have been more directly connected to the adoption?

01:26:56 - Question (James): Was there any element of Mitya’s relationship with the hardware VP that impacted the political cover we enjoyed.

01:27:55 - Question (Samuel): What could have been done to establish a more direct connection to product management?

01:30:39 - Question (Julian): What might be done differently with the communications with, or around the new SVP/GM?

01:35:38 - Question (Vladimir): In what way was it a struggle to get the new VP on board? What was the new VP looking for?

01:56:14 - Question (Joel): How do I respond to a manager who is seeking to micro-manage a Scrum team?

02:04:21 - Question (Joel): Exploration of the “adoption vs transformation” spectrum.

02:08:15 - Question (David): Were there any metrics that you set out with?

02:13:00 - Question (Joel): Did the project eventually get completed, or did the whole product line fail?

02:13:39 - Question (Vladimir): What measurements were used to determine success and progress as well?

Join James and his mysterious co-presenter as they present highlights from a LeSS-Huge adoption effort at a large networking and server hardware company. After a quick walk-through of the case study excerpts, James and his co-presenter will focus on participant questions inspired by the extensive diagrams available in the pre-read content.

Colorful information rich context for the discussions is being provided in the many graphics found in the pre-read content. Nuances regarding challenges from executive management changes, clever requirement area boundary definitions, complex engineering challenges, and the political dynamics of a multi-national engineering organization can all be seen in the figures and captions provided in the pre-read content.

Samuel Brisson: the LeSS site has some general notes on the feature team adoption map - https://less.works/less/adoption/feature-team-adoption_map I like how James’ case study interprets this for the teams they were working with in context of the product

Joel Robinson - Redmond WA: I think domains like firmware where it’s believed agile isn’t appropriate ought to be challenged - in some cases, I bet there are good reasons and in others, I’d bet there’s potential to work incrementally / feedback-driven / etc. but it just hasn’t been tried / given a chance.

Joel Robinson - Redmond WA: Interesting to see HW VP more onboard than SW VP

Samuel Brisson: Joel, I agree - adaptiveness is a ‘keystone’ that seems to unlock so many other aspects of high value delivery

Bill Asch: HW VPs get the cost of rework… (my personal experience at Intel…9+ years)

David Nielsen: Logging questions and comments, keep them coming!

Julian Johnson: How did this team structure evolution tie in with the training to Bios Teams, specifically in helping to resolve “a few key team dysfunctions”?

David Nielsen : Q1:How did this team structure evolution tie in with the training to Bios Teams, specifically in helping to resolve “a few key team dysfunctions”?

Samuel Brisson : For Mitya: In retrospect, were there any key economic elements of this product that the Adoption strategy could have connected to more directly as a part of the product / tech team partnership?

Joel Robinson - Redmond WA: I’m curious what kind of training teams get before they change into a more Less-like way of working. I’m currently using Seattle Scrum Company’s video-based training to train very basic Scrum concepts, am assuming coaches and POs get training but I’m less (pun) sure about what kind of training to offer for Devs. 3-day LeSS practitioner training sounds like a big ask.

Joel Robinson - Redmond WA : Yes, and …

Samuel Brisson: Larman’s Laws of Organizational Behavior

Julian Johnson: What might be done differently with the communications with, or around the new SVP/GM? Wondering if there any retro on if any incremental steps that could’ve been taken up each layer of the org chart.

David Nielsen: https://less.works/trainers/craig-larman-as-a-trainer-8/courses

Joel Robinson - Redmond WA : We’re going to get about 50 people through 3-day LeSS training w/Michael James next month - including our CEO, directors, managers, POs, PMs, coaches, etc.

Joel Robinson - Redmond WA : That’s about 30% of our company

Jerry Lopez : That is EXCELLENT!!!!!!

Samuel Brisson: @Joel - huge win! that’s a big deal

Jerry Lopez: MJ is an awesome guy. Really like him.

Joel Robinson - Redmond WA : about 60% have finished his Scrum Training Series

Jerry Lopez : You are on track to something great.! Well Done!!

Walt Paulson : That is a GREAT first step to get a large mixed group!!!

David Nielsen : Q3: For Mitya: In retrospect, were there any key economic elements of this product that the Adoption strategy could have connected to more directly as a part of the product / tech team partnership

Joel Robinson - Redmond WA : I’d like to explore the “adoption vs transformation” spectrum - James’ comments about the change sounded kind of…abrupt

David Nielsen : Q4: (Julian) What might be done differently with the communications with, or around the new SVP/GM? Wondering if there any retro on if any incremental steps that could’ve been taken up each layer of the org chart.

Vladimir Bushin : and what actually happened when a new VP came?

Vladimir Bushin: not everybody believed in Scrum?

Vladimir Bushin: what new VP was looking for?

Joel Robinson - Redmond WA: I think that’s the hardest part of the job — winning the hearts and minds of hard-headed managers (I’m using that term instead of ‘leadership’ intentionally).

David Nielsen: Q5: (Joel) I’d like to explore the “adoption vs transformation” spectrum - James’ comments about the change sounded kind of…abrupt

Joel Robinson - Redmond WA: Regarding retaining/empowering the SW VP, I’m reminded of this quote: “”We cannot solve our problems with the same thinking we used when we created them.” — Albert Einstein

Jeff Hove: Did the project eventually get completed, or did the whole product-line fail?

Nissa Eberly: Hi All need to jump. Thank you.

Joel Robinson - Redmond WA: Feature lead times

Joel Robinson - Redmond WA: blood / effort = priority

Vladimir Bushin : was there something measured routinely every sprint besides number of bugs and velocity?

Joel Robinson - Redmond WA : Cost of delay > bug-free quality

Vladimir Bushin: how frequently have you released a new version to production?

Joel Robinson - Redmond WA: they’re still in business because they didn’t do all those things :-)

Vladimir Bushin: great session, thank you so much!

Vladimir Bushin: thank you for sharing your experience and helping us learn

Jeff Hove: Very interesting. Thanks.

Walt Paulson: Outstanding conversations!!! Thanks

James Carpenter

James is an expert in helping companies create effective engineering team structures and cultures.

Recent Articles

Hundreds of Millions In Annual Savings Realized

Billions In Lost Revenue Avoided

Economic View Of LeSS Case Study

LeSS In Arabic (ليس باللغة العربية)

Agile Approach: Case Study

Jul 11, 2014

610 likes | 1.49k Views

Agile Approach: Case Study. Chapter 3. Information Technology Project Management, Seventh Edition. Project Management Process Groups. Project management process groups include initiating processes planning processes executing processes monitoring and controlling processes

Share Presentation

• project charter
• project management process groups
• main activities
• generate business case
• final report

Presentation Transcript

Agile Approach: Case Study Chapter 3 Information Technology Project Management, Seventh Edition

Project Management Process Groups • Project management process groups include • initiating processes • planning processes • executing processes • monitoring and controlling processes • closing processes

Process Groups & Knowledge Areas • Process groups vs. knowledge areas • Knowledge areas cross the various process groups including some key distinctions Information Technology Project Management, Seventh Edition

Project Management Process Groups and Knowledge Area Mapping* Information Technology Project Management, Seventh Edition

Global Issues – India and Agile • A 2011 study of organizations across India included the following findings: • Agile Adoption Increasing • Significant Cultural shift for Agile • Paired Programming and Open Workspace are not popular Information Technology Project Management, Seventh Edition

An Informed Decision • It is not a snap decision whether to use an agile approach or not, just like flying or driving somewhere on a trip • The approach has to fit the culture, project, etc. at the organization to be successful.

PM Network: A Philosophical Makeover • Impact of Agile PM • Challenges of starting Agile • Best Practice? • Support

PM Network: The Sweet Spot • Beyond Software Development • Is it the right fit?

Agile Approach: JWD Consulting’s Project Management Intranet Site • An agile project team typically uses several iterations or deliveries of software instead of waiting until the end of the project to provide one product. Information Technology Project Management, Seventh Edition

Traditional Approach: JWD Project Management Intranet Site • Pre-Initiation • Generate Business Case (includes high level estimates on scope, cost, time, etc.) • Identify Sponsor and PM • Initiation • Project Charter • Stakeholder Identification Information Technology Project Management, Seventh Edition

Traditional Approach: JWD Project Management Intranet Site • Planning • Team Contract • Scope Statement • WBS • Gantt chart • Risks • Execution • PM acquires team then directs and manages work • Milestone reporting • Update progress (handle human resource issues) • Manage Communications • Ensure stakeholders remain engaged Information Technology Project Management, Seventh Edition

Traditional Approach: JWD Project Management Intranet Site • Monitor and Controlling • Change Control • Validate/Control Scope • Scheduling (forecasts) • Progress Reports • Closing • Final report and presentation • Client sign-off • Lessons-learned Information Technology Project Management, Seventh Edition

Scrum Roles & Artifacts • Scrum Roles • Product owner • ScrumMaster • Scrum team or development team • Artifacts • Product backlog • Sprint backlog • Burndownchart Information Technology Project Management, Seventh Edition

Scrum Ceremonies • Sprint planning session • Daily Scrum • Sprint reviews • Sprint retrospectives Information Technology Project Management, Seventh Edition

Scrum Framework and the Process Groups

Unique Scrum Activities by Process Group

Pre-Initiation and Initiation • Pre-Initiation and Initiation major tasks • # of releases and functionality by release • Sprints in release • Charter • Stakeholder Register • Kick-off Meetings

Planning • Similar to Traditional Process Groups • Differences

JWD Intranet Site Project Baseline Gantt Chart Using Scrum Approach 3 releases vs. 1 release Information Technology Project Management, Seventh Edition

JWD Product and Sprint Backlogs

Executing • Similarities to Traditional Process Groups • Differences Information Technology Project Management, Seventh Edition

Monitoring and Controlling • Similarities to Traditional Process Groups • Differences Information Technology Project Management, Seventh Edition

Figure 3-7. Burndown Chart Information Technology Project Management, Seventh Edition

Closing • Similarities to Traditional Process Groups • Differences: Information Technology Project Management, Seventh Edition

Chapter Summary • Project Management Process Groups • Main activities of each process group mapped to knowledge areas • Information technology project management methodologies • JWD Consulting – Predictive vs. Agile • Biggest Difference: providing three releases of useable software versus just one Information Technology Project Management, Seventh Edition

• More by User

HUD RHIIP Training – PH/HCV

HUD RHIIP Training – PH/HCV. Case Study 3 – Champion Family (Housing Choice Voucher). Champion Case Study:. Same process as Alexander and Bennett Topic presentation Students complete case study Using Appendix C, File Review Checklist Worksheets Students review PHA’s HUD 50058

1.28k views • 94 slides

USAFRICOM Case Study TRANSCOM JDPAC

UNCLASSIFIED. USAFRICOM Case Study TRANSCOM JDPAC. UNCLASSIFIED. (25 Feb 09). Overview. UNCLASSIFIED. Background Mobility Challenges Discussion Requirements Infrastructure DPS Extension. UNCLASSIFIED. Background. UNCLASSIFIED. Case Study Purpose

992 views • 42 slides

Zara- An MIS Case Study

Zara- An MIS Case Study. Using Technology to Succeed. The poor, ship-building town of La Coruña in northern Spain seems an unlikely home to a tech-charged innovator in the decidedly ungeeky fashion industry

2.2k views • 29 slides

GridWorld Case Study

GridWorld Case Study. Barbara Ericson Georgia Tech [email protected] Jan 2008. Purpose of a Case Study. Give students a larger program to study and extend context to apply inheritance and polymorphism Serve as an example of good design and coding practices

1.35k views • 64 slides

Case study: Kohler Co.

Case study: Kohler Co. . Private Company Valuation HBS Case. Methodology. Case summary Ratio Analysis Valuation: Income approach (DCF) Valuation: Market approach (Multiples) Discount for lack of control and marketability Valuation summary (intrinsic value per share). 2. Income approach.

2.48k views • 8 slides

Agile Modeling and Prototyping

Agile Modeling and Prototyping. 6. Systems Analysis and Design, 7e Kendall & Kendall. © 2008 Pearson Prentice Hall. Learning Objectives. Understand the roots of agile modeling in prototyping and the four main types of prototyping

2.37k views • 43 slides

1.05k views • 52 slides

Product Development: Case Study Overview

Product Development: Case Study Overview. Outline of Presentation. Key Steps for Quality by Design Case Study Organization Introducing API and Drug Product Discussion of concepts of Quality Target Product Profile, processes, composition Description of API & Drug Product process development

2.16k views • 41 slides

Sustaining Biodiversity: The Species Approach

Sustaining Biodiversity: The Species Approach. Chapter 9. Core Case Study: The Passenger Pigeon: Gone Forever. Once the most numerous bird on earth. In 1858, Passenger Pigeon hunting became a big business. By 1900 they became extinct from over-harvest and habitat loss.

1.34k views • 91 slides

OJ Simpson Case Study Compilation

OJ Simpson Case Study Compilation. SUPA Forensics Period 8. O.J. Simpson Case: Background. Sara Starr, Michelle Hao, Mariam Momjian, Rebecca Song, Tristan Jeong. Who was O.J. Simpson?. Born on July 9th, 1947 He was raised by his mother, along with three siblings

1.28k views • 81 slides

Agile Software Development using Scrum

Agile Software Development using Scrum. Derek Mathieson Group Leader Advanced Information System CERN – Geneva, Switzerland. Agenda. Traditional Software Development What is Agile? The Agile Manifesto Agile Methods SCRUM SCRUM @ CERN. Traditional Development. Waterfall Model.

1.17k views • 82 slides

Case studies in neuro trauma

Case studies in neuro trauma. Goals. Brief anatomy review Discuss important exam findings in brain and spine trauma Discuss key management principles in brain and spine trauma Case study of Epidural Hematoma Case study of Diffuse Axonal Injury Case study of Cervical Spinal Cord Injury.

1.19k views • 60 slides

Deby K. Samuels

Recent Portfolio. 2009. Deby K. Samuels. Contents. Case Study #1: D-to-C Electronic Marketing in Health Care Case Study #2 : Affinity Marketing Case Study #3: Brand Redefinition Case Study #4: Crisis Management Case Study #5: Video Messaging to impact behavior change

1.02k views • 64 slides

The Fiat-Chrysler Case Study

The Fiat-Chrysler Case Study. An overview of strategic alliances. Nicole McAdoo Dan Redman-Hubley Jan Rohweder. 02. Nov. 2011. Agenda. Background information on Fiat and Chrysler An in-depth look at the new alliance Questions proposed by the case study

3.33k views • 42 slides

Sustaining Biodiversity: The Species Approach. Chapter 9. Core Case Study: The Passenger Pigeon: Gone Forever. Passenger pigeon hunted to extinction by 1900 Commercial hunters used a "stool pigeon” Archeological record shows five mass extinctions

966 views • 71 slides

RURAL LAND RESOURCES

Caring and sharing the landscape. National Parks & other protection policies. PART 1-. RURAL LAND RESOURCES. CONTENTS. PART 2- Karst case study –Yorkshire Dales. PART 3- Coastal case study – Dorset coast. PART 4- Glaciation case study – Lake District. What is assessed in this unit?.

1.27k views • 104 slides

Introduction to Logical Structuring & Storyboarding

Introduction to Logical Structuring & Storyboarding. Agenda. Overview 10 minutes Writing the Introduction 30 minutes Case Study Working Out the Logic 60 minutes Case Study Grouping the Ideas 20 minutes Case Study Creating the Storyboard 110 minutes Break

3.73k views • 59 slides

Source: DPR

Virtual Design and Construction Case Study Martin Fischer Cristina Garcia Calvin Kam John Kunz Kathleen Liston Marcus Schreyer Vibha Singhal. Source: DPR. Virtual Design and Construction Case Study. Case Overview Baseline Delay Acceleration Summary and Analysis. Site Plan.

1.06k views • 84 slides

Semantic Web

Semantic Web. Applications. Where are we?. Agenda. Motivation Technical solutions and illustrations Dr. Watson Yahoo! SearchMonkey ACTIVE case study INSEMTIVES case studies LARKC case study Summary References. MOTIVATION. Motivation.

1.3k views • 107 slides

• Publishing Policies
• For Organizers/Editors
• For Authors
• For Peer Reviewers

Agile Internal Auditing – The Case Back To Normal

In a world of disruption and fast-paced changes, today’s internal auditing (IA) needs to be highly adaptive to changing risks. Agile work processes have speeded up product and software development processes and are rapidly spreading to other disciplines, very recently also to IA. This development has received little research focus so far, which leaves IA practitioners unguided in their attempts to become more adaptive. The present research project attempts to make knowledge explicit about context factors which influence how agile IA work processes are implemented and abolished. Specifically, it uses an explanatory grounded case-study approach to analyse the single case of a small IA function which has implemented Scrum for all of its IA work processes in 2015 and has returned to a regular approach in 2018. A within-case analysis identifies context variables which impact agile IA change processes decisively, namely the setup of the change process, the choice of the agile method and agile planning process, and the organization of teamwork and related communication processes. The study finds out that in an already fast-paced and innovative audit team, the implementation of Scrum is fostered by a collaborative involvement of the whole IA team and strengthens knowledge sharing and agility in return. In contrast, the implementation of a lean approach deteriorates the collaborative and communicative practices established by Scrum while the agile mindset of team members and the innovative drive of the team remain constant. These findings call for more agile IA case-studies to generate hypotheses based on cross-case analyses. Keywords: Internal auditing agile frameworks scrum case-study end of scrum agile certification

Introduction

In today’s VUCA world ( Bennet & Lemoine, 2014 ), where variability, uncertainty, complexity, and ambiguity reign, organizational risk management, control and governance processes must keep pace with our disruptive environment. Internal auditing (IA) is the independent, objective assurance and consulting activity designed to add organizational value by improving these processes (The IIA, 2017b). It must keep pace with or, better, anticipate rapid changes in order to fulfil its mission.

Research on how IA can cope with these challenges is scarce. The professional bodies of internal auditors (The IIA, 2019) and external service providers (PwC, 2019) describe what is happening at large scale in the IA profession by conducting surveys with descriptive statistics. The results indicate changes to IA processes. However, surveys with descriptive statistics are of little theoretical and practical value as far as the rich complexity of change processes is concerned and when IA professionals seek guidance on how to lead change and adapt to change in the best possible way.

This explanatory research study adds empirical evidence and case-grounded hypotheses to our common knowledge base of IA in times of disruption. Specifically, it analyses how and under which conditions an IA department has pioneered the implementation of agile frameworks for its audit work processes in 2015 and how it has returned to a more regular work approach in 2018.

Problem Statement

Rapid adaptation depends on conditions which can be called dynamics, fitness for change, or agility. The following literature review outlines the meaning of agility for IA and traces how the most audit relevant agile frameworks have developed and how they have impacted the work processes of IA functions. This leads towards the problem statement in the end of this section and to the research question in section 3 .

While agility is often described as a personal mindset, its organizational manifestation can be defined as the organizational capability to rapidly and pro-actively adapt to a VUCA world and changing customer needs (Schmitz, 2018).

This adaptive power is very core to IA. All ten Core Principles for the Professional Practice of Internal Auditing (The IIA, 2017a), which define IA effectiveness, require agility (Wilhelm, 2019a). Agile auditing is a set of practices that helps IA functions in meeting their objectives in a more wholesome manner, it is a mindset adopted by an IA team to focus on stakeholder needs, drive timely insights, accelerate audit cycles, generate less documentation and reduce wasted effort ( Foo & Bhattacharya, 2017b ).

According to practitioners, agility in IA processes has explicit manifestations (Wilhelm, 2019b), which are summarized in Table 01 . The table shows: agility in IA is not just a new buzzword but affects the core of IA work processes.

While these manifestations of agility in IA have been described by practitioners ( Coleman & Kasahara, 2019 ; Herbert, 2019; Pundmann et al., 2018 ; Wilhelm, 2019a; Wilhelm, 2019b), the academic research into agile IA practices is very thin. To date, there is only one academic case-study to this topic ( Foo & Bhattacharya, 2017a ), which shows the need for studies like the present one.

The following sections analyse agile frameworks which are most relevant for IA work processes.

Kaizen and Kanban

The most widespread agile framework in IA work processes today is Kaizen (Japanese for: change to the better). Its basic ideas were conceived as the Plan-Do-Study-Act-Cycle by US professor Walter Andrew Shewhart, and his student and later professor William Edwards Deming ( Moen & Norman, 2010 ). Their ideas spread rapidly in Japan, where industrial companies like Toyota agilized standardized mass production in the 1950s.

The basic idea of Kaizen is to establish and live a culture of continuous improvement, especially by reducing the three main inefficiencies of a process to make it “lean”: overcharging a process or a system beyond its capacity (“muri”), inconsistency in performance (“mura”), and wastes within the process (“muda”). Kaizen is translated into different schools of thought, such as Lean & Total Quality Management, Six Sigma or ultimately also the industrial norms of the ISO 9000 family of standards.

Kaizen is very often combined with Kanban (Japanese for: visual signal), a visual pull-system for just-in-time production which was first introduced by Toyota in the 1940s. In Kanban, workflows are visualized on boards with cards in columns, where each column represents a workflow step and cards represent tasks with a focus on the flow of work. According to the “muri”-principle, the maximum number of items in each workflow step are limited, the so-called work in progress (WIP) limit (Baig, 2019).

In IA, the Kaizen ideas of continuous improvement and waste elimination are well established. The IIA’s International Professional Practices Framework requires a quality assurance and improvement process (QAIP) for all IA functions (The IIA, 2017c). IA practitioners have long applied “muda” principles to their own work processes (see Table 02 ).

The first book on lean internal auditing was published in 2014 ( Paterson, 2014 ), while research on the application of different schools of thought of Kaizen in IA has been published already before. The role of IA in the implementation of total quality management systems, including an empirical survey on how audit work processes apply TQM principles, was a research topic already in 1998 ( Wilhelm, 1998 ). The topic how the work processes of IA can be compatible to certification according to the family of norms ISO 9000 was explored in 2011 ( Wilhelm & Wasmer, 2011 ).

The most recent and most fundamental agile framework that has been applied to IA work processes is Scrum. The expression Scrum and the underlying approach was invented by the two Japanese professors Hirotaka Takeuchi and Ikujiro Nonaka when they conducted a research study of new product development processes. They found out that successful companies in their study no longer use a sequential approach but employ a holistic method with a built-in instability, self-organizing project teams, overlapping development phases, multilearning, subtle control, and organizational transfer of learning ( Takeuchi & Nonaka, 1986 ). This approach was first applied to software development in 1990 ( DeGrace & Hulet, 1990 ) and became very popular after 1995, when the two US software developers Jeff Sutherland and Ken Schwaber codified Scrum as agile framework for software development and marketed it all over the world ( Rigby et al., 2016 ).

Scrum is, in short, a set of rules which organizes work processes in loops of improving trials and errors (so-called Sprints), running in largely self-organized teams with daily transparent progress updates (Daily Scrum). It allows to deal with complex, adaptive problems and fosters continuous learning and naturally adjusting to changing conditions (Wilhelm, 2019a). Scrum incorporates aspects of Kaizen because its rules demand a regular inspection of the work done (Sprint Review) and a regular brainstorming on what went well and what needs to be improved (Sprint Retrospective). It implies aspects of Kanban as it works with a task board, on which the overall list of tasks to-do (Product Backlog), the list of tasks to-do during the next sprint (Sprint Backlog), as well as tasks in progress (Doing) and finished tasks (Done) are visually tracked. In contrast to Kanban, Scrum has specific roles, namely a keeper of the rules (Scrum Master), a person who is responsible for the emerging product, prioritizes the Product Backlog and links to the customer (Product Owner), as well as a self-organized project team which does the work (Scrum Team). Scrum does not know an explicit limit for work-in-progress as Kanban does but has its Scrum Team, jointly with the Product Owner, estimate its capacity and the amount of work to be done in the next sprint. Scrum has more elaborate rules, which is why Kanban is easier and faster to implement and can be applied more widely. Scrum has more disruptive power and can unleash more agile potential (Wilhelm, 2019b).

The first research endeavour to mention Scrum in relation to auditing was published in 2014 ( Wright, 2014 ). The book is written as an overview for auditors and agile teams over agile governance and audit. It bridges the knowledge gap between agile software development teams and auditors (internal and external) because back then auditors and agile teams knew little about each other’s work practices, goals and concerns. While its foreword mentions a number of (external?) audit teams looking at agile techniques and tools to plan and undertake their own audit work, the book focuses on the governance and audit of agile software development processes and does not deal with how agile frameworks can be applied to IA work processes.

The first documented application of Scrum in IA work processes happened at the IA department of the Swiss Accident Insurance Trust Suva in March 2015, the start of a full-fledged implementation of Scrum to all IA work processes (Wilhelm, 2017a, 2017b). Since then, the number of IA functions that “went agile” has proliferated. Practitioners have recently picked up the topic, with the first practical guide on how to do lean and agile auditing published this year ( Coleman & Kasahara, 2019 ). Also, external service providers (Pundmann et al., 2018) and software companies (Herbert, 2019) have started to position themselves in anticipation of the rapidly growing market of agile IA transformations.

Standard academic books of IA are already mentioning the term “agile”, which appears nine times in the IIA Research Foundation’s standard book Sawyer’s Internal Auditing ( Clayton, 2019 ). However, the advice there is that internal auditors should follow their agile organizations and build up knowledge of agile frameworks in order to be able to audit them. The books do not yet mention or advise on the implementation of agile IA work processes. The first research study on Scrum in IA is a case-study on the IA function of DBS Bank in Singapore ( Foo & Bhattacharya, 2017a ). In the case-study, DBS IA implements Scrum in pilot audit projects. A Sprint Team comprised the usual Scrum roles Scrum Master and Product Owner and only one auditor plus members from all stakeholder teams, namely also process improvement executives, user representatives, and project managers from line management ( Foo & Bhattacharya, 2017a ).

According to that case-study, DBS IA has adopted their agile approach to avoid the disruptive effects of a full-scale agile adoption. Speaking in the classification of agile IA approaches summarized in Table 03 , the DBS case-study exemplifies an IA Project Scrum, where the agile approach is limited to single audit projects and is not comprising all IA activities.

The application of agile frameworks, especially Scrum, in IA work processes is a relatively new phenomenon which has not yet been adequately covered by academic research. Specifically, there is up to date no research study which has analysed an IA function that lives a full-fledged agile approach, an IA Function Scrum, for all its IA work processes. This appears to be the more urgent, the more agile IA work processes get adopted throughout the world of IA, as it is currently the case.

Research Questions

Given the large number of IA functions in transition from traditional to agile work approaches, the specific research question for this study is:

How can the change of an IA function related to agile IA work processes be influenced?

Purpose of the study.

The goal of business administration as applied science is not only to generate new knowledge but also to support practitioners in the field, in this case active internal auditors and chief audit executives (CAE).

Research Methods

The choice of a ‘how’ research question indicates an explanatory research approach which tries to build theory by answering the research question.

Ontological, epistemological, and methodological position

This research project assumes a post positivistic ontological position, in other words it takes it for granted that reality exists in a complex nature that cannot be fully understood by the limited human mind. As a consequence, the best way to understand reality is to critically examine claims about it. As epistemological position, which concerns the nature of the relationship between researchers and their knowledge about reality, this project accepts the existence of dependence between researcher and research object but upholds objectivity of the researcher as ideal that must be controlled by means of critical questioning or peer review. This is especially important as the author is also an IA practitioner with a large experience and personal convictions about the IA profession and the present case. Methodologically, the study applies modified experimental and manipulative methodologies which are supported by triangulation of perspectives and are based on empirically grounded data derived from natural, situational settings. Research projects with a post positivistic position see theory construction as scientifically equal to theory testing, consider empirically grounded contextual variables and focus also on human behaviour and its aspects, thus trying to bridge the gap between individual cases and generalizations ( Guba & Lincoln, 1994 ).

Single case-study research design

This study chooses a single case-study research design in its attempt to answer the research question of a case with an unusual outcome, which underlines the suitability of this design ( Ragin, 2000 ). Such a case-study research design starts with data collection, namely writing a case-study on an IA function that has pioneered the implementation of IA Function Scrum in its IA work processes. It aims at developing explanations by finding general patterns in the case observations, which are considered in their context and are obtained and described with the help of interviewed respondents who provide also clues about the meaning of behaviour.

Grounded case-study approach for within-case analysis

Within-case analysis of the data was done following the methodological procedures of the grounded case-study approach by Wilhelm ( Wilhelm, 2005 ), adapted for the single case-study approach of this study. It starts with data collection in semi-structured, problem-centered interviews, which are methods of data collection that are suitable for case-specific complexity.

The case of an IA department going agile and returning back to regular work processes was selected because of its obvious fit to the research question. Table 04 summarizes key criteria for the initial selection.

Data collection is based on two interviews of 90 and 76 minutes length, covering the IA Scrum roles Scrum Master and Team Member. The interviews were recorded and transcribed, entered into a case-study database and are turned into a grounded case summary with the help of summarizing content analysis.

In the data of the case-study of FICO’s IA, the empirical data can be structured into categories which have emerged as influences on the implementation of agile work processes. They are summarized in the following sections.

Background and change process

Before going agile, FICO’s IA employed a classical audit approach where an annual plan was established, decided for each year, then worked off in individual black-box audit projects. The way how agile work process were implemented played an important role. Mental speed has already been IA’s key success factor and has allowed it to successfully overcome organizational hostility during the past seven years. The CAE and his team had already implemented several innovations such as dedicated consulting and data analytics teams or a database of findings and recommendations replacing traditional audit reports. After years of trying out in vain audit work process software solutions to find satisfactory IA work processes, the CAE brought forward his agile idea. His five-person team’s reaction reached from change fatigue to deep interest in a new potential solution. What followed was a time of intensive reading by those interested. The CAE communicated his wish to give the idea a try and gave every member of his audit team the chance to veto against it – which nobody did. In March 2015, they decided to go agile. They organized a training workshop for agile methodologies and their implementation in IA to get the knowledge about agile work. The workshop was given by a Tunisian agile coach experienced with software development. It introduced agile frameworks and Scrum, had practical exercises to strengthen the knowledge, and placed its focus on finding a solution on how to adapt agile to IA. Having a professional coach saved a lot of time because of his idea of agile opportunities. He helped to structure the discussions and represented ideas visually. As the coach knew only agile software development, he did not speak the language of internal auditors and therefore the IA team autonomously transferred his ideas into the IA world. At the end of this two-day workshop, every IA team member became certified as Certified ScrumMaster. Whereas several team members were initially rather sceptical, the course sparked their enthusiasm and willingness to try living Scrum. The IA team had decided to use Scrum for all IA processes because also support processes and links to other processes like planning, education or data analytics are relevant for the core audit processes. They felt that the more pervasive Scrum was applied, the better will be the prioritization of tasks. What follows was a period until June 2016 in which the IA team used trial and error and cut its annual plan into pieces until manageable tasks were found as items on the Product Backlog.

In this initial phase, Scrum met much resistance within the IA team. People were used to know in the beginning of a year what audits they will perform. The idea to meet every day and every two weeks to plan anew how little chunks of work can be done took away planning security for the individual auditor. Astonishingly, people with a very structured accounting profile who appeared to be rather inflexible coped with the change process very well whereas other team members had severe concerns and, at one time, tried even to work out an alternative work model which followed a waterfall project method. In intensive team discussions and with the strong dedication of the CAE, the IA team tried to find “their Scrum” and the right aggregation of tasks. Very quickly, working with Scrum became the normality for FICO’s IA team. The agile method lost its initial attraction and became routine. The IA team started to feel well with this new way to work. In this phase, instead of individual motivation the strong structures of Scrum carried the system forward: the sequence of institutionalized exchanges in daily and bi-weekly meetings and the included continuous improvement process. When the CAE left the company, a new CAE was appointed out of the IA team, who happened to be a proponent of the waterfall project and lean management methods. The new CAE aimed at making the Scrum work process leaner, which is why – after a transition phase of one year – he eventually changed the IA Scrum work processes back to a regular IA approach with a Kanban board in 2018.

Agile method, audit planning, and innovation

In the Scrum approach, especially the definition of work packages proofed to be difficult. A too fine-grained planning of Scrum tasks consumes a lot of preparation time and is felt by some auditors as pressure. Due to the interdependencies outside of IA’s control, it often turns out to be in vain. Agile audit gets more transparent but often not much quicker when the auditee and data access do not work in an agile way.

One and a half years after FICO’s IA had fully implemented Scrum, the new CAE abolished the regular team meetings, the role of a Scrum Master and self-organization of the audit team. Instead, there were biweekly regular team meetings without an agile rule setup. A conventional Kanban board as a general to-do list, a special to-do-list for the next two weeks as well as columns with “doing” and “done” were retained. The process became leaner but also less agile as fast changes were no longer done and team members did no longer bring in new requests in an agile way. During the Scrum approach, IA had still kept the traditional annual planning process where the AC decides on a yearly plan. This was a trade-off made to develop IA Scrum in an incubator mode without AC involvement. The new CAE arranged with the AC to introduce a half-yearly planning. As a consequence, the audit plan was executed closer to its initial risk assessment. Also, according to the regular audit approach, internal auditors were no longer multi-tasking in several audits but worked at one audit at a time. Audit planning became more rigid as the audits had to be finished punctually twice a year instead of once a year. Given the fixed end dates and less flexibility of a one-auditor-one-audit approach, agility inside individual time-boxed audit projects became more difficult because many auditees were rather inflexible and favoured a planned inflexible audit approach whereas agile auditing would have required quick access and quickly scheduled interviews during the time-boxed audits.

Regardless of the audit approach, where an audit is broken down into tasks there is the risk to intellectualize the audit work – it is already difficult to formulate a good task but it takes an enormous planning effort and has doubtful chances for success to plan the ideal backlog first and then implement it as it is.

FICO’s IA team had always spent a lot of time for innovation. The introduction of Scrum has supported this innovative spirit because in an IA Function Scrum innovation was treated as a normal task and there was no difference between innovative tasks and regular work tasks. Both types of tasks were included in the normal work process, which was very helpful. The team managed to develop an agile mindset which led to more discussions and innovation debates compared to before the introduction of Scrum. This mindset stayed also after the restitution of a regular work process and was nourished by a constant inner urge to be agile and to stay innovative, no matter if agile was lived or not in the work process.

Organization of teamwork

In the Scrum and the conventional Kanban approach, the decision what the end result must be is taken top-down. The CAE is the place, irrespective of the approach, where the full responsibility remains.

Before FICO’s IA changed to Scrum, the individual auditors had limited contact with each other. Once the annual audit plan was decided, the projects were distributed by the CAE and if no urgent question or resistance came up, the auditor could execute the whole allocated audit project without any contact to the team or the CAE. This was satisfying for individual experts and granted them a lot of freedom. Teamwork, transparency and sharing knowledge were limited.

When FICO’s IA changed to Scrum, a self-organized team gained the freedom of implementation and could freely decide who does what task and how. The individual auditors had their specializations which played a large role on the choice of tasks each one made. Each auditor worked together with other auditors and according to the circumstances there were mixed and changing teams within a single audit. Auditors were multi-tasking in several audits and tasks of other IA processes such as education, management or quality improvement. Most audit projects were completely unique green field approaches, derived solely out of the IA team’s risk assessment. Every second week, the IA team critically discussed its active projects and decided if action should be taken and if the initial goals were still justified.

When FICO’s IA changed back to a conventional Kanban work process, the auditors could pronounce their work preferences in a meeting but the CAE decided over the distribution of labour. With a lean approach in mind, the new CAE strived for a strong standardization of the audit process. Templates with process and content checklists were introduced that had to be closely followed in each audit, with any deviation to be explained in detail. One team member was appointed as quality controller to make sure the templates were filled in and the individual steps were all kept in every audit project. It stayed in the discretion of the individual auditor to add additional content, however due to the time-boxed setup working off the checklists had the priority. Fulfilling the audit plan became the priority whereas reaching unique value added used to be the priority before. The Scrum Master’s usual role is to take away impediments so that the development team can concentrate on their work. Most impediments in IA stem from sources external to the IA function, which is why the possibilities of a Scrum Master as regular IA team member are limited. If the team members are not content with the work approach, the Scrum Master frequently receives negative feedback and is in a double role in between the CAE and the team. After the FICO’s IA changed back to a conventional Kanban work process, the Scrum Master role was abolished.

Communication and customer focus

For FICO’s IA team, the customer focus remained constant irrespective of the work approach because it is linked to the proactiveness of every individual auditor. The relation to auditees was coined by interviews and feedback questions, no matter if the audit approach was agile or not. With Scrum, the communication became more structured and daily communication routines were formalized. The team members knew that they will see each other in and around the next daily Scrum meeting so they tended to use the formal time to exchange instead of spontaneous office visits. Inside the audit team, discussions were very intensive, before, during and after Scrum. The intensive exchanges in formal Scrum meetings made especially sense when every team member felt as real part of the project. In the IA Function Scrum, the team often talked every day about very different topics. In such a situation, the limited mutual influence of team members on each other turns the exchange less vital. In contrast, in an environment where one task influences the other and where there is real collaboration, feedback from colleagues is more interesting and the formal meetings allow to share topical knowledge and not only to gain insight into the work of the team in terms of organizational information about where a colleague is and what he does. Before Scrum, FICO’s IA had already replaced their formal IA report with a database of findings and recommendation and kept formal presentations to a minimum, therefore Scrum did not have a large impact on reporting. However, the IA team had decided to balance the speed of quick reports with the need to wait until interrelated findings can be linked, which may appear during different phases of the audit. In addition, having too frequent reports carries the risk of confusion and a loss of time due to avoidable discussions with auditees.

This case-study is the first research project to examine the introduction of an IA Function Scrum in an IA function. In addition, it is the first case-study about an IA function which has returned back to a regular work approach after having implemented an agile framework. The data is highly contextual and specific to the individual case of an IA team that used to be already fast-paced and innovative before implementing agile frameworks. It indicates how sets of context variables influenced the agile change of FICO’s IA function. Thanks to the rich contextual descriptions, a comparison of context variables will allow to infer general conclusions for IA change processes in other environments.

The within-case analysis has identified the setup of the change process, the choice of the agile method and agile planning process, and the organization of teamwork and related communication processes as relevant influencers of agile change. It shows that the collaborative involvement of the whole IA team has facilitated the implementation of Scrum. The implementation process was supported by the motivating dedication of the CAE as well as by an agile workshop led by an external coach and the included certification of the whole IA team. After the initial enthusiasm became less, the new work processes were backed by the strong routines of the Scrum approach. FICO’s IA team has repeatedly adapted these routines to their specific needs and has thereby applied the principle of trial and error to the implementation process. Scrum has increased the transparency over IA work processes and it has strengthened knowledge sharing and agility in the IA team. It turned out challenging in terms of finding the right task size and striking a balance between fast reporting and considering interdependencies of findings. The strong structure of Scrum has created its own inefficiencies, thereby paving the way to its abolition in favour of a leaner approach. FICO’s leaner approach was successfully rolled out in a strictly top-down manner and has replaced Scrum. It has deteriorated the collaborative and communicative practices established by Scrum. However, it has consistently preserved the agile mindset of team members and the team’s innovative drive.

The most decisive factor for the implementation of Scrum and for its replacement by a leaner approach were individual preferences of the CAEs and their ability to overcome resistance in the team. The collaborative implementation of Scrum was well aligned to its collaborative nature and allowed to spark enthusiasm and commitment in the IA team. Over time, this drive ceded to a more bureaucratic application of the strong structural processes of Scrum. Agile work processes tended to become tedious and time consuming routines. The top-down implementation of a leaner approach counteracted a collaborative spirit and did not cause open resistance but tended to create emotional withdrawal and a work-to-rule spirit. After the restitution of less-agile work processes, a strengthened agile mindset and innovative drive remained unchanged. This shows that agility is more than a question of designing work processes but affects organizations primarily as a mindset shared by individuals and teams. FICO’s agile audit case calls for more research into how different agile audit work processes succeed in different organizational settings. Specifically, it will be interesting to see how IA can keep up the momentum of agile work processes without getting stuck in agile structures and bureaucracy. Based on a variety of empirically grounded cases, multi-case analysis will allow a cross-case analysis emancipated from individual preferences. This will ultimately lead to the discovery of options for practitioners who plan to change their IA teams towards more agile work processes.

• Baig, M. S. (2019, November 28). A (Very) Short History of Kanban. https://www. researchgate.net/publication/332571187_kanban
• Bennet, N., & Lemoine, G. J. (2014). What VUCA Really Means for You. Harvard Business Review, 92. https://hbr.org/2014/01/what-vuca-really-means-for-you
• Clayton, D. (2019). Sawyer’s Internal Auditing: Enhancing and Protecting Organizational value. Altamonte Springs: Internal Audit Foundation.
• Coleman, P., & Kasahara, S. (2019). Active Auditing – A Practical Guide to Lean & Agile Auditing. Amazon Kindle: Coleman.
• DeGrace, P., & Hulet, S. L. (1990). Wicked Problems, Righteous Solutions: A Catalogue of Modern Engineering Paradigms. Upper Saddle River: Prentice Hall International.
• Foo, S. L., & Bhattacharya, L. (2017a). Agile Auditing at DBS: Embracing the Future. Case-Study. Boston: Harvard Business Press.
• Foo, S. L., & Bhattacharya, L. (2017b). Agile Auditing at DBS: Embracing the Future. Case-Study Teaching Note. Boston: Harvard Business Press.
• Guba, E., & Lincoln, Y. S. (1994). Competing paradigms in qualitative research. Handbook of qualitative research, 105-117.
• Herbert, G. (2019, May 31). Dynamic Auditing. Presentation at the SOPAC 2019. http://iia.org.au/sf_docs/default-source/sopac-2019/delegate-copy-presentation-session-8d-dynamic-auditing-keeping-pace-in-the-now-environment.pdf?sfvrsn=2
• Moen, R., & Norman, C. (2010). Circling Back – Clearing up myths about the Deming cycle and seeing how it keeps evolving. Quality Progress, 22-28.
• Paterson, J. C. (2014). Lean Auditing: Driving Added Value and Efficiency in Internal Audit. Wiley.
• Pundmann, S., Adams, S., & Narayanan, R. (2018, February 2). How Agile Internal Audit Can Add Value. https://deloitte.wsj.com/cfo/2018/02/02/how-agile-internal-audit-can-add-value/
• PwC. (2019, November 6). 2019 Global State of the Internal Audit Profession Study. https://www.iianz.org.nz/Site/news/all-news/2019-state-of-internal-audit-profession.aspx
• Ragin, C. (2000). Fuzzy-Set Social Science. University Press.
• Rigby, D., Sutherland, J., & Takeuchi, H. (2016, April 20). The Secret History of Agile Innovation. Harvard Business Review. https://s3.amazonaws.com/media.loft.io/attachments/ The_Secret_History_of_Agile_Innovation.pdf
• Schmitz, A. (2018, November 15). Agiles Arbeiten – Worüber reden wir hier überhaupt? Präsentation an der BGM-Fachtagung der ZWW, Universität Bielefeld. [Agile work – what are we talking about? Presentation at the ZWW conference, University of Bielefeld]. https://www.bgm-bielefeld.de/downloads/ws181115bgm31415.pdf
• Takeuchi, H., & Nonaka, I. (1986). The New New Product Development Game. Harvard Business Review, 37-146.
• The IIA. (2017a, November 5). Core Principles for the Professional Practice of Internal Auditing. https://na.theiia.org/standards-guidance/mandatory-guidance/Pages/Core-Principles-for-the-Professional-Practice-of-Internal-Auditing.aspx
• The IIA. (2017b, November 5). Definition of Internal Auditing. https://na.theiia.org/standards-guidance/mandatory-guidance/Pages/Definition-of-Internal-Auditing.aspx
• The IIA. (2017c, November 5). International Standards for the Professional Practice of Internal Auditing (Standards), 7-9. Retrieved from https://na.theiia.org/standards-guidance/mandatory-guidance/Pages/Standards.aspx
• The IIA. (2019, November 6). Pulse of Internal Audit Reports. The Audit Executive Center. https://www.theiia.org/centers/aec/Pages/pulse-of-internal-audit.aspx
• Wilhelm, P. (1998). Die Rolle der Internen Revision bei der Umsetzung einer TQM-Strategie (Diplomarbeit). [The Role of Internal Auditing during the implementation of a TQM strategy]. (Master Thesis). University of St. Gallen.
• Wilhelm, P. (2005). Power in Change Management (Doctoral dissertation). Antonym.
• Wilhelm, P., & Wasmer, S. (2011). Qualitätssicherungsprozess bei der Suva – IIA-Qualitätsprogramm und ISO 9001:2008. [Quality Assurance Process at Suva – IIA-Quality Programme and ISO 9001:2008]. Der Schweizer Treuhänder 9, 732-737.
• Wilhelm, P. (2017a, September 21). Agile Audit Planning. Presentation at the ECIIA Conference Basel, Switzerland.
• Wilhelm, P. (2017b, November 10). Agile Audit Planning. Presentation at the IIA Baltic Conference 2017, Riga, Latvia.
• Wilhelm, P. (2019a, July 9). Agile Internal Audit Processes. Presentation at the International Global Conference 2019 of The Institute of Internal Auditors, Anaheim, California.
• Wilhelm, P. (2019b, September 26). Agilität und ihre Anwendung in der Internen Revision. [Agility and its Application in Internal Auditing]. Presentation at the 38th Annual Conference of the IIA Austria, Schloss Schönbrunn, Vienna.
• Wright, C. (2014). Agile Governance and Audit – An overview for auditors and agile teams. IT Governance Publishing.

Copyright information

About this article

Publication date.

13 February 2021

Article Doi

https://doi.org/10.15405/epsbs.2021.02.16

978-1-80296-100-3

European Publisher

Print ISBN (optional)

Edition number.

1st Edition

National interest, national identity, national security, national consciousness, social relations, public relation, public organizations, linguocultural identity, linguistics

Cite this article as:

Wilhelm, P. (2021). Agile Internal Auditing – The Case Back To Normal. In C. Zehir, A. Kutlu, & T. Karaboğa (Eds.), Leadership, Innovation, Media and Communication, vol 101. European Proceedings of Social and Behavioural Sciences (pp. 173-185). European Publisher. https://doi.org/10.15405/epsbs.2021.02.16

We care about your privacy

We use cookies or similar technologies to access personal data, including page visits and your IP address. We use this information about you, your devices and your online interactions with us to provide, analyse and improve our services. This may include personalising content or advertising for you. You can find out more in our privacy policy and cookie policy and manage the choices available to you at any time by going to ‘Privacy settings’ at the bottom of any page.

Manage My Preferences

You have control over your personal data. For more detailed information about your personal data, please see our Privacy Policy and Cookie Policy .

These cookies are essential in order to enable you to move around the site and use its features, such as accessing secure areas of the site. Without these cookies, services you have asked for cannot be provided.

Third-party advertising and social media cookies are used to (1) deliver advertisements more relevant to you and your interests; (2) limit the number of times you see an advertisement; (3) help measure the effectiveness of the advertising campaign; and (4) understand people’s behavior after they view an advertisement. They remember that you have visited a site and quite often they will be linked to site functionality provided by the other organization. This may impact the content and messages you see on other websites you visit.

• Get started Get started for free

Figma design

Design and prototype in one place

Collaborate with a digital whiteboard

Translate designs into code

Get the desktop, mobile, and font installer apps

See the latest features and releases

• Prototyping
• Design systems
• Wireframing
• Online whiteboard
• Team meetings
• Strategic planning
• Brainstorming
• Diagramming
• Product development
• Web development
• Design handoff
• Product managers

Organizations

Config 2024

Register to attend in person or online — June 26–27

Creator fund

Build and sell what you love

User groups

Join a local Friends of Figma group

Learn best practices at virtual events

Customer stories

Read about leading product teams

Stories about bringing new ideas to life

Get started

• Developer docs
• Best practices
• Reports & insights
• Resource library
• Help center

Figma Case study templates

Present your project in pre-built editable templates to get you started.

UX Case study template

UX Case Study Template made to help UX Designers create and organize their case study without any struggle.

Case study presentation template

Case study presentation to frame key insights and outcomes.

Long form research case study template with customizable styles.

Design presentation deck

Modern design deck template with multiple sections.

Visual portfolio template

Modern visual portfolio template with 12 column grid and light and dark themes.

Behance Presentation Template

Case study template with multiple components, visual styles and frame sizes.

Case study template

Case study template with pastel style coloring.

Holistic Case Study Template

Case study presentation template complete with project overview, wireframes and key journey insights.

Case study presentation layout for interview

Case study template with multiple app UI screens.

Portfolio UI - Web & Mobile

A portfolio UI for designers and developers which has 4 unique pages includes blog, case study.

Apple device mockups

Complete Apple device mockup screens for iPhone, Mac, iPad and Apple Watch.

Explore 1,000+ templates on the Figma community

Explore even more templates, widgets, and plugins—all built by the Figma community.