Successful utilization of ESSENCE at Munich Re
With a grain of salt …
Burkhard Perkens-Golomb
18th June 2015, SEMAT conference, Berlin
The characteristics of the business model,
the IT applications and the AD Organisation
Business Model
Applications
Appl. Dev. Organisation
 Well established since
1880
 Transactional Systems
 ~ 1000 FTE int. + ext.
 Reporting Systems
 ~ 11,000 employees
 Mostly expert users
 ~ €28bn income in 2014
 High complexity in data
(data structures, data
relationships, data rules,
heterogeneity, quality etc.)
 Stove pipe organisation
(„Services“) with tendency
to silos
 Pure B2B
 Not many customers, not
many contracts
 High diversity w.r.t.
geography & lines of
business
 Big volume of money and
data per contract
 Complex contracts
 Multisourcing & offshoring
 In the past:
• Way of working was
strictly waterfallish &
document-focused
• Weak end2end
responsibility
 Nowadays: Moving
towards iterativincremental
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
2
And so …
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
3
The old way of working: The discipline-oriented setup
led to a strictly sequential &artefact-based approach
“Iteration”
Project
Initiate
Hand
over
Plan
Project
Manager
Quality
Gate
Quality
Gate
Specify
Service
Team
Design
Service
Team
Quality
Gate
Code
Service
Team
Test
Service
Team
Sequential activities with formal artefact-based hand-over from one service
to the next, ‘orchestrated’ by a Project Manager, each service with a
specific way-of-working focused on their own activities.
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
4
Snapshot of a discussion in the SEMSO1) group …
1) SEMSO = Software Engineering in a Multisourcing Organization
 No common
understanding of
particular work
products
 Different levels of
detail for work
products in mind
 Different work
products can be
used for the same
purpose
No common
language for the
discussion of a
way of working!
The Confusion of Tongues
by Gustave Doré (1865)
[Wikipedia]
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
5
ESSENCE’s Benefit 1: Definition of Lifecycles
A standard lifecycle
$
Stakeholders
Standard
Recognized
Opportunity
Requirements
System
Work
Team
Way of Working
Identified
Conceived
Represented
Solution Needed
Involved
Value
Established
Bounded
Principles
Established
Initiated
Approach
Selected
Prepared
Seeded
Foundation
Established
Started
Formed
In Use
Under
Control
Collaborating
In Place
Performing
Working Well
Performing
Working Well
Adjourned
Retired
Inception
Elaboration
In Agreement
Viable
Coherent
Demonstrable
Acceptable
Usable
Usable
Construction
Addressed
Satisfied for
Deployment
Addressed
Fulfilled
Ready
Ready
(Concluded)
Concluded
Transition
Satisfied in Use
Benefit Accrued
Fulfilled
Operational
Closed
Retired
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
6
ESSENCE’s Benefit 1: Definition of Lifecycles
A standard lifecycle
$
Stakeholders
Standard
Recognized
Opportunity
Requirements
System
Work
Team
Identified
Solution Needed
Involved
Value
Established
Bounded
Principles
Established
Initiated
Conceived
Represented
Approach
Selected
Way of Working
Prepared
Seeded
Foundation
Established
Started
Formed
In Use
Under
Control
Collaborating
In Place
Performing
Working Well
Performing
Working Well
Adjourned
Retired
Inception
Elaboration
In Agreement
Viable
Coherent
Demonstrable
Acceptable
Usable
Usable
Construction
Addressed
Satisfied for
Deployment
Addressed
Fulfilled
Ready
Ready
(Concluded)
Concluded
Transition
Satisfied in Use
Benefit Accrued
Fulfilled
Operational
Closed
ESSENCE’s Benefit 1: Definition of Lifecycles
Variants of lifecycles
Exploratory
Standard
Small Enhancements
Support
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
8
ESSENCE’s Benefit 1: Definition of Lifecycles
Enhancements for mandatory processes
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
9
ESSENCE’s Benefit 1: Definition of Lifecycles
Enhancements for optional topics
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
10
ESSENCE’s Benefit 2: Giving more specific guidance
with practices (activities, work products, etc.)
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
11
ESSENCE’s Benefit 3: Defining company-specific
practices
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
12
ESSENCE’s Benefit 4: Combining practices to build a
Way-of-Working
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
13
ESSENCE’s Benefit 5: Linking the way of working to
the organization
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
14
Who‘s using all the stuff? Well …
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
15
Introducing ESSENCE has challenges
Adoptioner:
Intrinsic/Extrinsic Motivation
Product:
Relevance & Attractiveness
1. Lack of self-improving culture
 „I looked at the SEMAT website –
I don‘t get the idea.“
2. In some areas very basic software
engineering issues revealed
3. „We’re too busy to improve“
4. No external driver for a more rigid
approach
 „All methodology stuff is boring!“
 „Not relevant for me – it’s too
sophisticated“
 „ ESSENCE makes projects look
mechanical – but projects aren’t.“
 „As an occasional user, using the tools
is hard.“
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
16
Who‘s using all the stuff? Well …
Adoptioner:
Intrinsic/Extrinsic Motivation People in
the Big
1. Lack of self-improving culturePicture?
2. In some areas very basic
software
Stuff must
engineering issues revealed
be visually
pleasing!
3. „We’re too busy to improve“
4. No external driver for a more
rigid
„ESSENCE
approach
from the
trenches“?
Product:
Relevance & Attractiveness
Sales Big
Picture?
 „I looked at the SEMAT website –
I don‘t get it.“
 „All methodology stuff is boring!“
 „Not relevant for me – that’s too
sophisticated“
 „ESSENCE makes projects look
mechanical – but projects aren’t.“
 „As an occasional user, using the tools
is hard.“
HIGH
usability of
tools
Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb
22.06.2015
17
Thank You for Your Attention.
Do You have any Questions ?
Munich RE
Essentials
MR Essentials:
Standard Application Development Lifecycle – v 2.0
Customer
Solution
Endeavor
$
Preparation
The aim of this phase is to identify the business need for the
project, and secure funding to start it. For complex, risky, or novel
projects, more detailed work may be need to be done for funding to
be obtained.
Stakeholders
Opportunity
Recognized
Identified
Represented
Involved
Inception
A short phase (usually only one quick iteration) to get the delivery
team up and running, and the initial plans in place. Ideally a proofof-concept is produced to show understanding of the problem and
technology.
Elaboration
The purpose of this phase is to address the technical risks facing the
project and produce a baseline plan with committed dates and costs.
To do this the project risks must be brought down to an acceptable
level by increasing the understanding of the requirements and
proving the architecture by implementing critical parts of the system.
This may take many iterations.
Solution Needed
Value Established
Funding
Sized
Requirements
Software System
Work
Team
Principles Established
Conceived
Estimated
Bounded
Approved
(Coherent)
Way of Working
Architecture Selected
Initiated
Seeded
Foundation Established
Formed
In Use
(Collaborating)
In Place
(Performing)
(Working Well)
(Adjourned)
(Retired)
Prepared
Started
Coherent
Demonstrable
In Agreement
Viable
Confirmed
Acceptable
(Usable)
Under Control
Usable
Construction
The longest phase of the project where the system is built iteratively
and incrementally, addressing the customer's requirements in
whatever order the customer requires. A usable, production quality
system is maintained at all times.
Satisfied
for Deployment
Transition
Addressed
Addressed
(Ready)
Fulfilled
Ready
During this phase the system is accepted by the customer and goes
live. Information critical to the running and maintenance of the
system is handed over. Historical data and lessons learned are
recorded to improve future projects.
(Concluded)
Concluded
(Satisfied in Use)
(Benefit Accrued)
Closed
Fulfilled
Operational
Closed
Legend:
Mandatory State
(Recommended State)
Version 2.0 – 28th Sep. 2014
Planning Baseline
Application
Development
Lifecycle – v2.0
Inception
Stakeholders
This is the default lifecycle for projects in
Application Development at Munich RE.
Opportunity
Preparation
Invovlved
Supporting Information: identifies architectural drivers and captures key
concepts
(important use cases Story Structure
Understood) all others Goal Established
Use Case {1..n}
(Use-Case Narrative: outlines the most important use cases)
Software System
Architecture Selected
A candidate architecture has been selected from the
initial understanding of the requirements.
This
architecture will be tested and evolved through the
whole lifecycle.
(Design Model: identifies critical components to be developed / changed)
Use-Case Model: reflects the agreed scope
Use-Case Model: complete for release
(Use-Case Model: kept up to date)
Supporting Information: reflects the agreed scope defining all terms used in
the use cases
Supporting Information: complete for release
(Supporting Information: kept up to date)
Initiated
There is a shared understanding of the project
purpose, and some of the key challenges facing it.
(Use-Case Realization: to describe critical collaborations)
the most important Scoped
scope-related possibly Requested
Change {n}
Software System
Architecture Selected
Design Model: clarifies the critical components to be developed / changed
(Build: for a prototype or proof-of-concept)
(Test Strategy: scopes the extent of testing)
Candidate Solution Identified
Architecture
Component {1..n}
Test {1..n}
(critical components
Responsibilities Assigned)
(to prove the architecture Specified
to test the proof of concept Evaluated)
Bug {n}
(for reused components Identified)
Work
Started
Schedule: defines internal and customer-facing milestones, and outlines
the phases and iterations
Backlog: set up and bounded
Project Status Report {n}: updated to include all known technical risks
Use Case {1..n}
Sufficient Stories Fulfilled (All Stories Fulfilled)
Sufficient Stories Fulfilled (All Stories Fulfilled)
Use-Case Narrative: describe all in scope use cases
Use-Case Narrative: describes architecturally significant use cases
(Test Case {n}: to verify the most important slices)
Iteration {1..n}
Risk {n}
last Inception Closed
1st Elaboration Objectives Agreed
business risks Addressed
top 10 Assessed
Team
Project Charter: defines the desired outcomes
Formed
Use-Case Narrative: describe all in scope use cases
Use-Case Realization: describes the impact of the architecturally
significant use-case slices
Use-Case Realization: describe the impact of all in scope use cases
Use-Case Realization: describe the impact of all in scope use cases
Test Case {n}: prove the architectural aspects of the system
Test Case {n}: prove the system meets the requirements
Test Case {n}: prove the system meets the requirements
architecturally significant Verified
all others Scoped
Use-Case Slice {1..n}
all Assessed
those accepted Specified
Change {n}
Software System
Demonstrable (Usable)
Design Model: describes “skinny” system
Build {n}: for the architectural spikes
(Test Strategy: describes the testing approach for the architectural
aspects of the system)
Established
Architecture
key components’ critical operations
Component {1..n}
Verified
Test {1..n}
Bug {n}
those that prove the architecture Evaluated
all open defects Assessed
those compromising the architecture Closed
Work
Under Control
Use-Case Slice {1..n}
all included in release Verified
all Assessed
those accepted Verified
Change {n}
Software System
Ready
Design Model: describes the entire system
Build: for the complete solution
(Test Strategy: describes the testing approach for the complete solution)
Validated
Architecture
all Verified
Component {1..n}
all (incl. regression, integration and system tests)
Test {1..n}
Evaluated
Bug {n}
those compromising the release Closed
all others Assessed
Work
Under Control (Concluded)
all included in release Verified
Use-Case Slice {1..n}
all Assessed
those accepted Verified
Change {n}
Software System
Operational
(Design Model: kept up tp date)
(Build: kept up to date)
(Test Strategy: describes the testing approach for hotfixes and further
small enhancements during maintenance)
Validated
Architecture
all Released
Component {1..n}
all affected by change Evaluated
those for 3rd-part integration and acceptance Evaluated
Test {1..n}
Bug {n}
those compromising the release Closed
all others Assessed
Work
Closed
Schedule: timeline and dates updated to reflect actual progress and
revised estimates
Schedule: timeline and dates updated to reflect actual progress and
revised estimates
Backlog: tracks and prioritizes the release contents
Backlog: demonstrates the release's scope
(Backlog: kept up to date)
Project Status Report {n}: provides snapshot of project health
Project Status Report {n}: provides snapshot of project health
Project Evaluation Report: captures the achievements of the project,
customer sign-off, historical data, and final costs
Way of Working
Seeded
There is agreement of what the team is to achieve, and
what structure would be suitable for that goal.
Human Resource Plan: outlines the desired team structure for the
planning baseline phase (Inception and Elaboration)
The aim of this phase is to identify the business need
for the project, and secure funding to start it. For
complex, risky, or novel projects, more detailed work
may be need to be done for funding to be obtained.
Iteration {1..n}
Risk {n}
Team
last Elaboration Closed
1st Construction Objectives Agreed
technical risks Addressed
top 10 Assessed
Formed (Performing)
Human Resource Plan: describes the team structure for the construction
phase
Human Resource Plan: identifies the roles and individuals
(Risk Register: initial project risks identified)
Team
architecturally significant Simplest Story Fulfilled
Use-Case Narrative: describe the most important use cases
Use-Case Slice {1..n}
Use Case {1..n}
Use Case {1..n}
Schedule: shows the history of the project
Scope Statement: states agreed scope of the project
Candidate Solution Identified
Work
Fulfilled
Supporting Information: supports the use-case model in describing the system
(Test Strategy: scopes the extent of testing)
Architecture
Requirements
Fulfilled
In Use
Project Management Plan: describes the recommended approach
A short phase (usually only one quick iteration) to get
the delivery team up and running, and the initial plans
in place. Ideally a proof-of-concept is produced to show
understanding of the problem and technology.
Way of Working
Iteration {1..n}
Risk {n}
Team
logistical risks Addressed
top 10 Assessed
last Acceptance Closed
Iteration {1..n}
Risk {n}
customer acceptance risks Addressed
remaining risks Assessed
Team
Formed (Performing
Human Resource Plan: describes the team structure for the transition
phase
Way of Working
In Place (Working Well)
Project Management Plan: describes the approach to be used for
Construction
last Construction Closed
1st Transition Objectives Agreed
In Place (Working Well)
Project Management Plan: tuned to reflect lessons learned
The purpose of this phase is to address the technical
The longest phase of the project where the system is
risks facing the project and produce a baseline plan with
built iteratively and incrementally, addressing the
committed dates and costs. To do this the project risks
customer's requirements in whatever order the
must be brought down to an acceptable level by
customer requires. A usable, production quality system
increasing the understanding of the requirements and
is maintained at all times.
proving the architecture by implementing critical parts of
the system. This may take many iterations.
Version 2.0 – 28th Sep. 2014
Formed (Adjourned)
(Human Resource Plan: shows the recent team structure)
Way of Working
In Place (Retired)
Project Management Plan: documents a successful approach
During this phase the system is accepted by the
customer and goes live. Information critical to the
running and maintenance of the system is handed over.
Historical data and lessons learned are recorded to
improve future projects.
Solution Delivered / Solution In Use
Feature List: captures the capabilities, services or qualities that the
customers most desire from this release of the system
Use-Case Model: shows the extent and value of the new system
(Cost Sheet: reflects any revised estimates)
Business Ready / Complete Useable Solution Available
Bounded (Coherent)
The stakeholders have a common understanding of
the scope of the proposed solution and its value to the
business.
(Cost Sheet: reflects any revised estimates)
Use-Case Model: shows the extent and value of the new system
Commitment Confirmed / Solution Approach Proven
Requirements
Closed
(Investment Approval: authorizes any additional spend needed to
complete the project)
Feature List: complete for release
Project Commitment Established / (Proof of Concept Demonstrated)
Investment Approval: authorizes the spend for the planning baseline phase
(Inception and Elaboration)
Need for Budget: states the expected cost of the project
Statement of Feasibility: shows that the project is feasible from a resource
and portfolio point of view
Confirmed
Feature List: complete for release
Story Structure Understood
Business Commitment Established / Solution Constraints Understood
Approved
Addressed (Benefit Accrued)
Funding
(Investment Approval: authorizes any additional spend needed to
complete the project)
Requirements
Acceptable
Opportunity
Feature List: prioritizes the release's content
Use Case {1..n}
The value of addressing the opportunity has been
quantified either in absolute terms or in returns or
savings per time period (e.g. per annum).
The expected total cost of the project has been
estimated, and funding has been approved for the
implementation project.
Bounded (Coherent)
Stakeholders
Satisfied for Deployment (Satisfied in Use)
Addressed
Funding
Confirmed
Requirements
Transition
Satisfied for Deployment
Opportunity
Viable
Investment Approval: provides approval to execute authorizing the spend for
Construction and Transition
Cost Sheet: replaces the need for budget with new estimate to complete
Feature List: scopes the release
Value Established
Stakeholders
In Agreement
Funding
Approved
Closing
Construction
Opportunity
Value Established
Requirements
The stakeholders representatives are actively involved
in the work and fulfilling their responsibilities.
Funding
Stakeholders
(Investment Approval: authorizes any additional spend needed to
complete Elaboration)
Entry Criteria & Essential Inputs
Opportunity
Elaboration
Invovlved
Funding
Stakeholders
Executing