Corporate Technology

Applying Agile and Scrum Practices at Siemens Sabine Canditt Siemens AG, CT SE 3 Otto-Hahn-Ring 6 D 81739 Munich Tel: +49 89 636 46752 [email protected]

Copyright © Siemens AG 2007. All rights reserved.

Motivation ƒ Scrum is a useful, albeit generic framework that does not answer all questions. In large companies like Siemens, special problems have to be considered. ƒ Introducing Scrum requires many changes; however not everything can / has to be changed – and not all at once. ƒ Here are some typical problems and pragmatic solution outlines to show how this can be done. ƒ They show how „core Scrum“ can be applied to sub-processes. ƒ They work under certain real life conditions – not everywhere. ƒ They may be a step towards more agility – or may be here to stay.

Page 2

2007-11

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Active in six business areas Automation and Control

Power

Transportation

Medical

Information and Communications

Lighting

Automation and Drives

Power Generation

Transportation Systems

Medical Solutions

Communications 1)

OSRAM

Industrial Solutions and Services

Power Transmission and Distribution

Siemens VDO Automotive AG 3)

Siemens IT Solutions and Services 2)

Siemens Building Technologies

External sales of Operations Groups excluding Other Operations (as of September 30, 2006) 28.5% 19.3%

17.3%

1) Since Oct.1, 2006, Com is no longer a Group. 2) Siemens Business Services (SBS) Group until January 15, 2007 3) Subject to approval by regulatory authorities, the Group will be sold to Continental AG

Page 3

October 07

19.7% 9.8%

5.4%

Copyright © Siemens AG 2006. All rights reserved.

Corporate Communications

Global presence – basis for competitiveness Germany 34%

30% 19%

Europe (excl. Germany) Americas 22%

26%

27%

31% 23%

27%

161

16.2

86

v

€

) Asia-Pacific

127 104

22.9

78

v

€

)

v

27.1

€

67

) Africa, Middle East, CIS

19%

15%

15%

70

12.9

54

v

€

)

9%

v

13 Employees (thousands)

€ Sales (billions of EUR)

) Major facilities As of September 30, 2006 October 07 Page 4

3%

8.2

1%

v

€

)

4

Copyright © Siemens AG 2006. All rights reserved.

Corporate Communications

Global presence of R&D: 48,900 R&D employees at more than 150 locations in over 30 countries

Issaquah Sacramento Chatham Peterborough Berkeley Tilbury London Drummondville Mountain View Concord Auburn Hills Danvers San José Hoffmann Santa Clara Burlington San Diego Estates Piscataway Pittsburgh Princeton Arlington Johnson City Newport News Austin Norcross Knoxville Guadalajara Lake Mary Orlando

Breda Hengelo Mülheim Amsterdam Pandrup Gothenburg Oslo Helsinki Bracknell St. Petersburg Eynsham Berlin Moscow Roke Manor Dresden Erlangen-Nuremberg Brussels Karlsruhe Regensburg Prague Paris Zurich Toulouse Vienna Budapest Bratislava Madrid Munich Zagreb Istanbul Timisoara Porto Athens Lisbon Graz Netanya Zaragoza Milan Linz New Delhi Tel Aviv Salzburg Sophia Treviso Antipolis Goa

Xi‘an Bombay

Nanjing Shanghai Hong Kong Chengdu

Sao Paulo Curitiba Buenos Aires

Tokyo Kawasaki Yokohama Kakegawa

Taipei

Bangalore Penang

Bogota

Changchun Beijing Seoul Tianjin Ichon

Singapore

Pretoria

Melbourne

Sydney

Copyright © Siemens AG 2006. All rights reserved.

Page 5

October 07

Corporate Communications

Corporate Technology Core technologies, competencies and services for the Groups

Customer Business Areas / Operating Groups +

top company programs

Automation and Control

Power

Transportation

Health Care

Information and Communications

Lighting

Regions

ƒ Innovation ƒ Customer focus ƒ Global competitiveness

Corporate Technology

Page 6

Corporate Research and Technologies ƒ Core technologies and competencies with multiple impact supporting the groups ƒ Pictures of the Future ƒ Accelerators for new business opportunities

2007-10-09

Canditt, CT SE 3

Corporate Intellectual Property and Functions ƒ Intellectual Property services and strategy ƒ Standardization, environmental affairs, Information research center

© Siemens AG, Corporate Technology

Corporate Research and Technologies Software & Engineering Technology Division

Quality and efficiency in software development

Optimization of planning, decision and production processes

Analysis and engineering of complex systems

Discrete Optimization

Software & Engineering

Systems Engineering Project Management and Innovation Project management and innovation

Page 7

Development Techniques

Software Initiative Siemens Software Initiative

2007-10-09

Canditt, CT SE 3

Information brokers and technical liaison managers Information Broker

Software architecture for distributed, mobile and embedded systems

Architecture

System and Software Processes System and software processes

© Siemens AG, Corporate Technology

Agile@Siemens ƒ Non-uniform, depending on the (sub-)organization ƒ Some with 1000s of developers at different sites ƒ Some with small pilot projects ƒ Some bottom-up, some top-down…

ƒ We at CT SE 3… ƒ help organizations to establish and agile understanding, goal, and strategy ƒ coach projects and people ƒ organize trainings and best practice sharing across business units ƒ CSM/CSPO trainings ƒ Agile newsletter ƒ Internal conferences

Page 8

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Why is Agile So Difficult in Industrial Environments? ƒ Characteristics of industrial projects: ƒ Complex lifecycles (Portfolio Management, Sales, Marketing, Service…) ƒ Many dependencies, many stakeholders ƒ Long-running projects ƒ System development (incl. hardware, mechanics) ƒ Big teams, distributed teams ƒ Outsourcing / offshoring ƒ Safety/security regulations (e.g. FDA)

ƒ Critical areas ƒ Customer involvement ƒ Organizational culture (e.g. waterfall history) ƒ Communication (distances, languages, time zones)

Page 9

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

The Change Curve

Page 10

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Our Approach: Balancing Traditional and Agile

Established

A Continuum

Agile

 You should have a process that addresses your needs, business goals, and environment. Organizational culture (e.g. management) Customers (e.g. contracts) Products (e.g. embedded) Projects (e.g. distributed teams) Tools and Processes (e.g. TDD) Staff (e.g. expertise)

 Agile and established elements can support each other to find an optimized solution. Page 11

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Examples Requirements Team Structure Testing Agile and the Product Lifecycle Process

Page 12

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Requirements ƒ The problem: ƒ Commercial requirements are often much too complex to be realized in one Sprint by one team. ƒ Breaking down requirements to Sprint tasks is time consuming. ƒ User stories are good for requirements with end user interaction, but how about other types of requirements?

ƒ Solution Outline: ƒ The procedure has to be agile enough to capture and integrate new requirements at any time. It has to include not only development, but also “frontloading” (e.g. input from Portfolio Management, Service, lead customers…). ƒ Requirements should be pre-selected to avoid superfluous analysis activities and flooding the product backlog. ƒ Different concepts (also traditional) to express requirements can be combined.

Page 13

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Per product generation

Requirements Example: Product Family Development

Strategy, Roadmap

Project Vision/Scope

User Stories

HL Use Cases

Global NFRs

HL NFRs

Global general Reqs

General Reqs

SL Use Cases

Per Sprint

JIT refinement Freeze for next Sprint

Frontloading

Tasks Global/Product Family

Page 14

2007-10-09

Product/Project Product/Project

Canditt, CT SE 3

Scrum team Scrum team Scrum team © Siemens AG, Corporate Technology

Requirements Example: Product Family / Framework Development

ƒ Framework development aims at reusability of requirements (and solutions) ƒ Product Owners on different levels: ƒ Global level

Global reqs

PO G

ƒ Product level Product reqs

ƒ Application level ƒ Framework level

ƒ Prioritization conflicts have to be escalated and decided by the global Product Owner.

PO P

Component PO A PO F Reqs (Application/Framework)

ƒ System architects are important to derive framework requirements and keep the architecture consistent.

Page 15

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Requirements Example: Product Family / Framework Development

PO G Strategy/ Roadmap PO P

User Stories

Other Reqs

PO A Application Req Arch

Common Funct. Req

Page 16

2007-10-09

PO F Common Funct. Req

Canditt, CT SE 3

Framework

Developmet Projects

Application Req

Applications

Product Reqs

PO P Product Reqs

PO P, PO A/F, Arch.: Analyse reusability • Derive appl. Reqs • Check if there is a CF to be extended • Check if several producs need the req.

© Siemens AG, Corporate Technology

Team Structure ƒ The problem: ƒ Feature development may need expertise from different sites. ƒ In distributed feature teams, members hardly know each other and communication is difficult.

ƒ Solution outline: ƒ Depending on size and distribution, there should be PO Proxys for the feature teams who understand what to do and are responsible for the team requirements. ƒ Scrum Masters for remote team members don’t make much sense. People need local Scrum Masters they know and trust. ƒ Feature teams should meet regularly (requirement workshops, Sprint planning and reviews). This is often considered as too expensive! ƒ Mid term goal: co-located feature teams. This often requires a new strategy for sitespecific core competencies!

Page 17

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Team Structure Example

PO

Site teams

POP POP

“SM” “SM” “SM”

PO

POP

SM

POP

SM

POP

SM

Co-located Feature teams = Scrum teams

Feature teams Where are the Scrum teams??? SM = Scrum Master PO = Product Owner POP = Product Owner Proxy

Page 18

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Team Structure Process Issues and Quality Assurance ƒ The problem: ƒ For multiple (distributed) Scrum teams, it is hard to establish a „one team“ spirit and common goal. ƒ Self-organization mainly works locally. It is difficult to inspect and adapt across Scrum team borders.

ƒ Solution outline: QA (or Scrum of Scrum Master) to help teams with global quality / process issues ƒ Bug tracking (e.g. if reporter and resolver are in different teams) ƒ Tracking of reviews and test sufficiency (4-eyes-principle) ƒ Supporting optimization of common activities (e.g. release planning, synchronization of Sprint planning, root cause analysis) ƒ Providing process guidance (e.g. checklists, templates, definition of common rules and procedures…) ƒ Providing metrics (e.g. release burndown) ƒ Risk management

Page 19

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Testing ƒ The problem: ƒ Testing should be completed in each Sprint. ƒ This is sometimes not possible (yet). ƒ Manual regression tests ƒ Availability of hardware and non-iterative deliveries ƒ Availability of test expertise and equipment

ƒ Solution outline: ƒ Tests should be planned (incl. availability of deliveries and of test hardware). ƒ It has to be documented clearly which tests have to be executed when (“done” criteria). ƒ A separate (virtual) team may be useful to cover NFRs and end product tests, test automation and infrastructure, release preparation etc.

Page 20

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Testing Good! Dev/test finished by Scrum team in one Sprint

Sprint n

Development/ Unit tests

Sprint n+1

Integration test Ok. Pipelining of Dev/ST activities; Potentially shippable inc only after every 2nd Sprint

System test

Dangerous. Start text execution as early as possible. Use old/prototype HW, simulators. Automate tests. Only if necessary. Stabilization Sprint in case of quality problems. No new functionality developed, only bug fixes Avoid! Delaying special tests at the end is a high risk.

Page 21

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Testing Responsibilities Example

Unit tests

Dev

Dev

Dev

IT

IT

IT

ST • cross functionality regression testing with different product versions • performance testing and dimensioning of the overall system

Page 22

2007-10-09

ST

Cross ST

Canditt, CT SE 3

ST

Build integration, Smoke tests

• Interface testing • Project functionality • NFR (like concurrency, robustness) • Scrum team deliveries with dependencies to other scrum team owned functionality

© Siemens AG, Corporate Technology

Agile and the Product Lifecycle Process

ƒ The problem: ƒ Usually Agile covers „only“ the phases „Define“ and „Realize“. But there is more than „just“ development. ƒ In Agile, there is no strict border between these two phases (e.g. no Big Upfront Requirement Freeze, or Big Upfront Project Plan). ƒ The influence on and interfaces to other disciplines (Portfolio Management, Sales, Service, HW…) have to be adapted and optimized. ƒ Development has to be “frontloaded” with new requirements iteratively. ƒ Deliveries have to be offered and sold iteratively. M100

Plan

Portfolio Mgmt

Page 23

M200

Define

2007-10-09

M300

Realize

Canditt, CT SE 3

Commercia- Phase lize/Operate out

© Siemens AG, Corporate Technology

Agile and the Product Lifecycle Process ƒ Solution outline: ƒ Adapt M200 (e.g. “n% MUST requirements”) ƒ Avoid responsibility shift from Define to Realize (“throwing requirements over the fence”). ƒ Product Owner continuously involves all disciplines. M100

Plan

Portfolio Mgmt

M200

Define

M300

Realize

Commercia- Phase lize/Operate out

Agile Development

Responsibility of Product Ower

Page 24

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Agile and the Product Lifecycle Process Co-laboration of PO and „traditional“ roles. ƒ The problem: ƒ Product Owners have a lot to do and tend to become unavailable.

ƒ Solution outline: ƒ The PO has the overall responsibility. ƒ The “traditional” roles support the PO and work together as a team.

Sales

Customers Customers Customers

Other dev. teams

PO

Service

Suppliers

PM

PL

Ar

SE

Solutions

PM: Programme Manager Ar: Architect QA: Quality Assurance PL: Project Lead

POP Scrum team POP Scrum team POP Scrum team

QA Page 25

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Agile and the Product Lifecycle Process Example: Integration with Non-Iterative Deliveries

Common System test phase with clear entry criteria (milestones) Development/ Unit tests

Use preliminary/old HW or mock ups

Integration test System test

Iterative Features Release

Included in ST phase Non-Iterative Features

Not included in ST phase

Used for HW stabilization Hardware Prototype n

Page 26

2007-10-09

Canditt, CT SE 3

Prototype n+1

© Siemens AG, Corporate Technology

Agile and the Product Lifecycle Process Defining Agile Milestones ƒ Agile Milestones can be derived from traditional ones (as suitable for the organization). ƒ End of Sprint “done” criteria have to cover required deliveries for product lifecycle management. Most of these deliveries are created iteratively Analysis/ Implemen- Integration Design tation Test

Define

Traditional Milestones

M1

M2

M3

M4

System Test M5

EoS

Change: Avoid Upfront Requirement Freeze

Sprint 1 Sprint 2 Sprint 3 Sprint n

M1

Agile Milestones

MS

M5 New: Stability of main features and architecture; trigger sales/service

Page 27

2007-10-09

Canditt, CT SE 3

Transfer: Cancel intermediate milestone criteria or merge to End-ofSprint („done“)

Unchanged; check at end of development phase

© Siemens AG, Corporate Technology

Agile Documentation ƒ The problem: ƒ Agile aims to reduce waste and focuses on generating business value. ƒ Documentation often does not create (direct) business value. ƒ An agile process requires has different (less) documentation needs.

ƒ Solution outline: ƒ Don’t say: “We are agile, we won’t write documents any more”! ƒ Identify what information is necessary and useful, for whom and when (e.g. to support communication in distributed teams). ƒ Consider information needs beyond the project (and team) scope. ƒ Create the documents iteratively and in parallel to the software to keep them consistent. ƒ Include documentation in backlogs and plan accordingly. ƒ Use documentation to complement communication, not to replace it! Page 28

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Agile Documentation ƒ Examples for needed and useful documentation: ƒ Everything required by (external) processes and regulations (e.g. FDA, ISO…) ƒ User stories and other forms of requirements (e.g. Use Cases) ƒ Architecture concepts and high level architecture (e.g. UML) ƒ Code inline documentation ƒ Documented test scripts (also for acceptance tests)

ƒ Sometimes not needed: ƒ Extensive design specification (replaced by inline documentation and preliminary sketches) ƒ Test case specification (replaced by documented test scripts)

Page 29

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology

Conclusion ƒ Going agile does not mean forgetting about everything that we have learned in the past.

ƒ However, if you honestly want to live agility, don‘t make lousy compromises. ƒ A single bottleneck system test at the end of the project is not agile. ƒ Renaming Project Leaders to Scrum Masters does not create a self-organizing team.

Preserve the agile principles and values.

Page 30

2007-10-09

Canditt, CT SE 3

© Siemens AG, Corporate Technology