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

1. Agile software development
in practice
Christ Vriens
Software Engineering Services (SES)
MiPlaza – Systems Creation
Our MiPlaza video is on line:
http://www.miplaza.com/video/MiPlaza%20overview.html

2. Software Engineering Services (SES)
Started in 2000, now 80 software engineers
Certified 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 business
offering “right quality” at each stage
Strong focus on Agile SW development
eXtreme Programming
Scrum
2

3. Evolutionary path from idea to business
Mock-up
Good weather tests
Prototype
+ Bad weather tests
LabVenture
XP@Scrum
+ all …ilities
Incubator
Product
3

4. enabling
open innovation
Examples from our project portfolio
4

5. The iPill System
Hardware &
software developed
by MiPlaza
Systems Creation
Manufacturing of
pills by AppTech Batteries
Electrical Motor Drug Reservoir
Integrated:
Greenhouse Microprocessor
Wireless transceiver
Temperature sensor
Portable
Unit A
ID
018
Portable
Unit B
Foil Seal
Flex Circuit
Contro
l Portable Unit C
pH Sensor Antenna
Center
5

6. Intelligent Shop Window (Experience Lab)
6

7. Entertaible (Entertaining Table)
Tabletop gaming platform that
combines traditional multi-player
board and computer games in a
uniquely simple and intuitive way
7

8. 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
9

10. Scrum Process
10

11. Implementing Planning & Tracking
11

12. 12

13. Typical Developer’s Day
Stand Up Meeting
at 9:00
Dynamic
Pairing
Sign off
Refactoring
Task
All tests shall succeed
All tests shall succeed
Development
Integration Go Home
Unit Test
When Tired
Added test shall fail
Implementation
Added test shall succeed
13

14. Pair Programming
14

15. Quality System Deliverables for Software
Design For Lifestyle domain based on Additional for Healthcare
Controls ISO 9001 and CMM L2.5 domain 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, SDD, Traceability Matrix,
source code, executables, makefiles, Audit Trails (= recordings
configuration files, installation procedures 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 Design History File
operator manuals, release notes
Changes CR/PR database, CCB minutes, revision Justification of changes
15
history

16. Release 1.0
Customer/Manufacturer responsibility
3-6 calendar months
Inception Ship Release 1.0
Accepted FRS 1.0
Design Transfer
Accepted SyRS 1.0
Accepted SRS 1.0 Validation Spec 1.0 Clinical Validation
Informal Design Transfer
Release Plan 1.0
Retrospection 1.0
Verification
Software team responsibility
Accepted SDD 1.0
Spec 0.1
Accepted SRS 1.1 & VS 1.0
SDD 0.1
Release Bug fixing; review and
2-4
Iteration(s) Sign-off of deliverables
weeks
16

17. 3-6 calendar months
Inception Ship Release 1.0
FRS, SyRS 1.0 Validation
V&V Spec 1.0
Design Input 1.0 Design Output 1.0
Ship Release 2.0
FRS, SyRS 2.0 Validation
V&V Spec 2.0
Design Input 2.0 Design Output 2.0
Ship Release 3.0
FRS, SyRS 3.0 Validation
V&V Spec 3.0
Design Input 3.0 Design Output 3.0
17

18. 18

19. 19

20. 20

21. 21

22. 22

23. Productivity Improvement
Project Size, Effort, Engineering
Function Staff Productivity,
Points month FP / Staff
month
PPENG
444 92.6 4.79
V2
PEP 2.0 1050 169.55 6.19
Productivity
29.2%
Increase
Comparison with PPENGv2
Engineering Effort considered between CS & DR
Staff Months spent used as effort size (includes
projection till 748 for PEP)
23

24. Cost reduction
Description Unit Project
Effort
From PRS Plan 193.5
Staff Month
Actual (incl CRs) 166.3
Staff Month
27.2
Reductions Staff Month
Reductions % 14%
Nett Scope Change 18.2%
Func Points
Effort for PRS scope 136.0
Staff Month
57.5
Reductions Staff Month
True Improvement % 30%
Budget Savings predicted and
made used for other projects
24

25. Productivity More code
generated,
every day.
60
50
51.3
40
LOC / Day
30
24.9
24.3
20
10
0
XtraVision 5(Mach5) XtraVision 6(Mach6) XtraVision 7
25

26. Post Release Defect Rate Significantly
more stable!
2
Defects per day during acceptance
1.58
1
0.90
0
XtraVision 6(Mach6) XtraVision 7
26 26

27. Learn, Adapt and Improve: Retrospectives!
27

28. Example of a Project Retrospective
28

29. Allow experiments
Be not afraid to change things
29

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
30

31. (Some) Challenges on the Path to Agile
from 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 rigidly
Adapt 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 customer
Customer defines WHAT, in what ORDER but not the HOW
Offer customers to only fund the first couple of iterations
• Readiness assessment e.g. whole team in same location 31
(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
32

33. World-class expertise
Working for you

34. 34