Controlled chaos - Producing trustworthy embedded systems using Agile methods

Ko Dooms (Philips Applied Technologies)

Contents

Short introduction speakerSPI (top-down approach)has come to its end?Agile documentationAgile Experiences from Philips

BenchmarkAgile Tooling

Q&A

Meet Ko Dooms

Age: 51 Married with childrenOne grandchildSports: Golf, Darts, Baseball

Work: 26 year PhilipsNow:

Resource Competence manager at Philips Applied Technologies

Then: Software engineer, project leader, group leader, development mgr., project mgr., groups mgr.

Our role within Philips

G.J. Kleisterlee

G. Dutiné P.J. Sivignon S. Rusckowski A. RagnettiR. Provoost Th. van Deursen

Board of Management

Corporate Technologies

R. Harwig

Philips IP&SR. Peters

Philips ResearchR. Harwig

Philips AppliedTechnologies

C. van Uijen

Lighting DAPConsumer Electronics

Medical Systems

Corporate

Key figures

A global, leading technology center• Founded in 1968

A multinational highly qualified workforce of more than 1100 people (+ 150 temporary employees)• University degree ± 700• 6 professors, 135 PhD.• Bachelors & Engineers ± 400• Other type of education ± 100

Sales 2005• EUR 144 million• 80 % internal sales; 20 % external sales

Worldwide representation• 6 Locations spread over North America, Asia Pacific

and Europe

EindhovenSan JoséPittsburghSingaporeBangaloreRedhill

Contents

Short introduction speakerSPI (top-down approach)has come to its end?Agile documentationAgile Experiences from Philips

BenchmarkAgile Tooling

Q&A

Agile silver bullet?

DVD development

Never45%

Rarely19%

Sometimes16%

Often13%

Always7%

Are all the requirements used?

Source: Jim Johnson of theStandish Group, Keynote Speech XP 2002

ALL CODE CR/PR's of DXC / Nurnberg / Redhill

0

500

1000

1500

2000

2500

317

319

321

323

325

327

329

331

333

335

337

339

341

343

345

347

349

351

401

403

405

407

409

411

413

415

417

Weeks

Op

en/C

lose

0

20

40

60

80

100

120

140

160PMIOpen

Closed

PMI

Wish PMI

Lots of PR’s/CR’s to handle

Teamwork, Achievement and Hazards

KEY MESSAGES

Software Process Improvement (SPI) as we know it today has come to its endNeed of courage to rethink1) Drill down to the context - "Think it all"2) Improvement-in-the-small - "Keep thinking"

This leads to a so called "Innovative Leap" 1) 8x faster, 3.5x better, 4.9/5 customer satisfaction2) Lots of process optimitizations during the project

and not only after

LIFE IN THE 1990's

Come on, let' s show you something interesting !

Sorry, got no time.I've got to work!

Software ProcessImprovement

Fact corner:A good process will result in good products

BENEFITS OF SOFTWARE PROCESS IMPROVEMENT RETHOUGHT

Still, SPI isfairly expensive$11000-$53000/single engineer(Jones,1997)

1000+ studies in the IEEE database alone 0.21% of these

studies showSome concreteROI Figures (vanSolingen, 2004)

Moreover, 70% of the processimprovement projectsfail (SEMA, 2002)

IMPROVEMENT MODELS

Source: http://www.software.org/quagmire/, Aug-2005

Fact corner:If you know which one to take?

Source: Software Engineering Institute, March 2005

SW-CMM 2000-2004, 60% are Non-USA companies

IMPROVEMENT INCALENDAR TIME

20 months (1-->2)

19 months (2-->3)

25 months (3-->4)

Software Engineering Institute's data shows that process capability improvement takes

6.5 years (level 5) or3.25 years (level 3)

No data on capability levels vs. Business success

13 months (4-->5)

Business success?

Source: Software Engineering Institute, March 2005

The semi market for iDTV products

iDTV: emerging market, many players trying to get in

Fast changing Specs, Fast TTM,Every 12 months new System

High SW re-use,High productivity needed

Lower SW dev. budget& move to ISVs

Highly optimized SW (very expensive)

Software continues to grow exponentially (Like # transistors in ICs !)

iDTV: yet low market volumes,Market doesn’t pay (much) for SW(It’s the square mm that counts!)

Low cost prices for ICs(limited CPU power, limited memory)

Fact corner:We don’t have 5 years

Mgt view on Software

What are all these

Software guysDoing?

SW is always on the critical path

So inflexible!I was told that

software is easy to change

I don’t want large platforms, I need

products

They are only costing money and

don’t bring any !

Software is an immature discipline

Let us simply outsource software

Fact corner: Huge need for fasterImprovement – How? see next slides

0

5

10

15

20

25

30

35

40

45

1 2 3 4

Project 1

Project 2

Project 3

Project 4

Project 5

What is working in the process?342 positive remarks in the process..

# two-weekwork cycles

Fact corner:SPI people seldom knowwhat is going well!

# of positiveissues

What is working in the process?This document is a report of the reflection on the SmartInstall project until 8/11/2006. The

idea is to gather what is going well, what needs improvement and what steps to take.

Keep this• Flexible purchasing.

The team requires various hardware items and we directly ordered and bought the items we need.

• Experienced teamIt is an experienced team in the area of Motiva, java en Linux. Especially Linux knowledge is essential in this

project.

• Planning via PAT toolThe PAT tool provides a good mechanism to plan, track and manage all tasks to be executed.

• Weekly team meetingThe weekly team meeting is useful to discuss progress, plan next week and problems we hit.

• Flexible with requirementsTeam is flexible in changes to requirements from Nicoline’s team.

• Good understanding between disciplinesGood communication between development team and HCS team resulting in a good cooperation.

• Concept definition is clearThe extensive architecture document and the user scenarios have resulted into a clear starting point of the trial

implementation.

• Expert consultancyUse of external consultancy, like David, Rob and Peter.

• Multiple IPs generatedUsing a problem solving approach

What is not working in the process?

282 problems in the development process…

# two-weekwork cycles

0

5

10

15

20

25

30

35

40

45

1 2 3 4

Project 1

Project 2

Project 3

Project 4

Project 5

Fact corner:5 projects:8 week development cyclesw/ 10 person months effort

# of negativeissues

What is not working in the process?

Ongoing problems

• Purchase process not suitable for agile projects -> EscalateTo many people involved requires additional communication/effort takes to long

• No transparency on deliveryActual products not cheaper (although additional hours are spend).

• When bypassing purchase (by direct purchase by team members), the team members have to pay personal the purchase

• Projects tracking features missing in PAT. Features like good prints of overview, written hours per week for overall project

• IP responsiveness to low

• Improve progress reporting

• Availability program management.

0

5

10

15

20

25

1 2 3 4

Project 1

Project 2

Project 3

Project 4

Project 5

Concrete actions taken158 improvement actions, 70 "pure" spi actions

# two-weekwork cycles

Fact corner:Without actions-in-the-small things will not "really" improve

# of improvementactions

Try this• Inventory equipment needs done sooner

The ordering and delivery task much more (lead)time than expected. Solution was to get going earlier already in the

concept phase

• Buy assembled and working products instead of the componentsThe hours spend to assembly the computers highly exceeds the actual hardware coast, because various

unexpected

problems were hit. Solution is to buy assembled and working computers.• Daily standup team -> ALE

Introduce daily standup meeting with team members (including HCS members) to discuss progress last day and plan

coming days.

• Set clear goals task/stories/deliveries -> ALEWith current plan it is not clear who is responsible for integration and finalizing the implements to be ready on a milestone.

• Organize concept phase according normal projectTime was lost during concept phase, because in this phase a clear plan was missing.

• Appoint Nicoline as costumer representationIntroduce more formal milestones by releasing a milestone to Nicoline.

• Formalize stakeholders and their responsibility• Better integration with Installation guide and trail team

Make the dependencies and deliverables between sub-projects more formal. Also integrate project reporting

and risk management.• Do reflections sessions more regularly

Concrete actions taken

"KEEP THINKING"THE BOTTOM LINE

Fact corner:

"What we should have is a lot of experimentation. Encouraging people to make small improvements every day, to try little things because all big things start small. And then we need to nurture the improvements that are successful.“Gerard Kleisterlee - CEO Philips

Improvement-in-the-small:Return-on-investment becomesirrelevant; The development teamsare optimizing their performance onweekly basis.

800 process findings, 2 per minutein a workshop…

"Prevailing solutions are not always best. As leaders, we should seek to be challenged, to listen more and to empower people to search for better solutions," Theo van Deursen – CEO Philips Lighting

Big Bills start small as well

Microsoft corporation 1978Small

Bill

Contents

Short introduction speakerSPI (top-down approach)has come to its end?Agile documentationAgile Experiences from Philips

BenchmarkContinuous Integration & Agile Tooling

Q&A

Agile documentation with RaPiD7

Ko DoomsRoope Kylmäkoski

When is a document Agile?

1. Agile documents maximize stakeholder investment

2. Agile documents are “lean and sufficient”.1. Content is more important then the representation

2. Create simple content

3. Agile documents fulfill a purpose

4. Agile documents describe “good things to know”.

5. Agile documents have a specific customer and facilitate the work efforts of that customer.

6. Agile documents are sufficiently accurate, consistent, and detailed

Scott W. Ambler see alsohttp://www.agilemodeling.com/essays/WhyDocument

Contents

BackgroundIntroduction to RaPiD7Results

Background & Related Work

1997-1999 software projects were facing problems in specification work and in inspectionsTherefore, an improved method for specification work was developed in Nokia 1999-2000. This new approach is called RaPiD7RaPiD7 was developed independently based on the feedback from software projectsHowever, similar approaches to RaPiD7 exist such as JAD and Agile ModelingIn year 2000 RaPiD7 was taken into use in some parts of Nokia and then later deployed for Nokia Networks during years 2002-2004.

One View on Software Engineering

Analyze Inspect Design Inspect Implement Test

Valued Adding Software Engineering

Verifying Software Engineering

The Goal of documentation Work

Documentation work is done in order to…create understandingshare understandingstore the created understanding

And while doing this we want to…have good quality in the specifications, in other words, have no defects in the documentsgain common agreement on the matterdo all this as quickly as possible

Problems of Traditional Approach forAuthoring Documentation

Process described

Document authoring: Document A Inspection phase

Document authoring : Document B Inspection phase

Document authoring: : Document C Inspection phase

Phase starts Phase ends/new phase starts

Person A

Person B

Person C

Persons A,B,C…

Process not usually explicitly described

3) People are not attending the inspections and are not prepared for

the inspections

3) People are not attending the inspections and are not prepared for

the inspections

1) Not setting up a commontheme

on the contents

1) Not setting up a commontheme

on the contents4) The attendees have not

read the material ⇒no common understanding on

the matter

4) The attendees have not read the material ⇒

no common understanding on the matter

5) Inspections concentrate on unimportant details,

mostly negativefeedback

5) Inspections concentrate on unimportant details,

mostly negativefeedback

2) Writing documentstakes

a lot of calendar time

2) Writing documentstakes

a lot of calendar time

time

Fact box: This is still commonpractice in most projects

The Improved Practice – RaPiD7

time

Process described

Workshop 1 Inspection

Inspection

Inspection

Phase starts Phase ends/new phase starts

Document A

Document B

Document C

Persons A,B,C…

Workshop 2 Workshop 3

Workshop 1 Workshop 2

Workshop 1 Workshop 2

Workshop dates are agreed in

project planning

Workshop dates are agreed in

project planning

Documents (artifacts) are produced in

consecutive workshops

Documents (artifacts) are produced in

consecutive workshopsIf necessary, finally the document produced is inspected by e-mail or having a traditional inspection where the document is briefly checked

If necessary, finally the document produced is inspected by e-mail or having a traditional inspection where the document is briefly checked

Document should be mostly written in the

workshop and accepted at the end of

the workshop by participants

Document should be mostly written in the

workshop and accepted at the end of

the workshop by participants

Fact box: Change from individualtowards interaction wayof working

Layers of RaPiD7

Project layer

Case layerCase layerCase layer

WS layer WS layer WS layer WS layer WS layer WS layer WS layer

Case layer

WS layer WS layer

Case layer

WS layer WS layer

•Project layer: How the method is applied in projects?

•Case layer: How the documents/artifactsare created in consecutive workshops?

•Workshop layer: How the work is carried out in facilitated workshops?

Project Layer

11 22 4433

Official project planning starts End of iteration

Artifact workshop11 Project initialisation workshop

22 Project plan workshop 44 Project plan update / iteration planning workshop

33 Project plan workshop

Project starts

Case Layer

Workshop 1:General project

planning

Workshop 1:General project

planning

Workshop 2:Tasks &

responsibilities

Workshop 2:Tasks &

responsibilities

Workshop 3:risks

Workshop 3:risks

Project planv.0.1

Project planv.0.2

Project planv.1.0

1. Preparation

1. Preparation 1. Preparation

Workshop Layer RaPiD7

Preparation phase

Invitation phase

7. Closing

6. Decisions

2. Kick-off

3. Gathering ideas

4. Analysing ideas

5. Detailed design

1. Preparation

Nextmeeting

Participant Facilitator Participant

Facilitator

Action Points

DocumentFact box: 7 steps, 1 before and6 during workshop

Roles in RaPiD7 Workshops

Facilitator:Workshop process ownerInitiates the set of workshops (or single workshop), takes care of the initial planning, invites people, organizes the workshops and runs the workshops

Secretary:Takes care of recording decisions and results in the workshops

Other roles in the workshop are case dependent

“…the key factor is the purpose of the documents. Some documents are products themselves, others are internal documents supporting the later development phases and some documents are only back-of-the-napkin sketches supporting a small team with low requirements for the visual form of the documents. The difference is usually about how much of the ready made document can be achieved in the workshops.”

Applicability of the Method

The document is a product

(e.g. newspaper, users guide etc.)

How

muc

h of

the

fina

l doc

umen

t can

be

achi

eved

The document is “back of the napkin sketch”

Typical software project documents Documents used inside a team

External documentation

100%

What Kind of Documents Have Been Created?(Use Survey 2004)

20

13 1312

10 10

8 87

21 1

0

5

10

15

20

25

Act

ion

plan

s

Low

er le

vel

softw

are

spec

ifica

tions

Fea

sibi

lity

stud

ies

Req

uire

men

tsp

ecifi

catio

ns

Tes

t pl

ans

Oth

er

Pro

ject

pla

ns

Arc

hite

ctur

esp

ecifi

catio

ns

Str

ateg

ies

UI p

lans

Cus

tom

erdo

cum

enta

tion

Low

er le

vel

hard

war

esp

ecifi

catio

ns

Type of document

Nu

mb

er o

f re

spo

nd

ents

When Inspections Are Needed?

In principle, if everything goes right, no inspection is needed, and the inspection is actually a part of the workshop. Sometimes a separate inspection might be required:

The document is a product itself or almost a product and therefore the final document has not been completely authored in the workshops

The document is meant for wider audience than just the people in the workshops and therefore input is needed outside the workshop team

The process requires that inspections are held

Benefits of the Method

Needed calendar time for specification work significantly lower The overall quality of specifications is improvedThe time available is used more efficiently i.e. workshops give visibility for both inefficiency and efficiencyThere is no need to have inspections always nor do heavy corrections after the inspections i.e. less rework Communication in projects is easier and more effectiveBetter understanding within development teamLess personnel risks and more flexibility in assigning people to tasks

Benefits Perceived by People(Nokia Use Survey 2004)

TOP TEN

1. RaPiD7 improves common understanding

2. RaPiD7 increases information sharing and communication

3. RaPiD7 increases team cooperation

4. RaPiD7 speeds up the creation of the documents calendar wise compared to the traditional way

5. The overall quality of the documents is better when using RaPiD7compared to the traditional way

6. RaPiD7 ensures better commitment to project work compared to thetraditional way

7. The use of RaPiD7 decreases the amount of defects found in inspections

8. Inspections are more efficient and focused when the documents have been produced using RaPiD7

9. RaPiD7 decreases the efforts used in producing documents

10. RaPiD7 decreases the time used in inspections

Benefits by Metrics(Nokia Case Study 2004)

TOP FIVE

• Over 6 times less fatal defects in inspections than before

• Efforts for rework decreased over 50% per defect

• Over 50% more efficient defect finding rate

• No specification related defects found in implementation and testing phases

• No delays in project schedule

Challenges

In theory, there is no difference between theory and practice; In practice there is:

Understanding that this only sounds simple, but actually is notTailoring the method and understanding how it can be used for different documentsPlanning the workshops well. It’s in human nature to “just do it”Having enough skilled facilitatorsChanging the general way of working from individual working to team workingWorkshop way of working is not easier; it’s just different

Current Status in Nokia

There are hundreds of users and even more are influenced by the use of the method (i.e. not directly using the method themselves, but participating the workshops)Hundreds of documents have been created using the methodThe anticipated benefits have proven to be systematically true or at least partially true

Wrap Up

RaPiD7: Rapid Production of Documentation in 7 stepsThree layers:

Project layer: RaPiD7 approach is about a conscious decision and planned way of having the workshops as part of the specification workCase layer and workshop layer: RaPiD7 approach is about doing specification work and documenting the results in effective workshops

RaPiD7 provides the framework, steps, techniques and best practices for this work

Contents

Short introduction speakerSPI (top-down approach)has come to its end?Agile documentationAgile Experiences from Philips

BenchmarkContinuous Integration & Agile Tooling

Q&A

Contents

Short introduction speakerSPI (top-down approach)has come to its end?Agile documentationAgile Experiences from Philips

BenchmarkContinuous Integration & Agile Tooling

Q&A

Trial

Characteristics of the trial:Client/Server Software for audio/video playback with Digital Rights ManagementReverse engineering followed by partial redesignDevelopment based on PCP – CMM L3

Project – effort and production

Total Effort: 17,5 man yearsDevelopment Effort:15 man years Management Effort: 1 man yearTest Effort: 1,5 man years

Total Code Size: 422 KSLOCNew code: 176 KSLOCUpdated code: 195 KSLOCUntouched code: 51 KSLOC

Duration: 1 year (by definition)

Benchmark: Productivity

Industry data:Average: 150 SLOC/MMBest-in-class: 750 SLOC/MMPSP: 4000 SLOC/MM

Trial:New code only: 858 SLOC/MMNew + (0.3 * Adapted): 1143 SLOC/MMNew + Adapted: 1809 SLOC/MM

Based on total effort including Management & external Test effort

Benchmark: Defect Injection Rate

Industry data:Average: 7 defects per KSLOCBest-in-class: 3 defects per KSLOCPSP: 0.2 defects per KSLOC

Trial:New code only: 5 defects per KSLOCNew + Adapted: 2 defects per KSLOCNew + Adapted + Untouched:2 defects per KSLOC

Based on reported defects from internal & external test

Benchmark: Customer satisfaction

On a 5 points scale the customer scored:4.9

Customer satisfaction is measured as a survey of 7 questions on:

Having the right competencesMeeting the requirements (did we implement the right features) including handling changesMeeting deadlines and budget

Agile practices and tools used

From the ITEA-Agile project:SoftFab: Automating the build, test and reporting process daily builds, static and dynamic tests, doc generation, statistics: code coverage, confidence level gives focus on the real tasks, automated work environmentRaPiD7: used for IP generation and design documentation Daily integration + weekly release of working softwareInformation Radiator: SoftFab, code size, product start-up time, PR/CR statistics, team organizationCustomer collaboration: Weekly review and discussion with customer

From existing Agile practices but adaptedTDD: make test first, code stays smaller and more efficient Pair programming: on cross component level or difficult partsPair review: buddy system reviewing major implementationsScrum: used during focus time, dead line approachingReflections: team looks back what went well and what can be improved and adapts the process

Contents

ContextScope of the trialsBenchmark resultConclusionQ&A

Conclusion

Benchmark:Productivity increase of 8xQuality 3.5 betterCustomer satisfaction : 4.9 / 5

Agile and CMM can work togetherUse of tools is essential (automated build

and test)Developers are enthusiastic, customer is happy getting weekly releasesExploitation: SoftFab and Project Assist Tool

Contents

Short introduction speakerSPI (top-down approach)has come to its end?Agile documentationAgile Experiences from Philips

BenchmarkContinuous Integration & Agile Tooling

Q&A

Continuous Integration

using SoftFab

Peter JanssenAurora ProjectPhilips Applied

Technologies

Continuous Integration Process

Description from Wikipedia:

“Continuous integration is a software engineering term describing a process that completely rebuilds and tests an application frequently.“

Aurora Project Continuous Integration Setup

SoftFab Integration

Build Server

Aurora Integration Status Light

Continuous Integration Cycle

Developer’s PC

Source code repository

SoftFab Integration

Build Server

1Developer check-in

2Monitor

repository for changes

3Update Build Workspace 4

Execute Build and run tests

5Inform developers of build and test

results

Status: GreenLatest revision built and

tested OK

Status: Green / YellowRepository changes

detected, running tests(previous revision: OK)

Status: RedLatest revision FAILED

predefined test-set:STOP, FIX ASAP!

Status: Red / YellowRepository changes

detected, running tests (previous revision: FAILED)

Status: GreenLatest revision built and

tested OK again

Aurora Integration Status Light

Continuous Integration Best Practices

Maintain a Single Source Repository.Automate the BuildMake Your Build Self-TestingEveryone Commits Every DayEvery Commit Should Build the Mainline on an Integration MachineKeep the Build FastTest in a Clone of the Production EnvironmentMake it Easy for Anyone to Get the Latest ExecutableEveryone can see what's happeningAutomate Deployment

Source: www.MartinFowler.com

Continuous Integration Benefits

Reduced risk during developmentBugs are more easily foundRapid feedback on new software qualityCurrent integration status can be seen by everyone, all the time

Agile Tooling

Meet SoftFab

Questions

Lets interact :=)

Back up material

Ko Dooms

Contents

Agile manifestoShort introduction speakerThe 12 Agile principlesSPI has come to its end?The ITEA Agile projectIntroduction to RaPiD7Agile Experiences from Philips

Contents

Agile manifestoShort introduction speakerThe 12 Agile principlesSPI is over?The ITEA Agile projectIntroduction to RaPiD7Agile Experiences from Philips

THE 12 AGILE PRINCIPLES (1/3)

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter timescale.

4. Business people and developers must work together daily throughout the project

1. Satisfy customerthrough early andfrequent delivery.

2. Welcome changingrequirements evenlate in the project.

3. Keep delivery cyclesshort (e.g., everycouple of weeks).

4. Business peopleand developers

work together dailythroughout the project.

DESCRIPTION SUMMARY

Fact corner:Principals shouldbe seen as a setof “thinking-tools”

THE 12 AGILE PRINCIPLES (2/3)

5. Build project around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within development team is face-to-face conversation.

7. Working software is the primary measure for progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

5. Build projectsaround motivated

individuals.

6. Place emphasison face-to-face

Communication.

7. Working softwareis the primary

measure of progress.

8. Promote sustainabledevelopment pace.

THE 12 AGILE PRINCIPLES (3/3)

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflect on how to become more effective, then tunes and adjusts its behavior accordingly.

9. Continuous attentionto technical excellence

and good design.

10. Simplicity isEssential.

11. The best resultsemerge from

self-organizing teams.

12. Team reflectsregularly where

and how to improve.

Source: www.agilemanifesto.org

AGILE VALUES…

Fact corner:Agile manifesto is firstof its kind in the field ofSoftware engineering

FEATURE USAGE RATE

Never45%

Rarely19%

Sometimes16%

Often13%

Always7%

Source: Jim Johnson of theStandish Group, Keynote Speech XP 2002

Fact corner:> 60% features neveror rarely used!

One In Seven Enterprises Uses Agile, And Other Will Soon Follow

November 2005 Trends “Corporate IT Leads The Second Wave Of Agile Adoption”

Large Enterprise IT Shops Now Lead In The Adoption Of Agile Processes”

November 2005, Trends “Corporate IT Leads The Second Wave Of Agile Adoption”

Large Enterprise IT Shops Now Lead In The Adoption Of Agile Processes”

November 2005, Trends “Corporate IT Leads The Second Wave Of Agile Adoption”

Time-To-Market Concerns Drive Adoption Of Agile Processes

November 2005 Trends “Corporate IT Leads The Second Wave Of Agile Adoption”

Modes of communication

EFFICIENT DEVELOPMENT SETTING

Customer

Training

- Daily feedback fromthe developers- Communication- Collaboration

Software development activities,tools, people

Results:Working software,rapid delivery,high business value

State-of-the artmethods Process

definitions

Learning

Management

Removesobstacles

Coach / Mentor

supports

Shares end-userneeds & businessrequirements

Learnsneeds

End-users

delivers

Benefits

Provides value

"Think it all":Mobile-D™ for mobile

software

MOBILE-D FOR MOBILE SOFTWARE

Concept: “From scratch idea to mobile application in 8 weeks” (java or symbian c++ based)Mobile-D is based on Extreme Programming (practices), Crystal methodologies (scalability) and Rational Unified Process (coverage)Designed to meet the specific characteristics of mobile application development & industry quality standardsDesigned for < 10 developers working in co- to closely located office space

CMMI LEVEL 2CERTIFIED

SET-UP WRAP-UPCORE-2CORE STABILIZE

1 WEEK 2 WEEKS 2 WEEKS 2 WEEKS 1 WEEK

THE PRINCIPAL ELEMENTSOF MOBILE-D

Requirements: Off-Site CustomerPlanning: Phasing and pacing in Planning DayModeling: Agile modelingArchitecture: Architecture LineMetrics: Time, size and defectDocumentation: RaPiD7-methodImprovement: Agile Software Process ImprovementEnd-users: User-Centred FocusTesting: Mobile Test-First development

SET-UP WRAP-UPCORE-2CORE STABILIZE

1 WEEK 2 WEEKS 2 WEEKS 2 WEEKS 1 WEEK

Mobile-D: FIT TO STRATEGIC PLANNING

SET-UP WRAP-UPCORE-2CORE STABILIZE

1 WEEK 2 WEEKS 2 WEEKS 2 WEEKS 1 WEEK

STRATEGIC RELEASEPLANNING

RELEASEPROJECT

INCREMENT

HEARTBEAT

Rautiainen &Vähäniitty (2004)

4 CYCLESOF CONTROL

Mobile-D

Mobile-D: FIT TO STRATEGIC PLANNING

SET-UP WRAP-UPCORE-2CORE STABILIZE

1 WEEK 2 WEEKS 2 WEEKS 2 WEEKS 1 WEEK

STRATEGIC RELEASEPLANNING

RELEASEPROJECT

INCREMENT

HEARTBEAT

Rautiainen &Vähäniitty (2004)

4 CYCLESOF CONTROL

Mobile-D

Mobile-D: FIT TO STRATEGIC PLANNING

SET-UP WRAP-UPCORE-2CORE STABILIZE

1 WEEK 2 WEEKS 2 WEEKS 2 WEEKS 1 WEEK

STRATEGIC RELEASEPLANNING

RELEASEPROJECT

INCREMENT

HEARTBEAT

Rautiainen &Vähäniitty (2004)

4 CYCLESOF CONTROL

Mobile-D

Mobile-D: FIT TO STRATEGIC PLANNING

SET-UP WRAP-UPCORE-2CORE

STRATEGIC RELEASEPLANNING

RELEASEPROJECT

INCREMENT

HEARTBEAT

4 CYCLESOF CONTROL

Mobile-D

PLANNINGDAY

WORKINGDAY

RELEASEDAY

SET-UP WRAP-UPCORE-2CORE STABILIZE

1 WEEK 2 WEEKS 2 WEEKS 2 WEEKS 1 WEEK

PLANNING DAY WORKING DAY RELEASE DAY

Mobile-D: The daily heartbeat

Contents

Agile manifestoShort introduction speaker(s)The ITEA Agile projectIntroduction to RaPiD7Agile Experiences from Philips

AGILE Project

Introduction &Highlights

ITEA-labeled projectAGILE - Agile development of embedded systems22 partners, 8 countries, 178 person years1.4.2004 – 31.12.2006http://www.agile-itea.org

CONTENTS

BackgroundProject goalsPartnersIndustry sectorsHighlights from 2004Contact information

Background

Agile software development approaches have proven their effectiveness in small-scale application level software development

10-300% increase in productivity, a 250% increase in value delivered to the customer

Other empirically supported benefits include improved implementation & estimation skills, faster product integration, fewer schedule deviations and lower defect density

Project Goal

Develop Agile software development solutions to increase the reliability, productivity and reduce risk of embedded software development

Expected results

• Agile software development framework for embedded systems domain.

• A general methodology of how to apply Agile programming for embedded systems, compliant to CMMI, SPICE, ISO

• Deployment model to enable the use of the agile software development framework

• Industrial experience reports including qualitative and quantitative data, concrete, empirical results and lessons-learned

Partners

Finland

Netherlands

Spain

Slovenia

Belgium

Bulgaria

Italy

France

Application partners Technology partners

Project manager

Industry sectors present

Highlights from 2004

Developed Agile assessment framework, Agile development patterns among others

Successful agile trialsNokia, Barco, Hantro, F-Secure, Philips, Fagor and VTTIncreased understanding about suitable agile practices & solutions

Contributing to an international upcoming IEEE 1648 standard

15 scientific publications

Contact information

For more information, contact

Project manager Pekka Abrahamsson, pekka.abrahamsson@vtt.fiVTT, Finland

Deputy managerKo Dooms, ko.dooms@philips.comPhilips, The Netherlands

http://ww.agile-itea.org

The planning intention

The reality

Contents

Agile manifestoShort introduction speaker(s)The ITEA Agile projectIntroduction to RaPiD7Agile Experiences from Philips

Experiments with RaPiD7 in Philips

Ko Dooms

Contents

Background Philips Applied TechnologiesThe case for RaPiD7Results

5 Programs

System in PackageMechatronicsDigital Systems & Technologies

ServicesIndustry Consulting & PES

The Case for RaPiD7

Start small

An important value of our department is writing of patent applications to protect Philips intellectual property

These are started with small two page documents called “white cards”

An existing patent describes

Background of the inventionProblems or disadvantages overcome with the inventionThe essential feature(s) of the inventionDetailed description of how to build or use the inventionApplications of the invention

Goal workshop

Goal: Generation of x white cards preferable related to Modena technology

Target: 3 a 4 detailed and submitted white cards, + several ideas ready for next ‘workshop’

Agenda workshop (1/2)

13.00-13.10 Opening (Ko)Roles: Facilitator Ko, Secretary Maarten, expectation from othersAgenda agreement, explaining wow, agreement on payments and names of/on generated IP

13.10-13.15 Goal workshop (Ko)13.15-13.20 One sheet introduction to RaPiD7 (Ko)13.20-13.30 Competence overview EMD (Maarten) 13.30-13.40 Domain related patent (Dennis)13.40-14.10 Gathering ideas (all)

Method: yellow stickers + round robin (A3 paper)14.20-14.30 Silent clustering ideas (all) 14.30-14.45 Clustering overview (Ko)14.45-15.00 Break

Agenda workshop (2/2)

15.00-15.45 analyzing clustered ideas (3 groups)Discussion to get clustered idea clear, regrouping or split up of yellow stickers if needed ‘One liners’ describing the ideasCheck ‘One liners’ in Google

15.45-16.30 Creating detailed white card for one liners (3 groups)

IP&S templateSave as draft

16.30-16.45 Break16.45-17.30 Presentation of created ideas (each group 15 minutes)

Fine-tuning and final decision on each ideaSubmit

17.30-17.45 ClosingAction points, follow up

Results workshop

13 white cards written by the team in one afternoonNo home workAll received AC1 statusTeam had very good feeling on the workshop

Fact box: productivity 400%increased

Results workshop

Challenges Common mistakes

Readability by the customer (for example product management and business owners)

Unnecessary documentation produced by inexperienced project people

Being able to cover everything that is required in the document e.g.:What is essential and what isn’tAre the captured items actually describing what the stakeholders of the documentation needWhere do we get the right input

Too little documentation written by experienced project people Experienced people can either be too busy with other tasks or see some aspects as too obvious to be written down

How to keep/make it consistent with other documents or project deliverables, for example code or test scripts

Achieving common understanding of the decisions written down

Result workshops

# persons total man hours # id's # white cards8 35 80 89 40 76 134 20 25 46 28 44 710 40 54 3

White card RaPiD7 workshops

Next steps

Integrate RaPiD7 into standard software development processNew projects use RaPiD7 as standard documentation methodThere is a facilitator pool that can help you with workshops:

Facilitators: Bas Bergevoet, Dennis Lomans, Alex Vrijsen, Ben van Gompel, PiotrSawicki, Dick Bos and Ko Dooms

RaPiD7 planning session

Snapshots of

RaPiD7 planning session

at