Christ Vriens@Agile Community Event - March 19th, 2009

Preview:

DESCRIPTION

Presentation by Christ Vriens – Philips Research Europe on Agile community event (19 march 2009) at Xebia India , Gurgaon.

Citation preview

Agile software developmentin practice

Christ VriensSoftware Engineering Services (SES)

MiPlaza – Systems Creation

Our MiPlaza video is on line:http://www.miplaza.com/video/MiPlaza%20overview.html

Software Engineering Services (SES)Started in 2000, now 80 software engineersCertified for CMM L2 and ISO9001 (co-)Develop software part of devices……which are safe and effective,…and meet applicable regulatory requirements,…in an efficient way!Evolutionary path from idea to businessoffering “right quality” at each stageStrong focus on Agile SW development

eXtreme ProgrammingScrum

2

3

Evolutionary path from idea to business

Mock-up

Product

XP@Scrum

Prototype Good weather tests

LabVenture + Bad weather tests

Incubator + all …ilities

Examples from our project portfolio

enabling open innovation

4

Hardware & software developed by MiPlaza Systems Creation

Manufacturing of pills by AppTech Greenhouse

Drug ReservoirElectrical MotorBatteries

pH Sensor

Integrated:MicroprocessorWireless transceiverTemperature sensor

Antenna

Flex Circuit Foil Seal

ID 018

Control

Center

Portable Unit A

Portable Unit B

Portable Unit C

The iPill System

5

Intelligent Shop Window (Experience Lab)

6

Entertaible (Entertaining Table)Tabletop gaming platform that

combines traditional multi-player board and computer games in a uniquely simple and intuitive way

7

Lifestyle and Healthcare domain

• Same urgency in both domains: Deliver more functionality at lower cost, with higher and continuous quality and yield demonstrable value more quickly while responding to changing business conditions and user needs during development

8

9

XP@Scrum• XP: focuses on engineering practices• SCRUM: focuses on process• The SES WoW combines XP, SCRUM and some

common sense

10

Scrum Process

11

Implementing Planning & Tracking

12

13

Typical Developer’s Day

Integration

Added test shall succeed

Sign off Task

All tests shall succeed

Dynamic Pairing

Added test shall failImplementation

Refactoring

Development Unit Test

All tests shall succeed

Stand Up Meetingat 9:00

Go HomeWhen Tired

14

Pair Programming

15

Quality System Deliverables for SoftwareDesign Controls

For Lifestyle domain based on ISO 9001 and CMM L2.5

Additional for Healthcaredomain based on ISO 13485 and FDA QSR

Planning Project Management Plan, Interfaces Liability, System V&V Plan, Risk Management Plan

Input Product (FRS?) and Sprint backlogs URS, SyRS, SRS

Output Architectural designs and decisions, source code, executables, makefiles, configuration files, installation procedures

SDD, Traceability Matrix, Audit Trails (= recordings of changes made)

Review Retrospectives, QA checks, Fagan inspections, Management reviews

Verification Unit tests

Validation Acceptance test specifications Test Reports, RM sheets, Tool Validations

Transfer Minutes, status reports, user and operator manuals, release notes

Design History File

Changes CR/PR database, CCB minutes, revision history

Justification of changes

3-6 calendar monthsAccepted FRS 1.0Accepted SyRS 1.0Accepted SRS 1.0

Release Plan 1.0Validation Spec 1.0

2-4 weeks

Clinical Validation

Ship Release 1.0Inception

Verification Spec 0.1SDD 0.1

Retrospection 1.0Accepted SDD 1.0

Accepted SRS 1.1 & VS 1.0

Cus

tom

er/M

anuf

actu

rer

resp

onsi

bilit

ySo

ftwar

e te

am r

espo

nsib

ility

Design Transfer

ReleaseIteration(s)

Bug fixing; review andSign-off of deliverables

Release 1.0

Informal Design Transfer

16

FRS, SyRS 1.0 Validation

Ship Release 1.0Inception

Design Input 1.0 Design Output 1.0

V&V Spec 1.0

FRS, SyRS 2.0 Validation

Ship Release 2.0

Design Input 2.0 Design Output 2.0

V&V Spec 2.0

FRS, SyRS 3.0 Validation

Ship Release 3.0

Design Input 3.0 Design Output 3.0

V&V Spec 3.0

3-6 calendar months

17

18

19

20

21

22

Productivity Improvement

Comparison with PPENGv2Engineering Effort considered between CS & DRStaff Months spent used as effort size (includes

projection till 748 for PEP)

Project Size, Function Points

Effort,Staff

month

Engineering Productivity,

FP / Staff month

PPENG V2

444 92.6 4.79

PEP 2.0 1050 169.55 6.19

29.2%Productivity

Increase

23

Cost reduction

Budget Savings predicted and made used for other projects

Description Unit Project Effort

From PRS Plan Staff Month 193.5Actual (incl CRs) Staff Month 166.3Reductions Staff Month 27.2Reductions % 14%Nett Scope Change Func Points 18.2%Effort for PRS scope Staff Month 136.0Reductions Staff Month 57.5True Improvement % 30%

24

Productivity

24.9

51.3

24.3

0

10

20

30

40

50

60

XtraVision 5(Mach5) XtraVision 6(Mach6) XtraVision 7

LOC

/ Da

yMore code generated, every day.

25

26

Post Release Defect Rate

0.90

1.58

0

1

2

XtraVision 6(Mach6) XtraVision 7

Def

ects

per

day

dur

ing

acce

ptan

ceSignificantly more stable!

26

27

Learn, Adapt and Improve: Retrospectives!

28

Example of a Project Retrospective

29

Allow experimentsBe not afraid to change things

30

How to behave as a Manager in an Agile Organization

• No micro management as engineers will lose energy and self-direction resulting in an initiative-lacking organisation. Let your engineers have full authority to do whatever is necessary to meet their commitments within defined organizational standards

• Time boxing is no way to demand working in overtime at every iteration; keep a sustainable pace

• Minimal (barely sufficient) bureaucracy• Take your right to say ‘no’: don’t work with customers who

don’t play their roles as required by the process!• Celebrate success• Planning is a means of communication

31

(Some) Challenges on the Path to Agilefrom the viewpoint of a manager

• Most people are afraid of new ways of doing things • Organizational change is not top-down or bottom-up, but

participative at all levels• You can’t learn it out of a book or from a presentation

It also doesn’t work if followed rigidlyAdapt it to your particular environment

• Find the right coach• Hire the right engineers (no fixed roles, teamwork, verbal

communication, …)• Customers reaction on refactoring, pair programming, and

on-site customerCustomer defines WHAT, in what ORDER but not the HOWOffer customers to only fund the first couple of iterations

• Readiness assessment e.g. whole team in same location (open space without barriers and lots of whiteboards)

32

Agile team members are not afraid to

• Stop when they are tired (XP = Revenge of the programmers!)• Let every business decision be made by the customer• Ask customers to reduce the scope of a release• Ask their peers, or customers, for help• Design and implement only what is needed for today, trusting that we can

add, tomorrow, what will be needed tomorrow• Make changes that improve the function or structure of code• Throw code away• Change the process when it’s not working

World-class expertiseWorking for you

34

Recommended