Scaling Agile to Large Globally Distributed Organizations

Aug 2nd 2016Casper Lassenius & Maria Paasivaara

Agenda

• Introduction

• Session 1: Large-Scale Agile Transformations

• Session 2: Scaling Agile

• Summary and Discussion

Introductions and Expectations

Introductions

• Who are you?• Your background?• What are your

expectations? What would you like to learn today?

What is Large-Scale in Agile?

Large-Scale Agile

• Software development organization size– > 50 people – Not all 50 people need to be

developers• Scrum masters• Architects• Product owners• …

OR– at least 6 teams

• Common– Product or project– > Need to collaborate

Finland

HungaryUS

Large-Scale Agile Transformations

Systematic Literature Review

• 52 papers– 46 experience reports, 6 research papers

• 42 industrial cases

Literature: Business Areas of Published Cases

Literature: Agile Methods Used

Cases We Have Studied

• Ericsson– Telecom networks– Case 1: over 400 persons, 25-40 teams, 2-3 sites, 10 year old product– Case 2: from two teams to 200 persons, 5 sites, newly acquired product

• Nokia– Telecom networks– Case 1: from 2 teams to 170 persons, 4 sites, new product– Case 2: old product + newly acquired product, several sites

• F-Secure– Security software– Case: 10-14 teams, 140 people, 3 sites, new product version

• Tieto– Energy software– Case: 7 teams, 40 (190) people, 2 sites, 10 year old product

Reasons to Adopt Agile at Scale

Why Go Agile at Scale?- Teamwork

Reasons to go Agile in the Large

Business

• Reducing the time to market

• Delivery too slow

• Must change to remain competitive

• Customers demand faster delivery

• Accommodating change

Management

• Project management challenges

• Command and control management style

• Schedule and estimation challenges

Process

• Process overhead

• Process nonconformance

• Late integration, testing and feedback

• Challenges in integrating agile teams into the process

• Old process does not scale

• Quality problems

Organizational

• Organizational silos hinder collaboration

• Lack of customer collaboration

Transformation Types

• A: Top-down big-bang• B: Step-wise top-down• C: Step-wise top-down-

bottom-up • D: Step-wise bottom-up

Challenges in Large-Scale Agile Transformations

What is Challenging when Adopting Agile at Scale?

- Teamwork

Challenges (1/2)

Change resistance

•General change resistance

•Skepticism towards agile

•Resistance towards top-down mandate

•Management unwilling to change

Lack of investment

•Lack of coaching•Lack of training•Too high current workload

•Old commitments kept

•Challenges in rearranging physical spaces

Agile difficult to implement

•Misunderstanding agile concepts

•Lack of literature guidance

•Poor customization•Reverting to old way of working

•Excessiveenthusiasm

Coordination of multiple teams

•Interfacing between teams difficult

•Autonomous team model challenging

•Global distribution challenges

•Achieving technical consistency

Different emergent approaches in multi-team environment

•Teams interpret agile differently

•Old and new approacvhes used side by side

Challenges (2/2)

Hierarchical management and org. boundaries

• Middle managers’ role in agile unclear

• Management in waterfall mode

• Keeping the old bureaucracy

• Internal silos kept

Requirements engineering

• High-level RE largely missing in agile

• Requirement refinement difficult

• Creating and estimating user stories is difficult

• Gap between long and short-term planning

QA & Testing

• Accommodating non-functional testing

• Lack of automated testing

• Requirements ambiguity affects QA

Integrating non-development

functions

• Other functions unwilling to change

• Challenges in adjusting to incremental delivery pace

• Challenges in adjusting product launch activitiesRewarding model not teamworkcentric

Success Factors for Large-Scale Agile Transformations

4/28/2017 Laitoksen nimi

20

What Can You Do to Succeed in a Large-Scale Agile Transformation?

- Teamwork

Success Factors (1/2)

Management support

•Ensure management support

•Make management support visible

•Educate management on agile

Commitment to change

•Communicate that change is non-negotiable

•Show strong commitment

Leadership

•Recognize importance of change leaders

•Engage change leaders without baggage of the past

Choosing and customizing the agile approach

•Conform to a single approach

•Customize the agile approach carefully

•Mapping to the old model eases adoption

•Keep it simple

Piloting

•Start with a pilot to gain acceptance

•Gather insights from a pilot

Success Factors (2/2)

Training and Coaching

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

Engaging people

•Start with agile supporters

•Include persons with previous agile experience

•Engage everyone

Communication and transparency

•Communicate the change intensely

•Make the change transparent

•Create and communicate positive experiences in the beginning

Mindset and Alignment

•Concentrate on agile values

•Arrange social events

•Cherish agile communitiesAlign the organization

Team autonomy

•Allow teams to self-organize

•Strive for grass roots level empowerment

Requirements management

•Recognize the importance of the PO role

•Invest in learning to refine the requirements

Questions?

Scaling Agile – Practices for Large-Scale Agile Implementation

4/28/2017 Laitoksen nimi

25

What Needs to be Scaled?

- Teamwork

What Needs to be Scaled?

• Product ownership and planning– How to divide work between teams?

• Teams & inter-team coordination– How to scale the experts?– Global distribution? Distributed vs. Local teams

• Work spaces and infrastructure

Agile mindset more important than practices and tools!

Scaling Frameworks

• Large Scale Scrum (LeSS)• Scaled Agile Framework (SAFe)• Disciplined Agile Delivery (DAD)• Nexus • Recipes for Agile Governance in the Enterprise (RAGE)• Spotify model• Drive Strategy Deliver More (DSDM)• …

Product Ownership and Planning

How to Scale the Product Owner role?

- Teamwork

Product Owner Structure in Nokia

Product Owner

Product Manager

LineManager

ProjectManager

Area Product Owner (APO)

SolutionArchitect

SystemArchitect

1-n APOs

1-n teamsper APO

Product Owner Structure in Ericsson

Product Manager

ChiefProduct Owner

ProductOwner

ProductOwner

Product Owner

1-n PPOs

Smallfeature

Smallfeature

Largefeature

Planning

Joint Release Planning at F-Secure

• 10-14 teams• 2-3 days planning• 2-4 month release• Videoconference

Continuous Planning at Ericsson

• 1-2 week cycle time• One pager• FCS= Feature Concept Study• F0, F1, F2 decision points

Teams & Inter-team Coordination

When to Use Distributed / Collocated Agile Teams?

- Teamwork

Distributed Scrum Teams at Tieto

• Norway - Malaysia• Knowledge differences

between the sites• Daily Scrum

(teleconference)• Weekly SoS• Retros, Demos• Frequent visits• Visiting engineer• Onsite system expert

How to Arrange Inter-team Coordination?

- Teamwork

How to Arrange Inter-team Coordination?

• Mindset more important than practices!!– Teams responsible for

coordination

• Practices:– Scrum-of-Scrums– Communities of Practice– Common Release / Sprint

Planning– Common Demo– Common Retrospective

What is a “Community of Practice”?

• Communities of practice have three important characteristics that sets them apart from other communities:

– The domain defines the area of interest in which the members collaborate to share and create knowledge.

– The community aspect means that members actively engage in joint activities, form relationships with each other, and share information.

– The practice aspect means that they develop a shared set of resources for addressing problems in their domain of interest.

A community of practice, is a group of people who share a concern, a set of problems, or a passion about a topic, and who deepen their knowledge and expertise in this area by interacting on an ongoing basis (Wenger et al.)*

* Ref. E. Wenger, R. McDermott, W. M. Snyder, Cultivating Communities of Practice, Harvard Business Review Press, Cambridge, MA, 2002.

CoPs at Ericsson

• Over 20 CoPs• Examples:

– Scrum Master / Coaching CoP– Feature CoPs– Developers’ CoP– End-to-End CoP– Functional Verification CoPs– Continuous Integration CoP– ….

Characteristics of Successful CoPs

5. Open community

8. Cross-site participants

when needed

4. Decision making

authority

7. Suitable rythm

3. Proper agenda

Successful CoP

2. Passionate leader

6. Supporting tool to create transparency

1. Interesting topic with

concrete benefits to participants

The Role of CoPs in Different Transformation Phases

Transformation Scaling Continuous improvement

Goal of the Phase

Implementing basic Scrum, broadening the knowledge in the cross-functional teams

Getting scaling, especially inter-team coordination, to work

Applying lean thinking: optimizing the whole, end-to-end flow, continuous improvement

Level of CoPknowledge

Learning and practicing what CoPs are and how do they work

Experimenting to use CoPs for new purposes

CoPs established their place as a central fora for a wide range of purposes

What kind of CoPs?

Role-based CoPs and CoPs to replace functions that did not exist anymore in the new organization structure

CoPs to support coordination and design between teams developing a common feature

CoPs aiming to improve the way of working and optimize the end-to-end flow

Drivers setting up the CoPs?

Managers and coaches Product Owners, Scrum Masters, Coaches

Coaches at different levels

Examples of CoPs

Scrum Master CoP,Functional Verification CoP

Feature design CoPs, Feature Coordination CoPs

End-to-End CoP, Coaching CoP, Developer’s CoP

Organizational Support for CoPs

1. Supportive Atmosphere

2. Infrastructure support

Openness of participation

and Managers and coaches

support in building

Participation valued

How to Arrange Inter-team Coordination?

• Mindset more important than practices!!– Teams responsible for

coordination

• Practices:– Scrum-of-Scrums– Communities of Practice– Common Release / Sprint

Planning– Common Demo– Common Retrospective

Common Sprint Demo at Nokia

1.

All the teams

2.

One Team

3.

All the teams

4.?

APO

Common Retrospective at Nokia

1. Each team brings 3 issues2. ”Open Space”

3. The biggest impediment

Internal coachAll theteams

Work Spaces and Infrastructure

Workspaces and Infrastructure

• Spaces– Team spaces– Product owner team– Global connections

• Infra– Continuous integration– Videoconference– Backlog, version control

Scaling PracticesChallenges:• Scaling practices not working as well as they could• Challenge of ”common” meetings: Mindset? Big picture?

Coordination between the teams?Successes:• ”Better than waterfall”• CoPs

Scaling practices are not easy to take into use

Questions?