framgångsfaktorer för agil utveckling av mycket stora programvaruprodukter

Framgångsfaktorer för Agil Utveckling av Mycket Stora ProgramvaruprodukterPMI Sweden ChapterPassion for projects 2013

Svante Lidman, Senior Productivity Expertsvante.lidman@hansoft.se@svante_lidmanwww.slideshare.net/SvanteLidman

?

Large Products?Vafalls, Stora Progamvaruprodukter?

Star Wars - The Old RepublicLucas Arts, Bioware, Electronic ArtsMicrosoft

Autodesk

Ericsson

Boeing

Why Agile?

• Are we and customers happy with the lead time from idea to volume deployment?

• Are we and customers happy with product quality?

• Are we happy with R&D efficiency?

• What will our situation look like tomorrow if we continue as we do?

SalesVolume

10% Efficiency increase in R&D

10% Increased speed

(Sales earlier)

R&D (~15%)

Jan Bosch - www.janbosch.com

The Importance of Speed

Conclusion

• Conformance to original budget is secondary• Conformance to original scope is secondary• Time to market and Quality is key!!

http://commons.wikimedia.org/wiki/File:PenroseTriangle.png

The Themes of this Talk

• Look at product development holistically• All development work is not the same• Self-organization

Holistically Speaking...

8

http://commons.wikimedia.org/wiki/File:Whole_onion.jpg

What is Our Job?

Opportunity / Problem

Value /Solution

Product management &Development

Feature X

What we set out for

Feasability

Prestudy

Development

FeasabilityFeasibility

Pre-study

The Traditional Way

Feasability

Pre-study

FeasabilityFeasibility

The Traditional Way

Development

Construction

Test

Feasability

Pre-study

FeasabilityFeasibility

The Traditional Way

Construction

Test

Feasability

Pre-study

FeasabilityFeasibility

The Traditional Way

Test

Feasability

Pre-study

FeasabilityFeasibility

The Traditional Way

Part NPart 1 …

Test

Feasability

Pre-study

FeasabilityFeasibility

The Traditional Way

Part NPart 1 …

?

???

???

??

Common Challenges

• Time slicing of people• Handovers of documents resulting in distortion• Coordination issues • Quality issues uncovered too late• Lead-time too long• Very few people understand the overall system• Too many meetings• Blame games

Claim: The fragmentation of value(work)is the single most important root cause for these issues

What is Our Job?

Opportunity / Problem

Value /Solution

Product management &Development

Pre-study

Execution

Prestudy

Feasibility

Technical coordinationProject Leaders Integration Test

Program Management

ALM

FG

PG

BP4

PD1

PD2

PD3

TG1 TG2

TG3

Integration PlanningCCB

Design

Anatomy

Release Strategy

Go-model

Projects

Requirements Baseline

VisionResource Planning

Defect-handling

FEAD

1/3

2/3

System

Design

V-Model

PDU

PA

Project Plan

Business Case

CR-handling

War room

RequirementsManagement

Steering Group

Contract Management

Key Ideas

• Focus on flow, customer-to-customer– Optimize for short end-to-end lead-time – Stop-the-line mentality regarding faults

• This will expose inefficiencies and force:– Removal of handovers– Removal of overly detailed studies

and gold-plated designs– Removal of late and non-repeatable testing

• The focus on flow and lead-time will act as aforcing function to address impediments toquality and efficiency

http://commons.wikimedia.org/wiki/File:Bulbgraph.svg

Key Concepts• End-2-End Cross Functional Teams for Development• Pull based approach• Continuous programs rather than finite projects• Continuous Integration (and Testing)

– Automated, continuous, fast and reliable feedback to teams• Requirement Areas (RA) as scaling concept

– Yearly budgeting (in terms of teams) per RA coupled to business strategy– Independent prioritization per RA– Limits competence challenge for Teams without code ownership

http://commons.wikimedia.org/wiki/File:Stock_keyring.svg

Flow Based OrganizationAnalysisProgram

DevelopmentProgram

- Identify- Analyze- Prioritize

- Detail- Design- Implement- Test- Document

- Package- Verify- Roll out

ReleaseProgram(Project)

Seen Another Way…

Release Program (Projects)

Meanwhile @ Spotify...

23Henrik Kniberg, Anders Ivarsson http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

25

http://commons.wikimedia.org/wiki/File:Pears_%26_Apples.jpg

All Software is not the Same

Custom Hardware + Firmware

OS Extensions (e.g. Protocols, Scalability, Security etc.)

Device Drivers

Domain General

Domain Specific

Application Specific

Features

Low Architectural Impact

Custom Hardware + Firmware

OS Extensions (e.g. Protocols, Scalability, Security etc.)

Device Drivers

Domain General

Domain Specific

Application Specific

Features

High Architectural Impact

Custom Hardware + Firmware

OS Extensions (e.g. Protocols, Scalability, Security etc.)

Device Drivers

Domain General

Domain Specific

Application Specific

Features

CodeImpact

High Architectural Impact

Custom Hardware + Firmware

OS Extensions (e.g. Protocols, Scalability, Security etc.)

Device Drivers

Domain General

Domain Specific

Application Specific

Features

Test Impact

Handling the Differences

• Low Architecural Impact– Single Team with end-

to-end ownership

• High Architectural Impact– Many teams– PO team– Anatomy to support vision

and rolling planning– May require pure test teams– Traps:

• Planning too much upfront• Locking down the plan• Disempowering the teams

30

31http://centrim.mis.brighton.ac.uk/events/irnop-2007/papers-1/Jarkvik%20et%20al.pdf

http://commons.wikimedia.org/wiki/File:Fugle,_%C3%B8rns%C3%B8_073.jpg32

Self-organization

33

Why do we want Self-organizing Teams?

34

A team is a group of people with complementary talents and skills, aligned to a common objective.

35

It is a Powerful Management Strategy

• End-to-end ownership Motivation Higher quality results

• Local decision making Adaptability Results more fit for purpose

• No hand-overs Reduced time-to-market

http://commons.wikimedia.org/wiki/File:Tic_tac_toe.svg

36

Typical Advice on Self-organization

• Don’t assign roles• Don’t assign leadership• Don’t assign tasks• Don’t say how

http://commons.wikimedia.org/wiki/File:Stop_hand_nuvola_alternate.svg

37

Foundations

Self-organization

People

38

Människor

Självorganisation

Foundations

Objectives Knowledge/Learning Communication/Feedback Way-of-working/Decision making High standards & expectations

39

Foundations

Självorganisation

People

Motivated individuals Group development

40

Motivated Individuals

Autonomy

Competence

Relatedness

Self-Determination

Theory

Self-Determination Theory, Deci and Ryan 

41

Susan Wheelan, Integrated Model of Group Development

Group Development

Dependencyand

Inclusion

Counter-dependency

andFight

Trustand

StructureWork Break up

Child Teenager Young Adult Adult Retirement

42

Grunder

Människor

Self-organization

Values Results Balance

43

Committment

Trust

Openness

Respect

Courage

Communication

Feedback Simplicity

Honesty Transparency

Authenticity

Accountability

44

Balance

Permission to failSpecialisation

LearningCentralization

ConsensusRisk/Opportunity

PlanningAnalysis

CreativityFun

Expect successGeneralisationDeliveryDecentralizationQuick/Good decisionsPrecisionImprovisationActionQuality

Boring

45

GUT of Self-organization

Values Results Balance

Motivated Individuals Groupdevelopment

Objectives Knowledge/Learning Communication/Feedback Way-of-working/Decision making High standards/Expectations

Summary

• Focus on end-to-end flow• Focus on product evolution rather than

running projects• Distinguish functional enhancements from

architectural evolution• Foster self-organization consciously

46

47

Frågor på det?

http://commons.wikimedia.org/wiki/File:Ostrich2010_2.jpg

Selected References• Creating Effective Teams (Wheelan) - http://

www.amazon.com/Creating-Effective-Teams-Members-Leaders/dp/1452217076/ref=sr_1_1?s=books&ie=UTF8&qid=1362513243&sr=1-1&keywords=susan+wheelan

• Agile Software Requirements (Leffingwell) - http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841/ref=sr_1_1?s=books&ie=UTF8&qid=1362513353&sr=1-1&keywords=leffingwell

• Drive (Pink) - http://www.amazon.com/Drive-Surprising-Truth-About-Motivates/dp/1594484805/ref=sr_1_2?s=books&ie=UTF8&qid=1362513408&sr=1-2&keywords=dan+pink

• Corps Business (Freedman) - http://www.amazon.com/Corps-Business-Management-Principles-Marines/dp/0066619793/ref=sr_1_1?s=books&ie=UTF8&qid=1362513452&sr=1-1&keywords=corps+business+the+30+management+principles+of+the+u.s.+marines

• The Principles of Product Development Flow (Reinertsen) - http://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009/ref=sr_1_1?s=books&ie=UTF8&qid=1362513506&sr=1-1&keywords=reinertsen

• Scaling Lean & Agile Development (Larman) - http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961/ref=sr_1_1?s=books&ie=UTF8&qid=1362513556&sr=1-1&keywords=larman+vodde

• The System Anatomy (Taxén ed.) - http://www.amazon.com/System-Anatomy-Lars-Taxen/dp/9144070748/ref=sr_1_3?s=books&ie=UTF8&qid=1362513689&sr=1-3&keywords=lars+taxen

• The Essence of Software Engineering (Jacobson, Ng, McMahon, Spence, Lidman) - http://www.amazon.com/The-Essence-Software-Engineering-Applying/dp/0321885953

Thanks!

Svante Lidman, Sr Productivity Expertsvante.lidman@hansoft.se@svante_lidmanwww.slideshare.net/SvanteLidman

Licensing of this Presentation

50

The artwork in this presentation is licensed under the terms defined by each respective source as indicated on each respective slide. If no source is given, then the artwork is in the public domain.

Trademarks and books, depicted in the presentation are owned by the respective tradmark owner and are only included for reference purposes and is not in any way an endorsement of the presentation contents.

If you make use of this material in whole or part, you should clearly state the source.

All original art work and the presentation as such is is licensed underCreative Commons Attribution-Share Alike 3.0 Unported license.See: http://creativecommons.org/licenses/by-sa/3.0/deed.en