Successful utilization of ESSENCE at Munich Re

Transcription

1 Successful utilization of ESSENCE at Munich Re With a grain of salt Burkhard Perkens-Golomb 18 th June 2015, SEMAT conference, Berlin

2 The characteristics of the business model, the IT applications and the AD Organisation Business Model Well established since 1880 ~ 11,000 employees ~ 28bn income in 2014 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 Applications Transactional Systems Reporting Systems Mostly expert users High complexity in data (data structures, data relationships, data rules, heterogeneity, quality etc.) Appl. Dev. Organisation ~ 1000 FTE int. + ext. Stove pipe organisation ( Services ) with tendency to silos Multisourcing & offshoring In the past: Way of working was strictly waterfallish & document-focused Weak end2end responsibility Nowadays: Moving towards iterativincremental

3 And so

4 The old way of working: The discipline-oriented setup led to a strictly sequential &artefact-based approach Project Iteration Project Manager Initiate Plan Quality Gate Quality Gate Quality Gate Hand over Specify Design Code Test Service Service Service Service 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

5 Snapshot of a discussion in the SEMSO 1) 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]

6 ESSENCE s Benefit 1: Definition of Lifecycles A standard lifecycle $ Stakeholders Opportunity Requirements System Work Way of Working Standard Recognized Represented Identified Solution Needed Conceived Initiated Principles Established Involved Value Established Bounded Approach Selected Prepared Seeded Foundation Established Inception Started Formed In Use Elaboration Coherent Demonstrable In Agreement Viable Acceptable Usable Under Control Collaborating In Place Construction Addressed Usable Ready Performing Working Well Satisfied for Deployment Addressed Fulfilled Ready (Concluded) Performing Working Well Transition Concluded Satisfied in Use Benefit Accrued Fulfilled Operational Closed Adjourned Retired Retired

7 ESSENCE s Benefit 1: Definition of Lifecycles A standard lifecycle $ Stakeholders Opportunity Requirements System Work Way of Working Standard Recognized Represented Identified Solution Needed Conceived Initiated Principles Established Involved Value Established Bounded Approach Selected Prepared Seeded Foundation Established Inception Started Formed In Use Elaboration Coherent Demonstrable In Agreement Viable Acceptable Usable Under Control Collaborating In Place Construction Addressed Usable Ready Performing Working Well Satisfied for Deployment Addressed Fulfilled Ready (Concluded) Performing Working Well Transition Concluded Satisfied in Use Benefit Accrued Fulfilled Operational Closed Adjourned Retired

8 ESSENCE s Benefit 1: Definition of Lifecycles Variants of lifecycles Exploratory Standard Small Enhancements Support

9 ESSENCE s Benefit 1: Definition of Lifecycles Enhancements for mandatory processes

10 ESSENCE s Benefit 1: Definition of Lifecycles Enhancements for optional topics

11 ESSENCE s Benefit 2: Giving more specific guidance with practices (activities, work products, etc.)

12 ESSENCE s Benefit 3: Defining company-specific practices

13 ESSENCE s Benefit 4: Combining practices to build a Way-of-Working

14 ESSENCE s Benefit 5: Linking the way of working to the organization

15 Who s using all the stuff? Well

16 Introducing ESSENCE has challenges Adoptioner: Intrinsic/Extrinsic Motivation 1. Lack of self-improving culture 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 Product: Relevance & Attractiveness I looked at the SEMAT website I don t get the idea. 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

17 Who s using all the stuff? Well Adoptioner: Intrinsic/Extrinsic Motivation 1. Lack of self-improving culture 2. In some areas very basic software Stuff must engineering issues revealed 3. We re too busy to improve be visually pleasing! People in the Big Picture? 4. No external driver for a more rigid approach ESSENCE from the trenches? Product: Relevance & Attractiveness I looked at the SEMAT website I don t get it. All methodology stuff is boring! Not relevant for me that s too sophisticated Sales Big Picture? ESSENCE makes projects look mechanical but projects aren t. As an occasional user, using the tools is hard. HIGH usability of tools

18 Thank You for Your Attention. Do You have any Questions?

19 Munich RE Essentials MR Essentials: Standard Application Development Lifecycle v 2.0 Customer Solution Endeavor $ Stakeholders Opportunity Funding Requirements Software System Work Way of Working 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. Recognized Represented Identified Solution Needed Sized Estimated Conceived Bounded Principles Established 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. Involved Value Established Approved (Coherent) Architecture Selected Initiated Prepared Seeded Foundation Established Started Formed In Use 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. Coherent Demonstrable (Collaborating) In Place In Agreement Viable Confirmed Acceptable (Usable) Under Control (Performing) (Working Well) 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. Addressed (Ready) Satisfied for Deployment Addressed Fulfilled Ready (Concluded) Transition 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 (Satisfied in Use) (Benefit Accrued) Closed Fulfilled Operational Closed (Adjourned) (Retired) Legend: Mandatory State Version th Sep (Recommended State)

20 Application Development Lifecycle v2.0 This is the default lifecycle for projects in Application Development at Munich RE. Stakeholders Opportunity Planning Baseline Executing Closing Inception Elaboration Construction Transition Invovlved Value Established Stakeholders Opportunity In Agreement Viable Stakeholders Opportunity Satisfied for Deployment Addressed Stakeholders Satisfied for Deployment (Satisfied in Use) Opportunity Addressed (Benefit Accrued) Preparation Entry Criteria & Essential Inputs Stakeholders Invovlved The stakeholders representatives are actively involved in the work and fulfilling their responsibilities. Funding (Investment Approval: authorizes any additional spend needed to complete Elaboration) Requirements Approved Bounded (Coherent) Funding Confirmed 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 Requirements Acceptable Funding (Investment Approval: authorizes any additional spend needed to complete the project) (Cost Sheet: reflects any revised estimates) Requirements Confirmed Fulfilled Funding Requirements Feature List: scopes the release Feature List: prioritizes the release's content Feature List: complete for release Feature List: complete for release (Investment Approval: authorizes any additional spend needed to complete the project) (Cost Sheet: reflects any revised estimates) Closed Fulfilled Opportunity Value Established 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). Funding Approved The expected total cost of the project has been estimated, and funding has been approved for the implementation project. 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 Requirements Bounded (Coherent) The stakeholders have a common understanding of the scope of the proposed solution and its value to the business. 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 Supporting Information: identifies architectural drivers and captures key concepts (important use cases Story Structure Use Case {1..n} Understood) all others Goal Established (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) (Test Strategy: scopes the extent of testing) Architecture Work Initiated There is a shared understanding of the project purpose, and some of the key challenges facing it. Project Charter: defines the desired outcomes (Risk Register: initial project risks identified) Candidate Solution Identified Business Commitment Established / Solution Constraints Understood Use-Case Model: shows the extent and value of the new system Supporting Information: supports the use-case model in describing the system Use Case {1..n} (Use-Case Realization: to describe critical collaborations) Software System Component {1..n} Test {1..n} Bug {n} Work Iteration {1..n} Risk {n} Use-Case Slice {1..n} Change {n} Architecture Selected Design Model: clarifies the critical components to be developed / changed (Build: for a prototype or proof-of-concept) Architecture Candidate Solution Identified (critical components Responsibilities Assigned) (to prove the architecture Specified to test the proof of concept Evaluated) (for reused components Identified) Started Schedule: defines internal and customer-facing milestones, and outlines the phases and iterations Backlog: set up and bounded Story Structure Understood the most important Scoped scope-related possibly Requested Project Status Report {n}: updated to include all known technical risks last Inception Closed 1st Elaboration Objectives Agreed Human Resource Plan: identifies the roles and individuals business risks Addressed top 10 Assessed Formed Project Commitment Established / (Proof of Concept Demonstrated) Use-Case Model: reflects the agreed scope Supporting Information: reflects the agreed scope defining all terms used in the use cases Use Case {1..n} architecturally significant Simplest Story Fulfilled Use-Case Realization: describes the impact of the architecturally significant use-case slices architecturally significant Verified Use-Case Slice {1..n} all others Scoped Change {n} Software System Design Model: describes skinny system Component {1..n} Test {1..n} Bug {n} Work Under Control Schedule: timeline and dates updated to reflect actual progress and revised estimates Iteration {1..n} Risk {n} Demonstrable (Usable) Build {n}: for the architectural spikes (Test Strategy: describes the testing approach for the architectural aspects of the system) Architecture Established key components critical operations Verified those that prove the architecture Evaluated all open defects Assessed those compromising the architecture Closed Backlog: tracks and prioritizes the release contents all Assessed those accepted Specified Project Status Report {n}: provides snapshot of project health Scope Statement: states agreed scope of the project 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 Commitment Confirmed / Solution Approach Proven Use-Case Model: complete for release Supporting Information: complete for release Use Case {1..n} Sufficient Stories Fulfilled (All Stories Fulfilled) Use-Case Realization: describe the impact of all in scope use cases all included in release Verified Use-Case Slice {1..n} Change {n} Software System Design Model: describes the entire system Build: for the complete solution Architecture Component {1..n} Work Under Control (Concluded) Schedule: timeline and dates updated to reflect actual progress and revised estimates Backlog: demonstrates the release's scope Iteration {1..n} Risk {n} all Assessed those accepted Verified Project Status Report {n}: provides snapshot of project health Ready all Verified all (incl. regression, integration and system tests) Test {1..n} Evaluated Bug {n} Validated those compromising the release Closed all others Assessed last Construction Closed 1st Transition Objectives Agreed logistical risks Addressed top 10 Assessed Formed (Performing Human Resource Plan: describes the team structure for the transition phase Business Ready / Complete Useable Solution Available (Use-Case Model: kept up to date) (Supporting Information: kept up to date) Use Case {1..n} Sufficient Stories Fulfilled (All Stories Fulfilled) Use-Case Narrative: describe the most important use cases Use-Case Narrative: describes architecturally significant use cases Use-Case Narrative: describe all in scope use cases Use-Case Narrative: describe all in scope use cases Use-Case Realization: describe the impact of all in scope use cases (Test Case {n}: to verify the most important slices) 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 (Test Strategy: scopes the extent of testing) (Test Strategy: describes the testing approach for the complete solution) all included in release Verified Use-Case Slice {1..n} Change {n} Software System (Design Model: kept up tp date) (Build: kept up to date) Architecture Component {1..n} Test {1..n} all affected by change Evaluated those for 3rd-part integration and acceptance Evaluated Bug {n} Work Schedule: shows the history of the project (Backlog: kept up to date) Iteration {1..n} Risk {n} all Assessed those accepted Verified Project Evaluation Report: captures the achievements of the project, customer sign-off, historical data, and final costs Closed last Acceptance Closed customer acceptance risks Addressed remaining risks Assessed (Human Resource Plan: shows the recent team structure) Operational (Test Strategy: describes the testing approach for hotfixes and further small enhancements during maintenance) Validated all Released those compromising the release Closed all others Assessed Formed (Adjourned) Solution Delivered / Solution In Use 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. Way of Working Project Management Plan: describes the recommended approach In Use 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 In Place (Working Well) Project Management Plan: describes the approach to be used for Construction 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. Way of Working Project Management Plan: tuned to reflect lessons learned In Place (Working Well) 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. Version th Sep Way of Working Project Management Plan: documents a successful approach In Place (Retired) 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.