and DevOps, a successful marriage or recipe for...EO.CO PRINCE2® and DevOps, a successful marriage...

PRINCE2® and DevOps, a successful marriage or recipe for divorce?Henny Portman

White paperNovember 2020

Contents1 Introduction 03

2 The PRINCE2 governance structure 03

3 DevOps in a nutshell 05

4 A permanent DevOps team versus a temporary PRINCE2 delivery team 08

5 How to cope with DevOps teams from a PRINCE2 project manager 08 perspective

6 How to cope with the PRINCE2 governance from a DevOps team 09 perspective

7 Blending PRINCE2 and DevOps 11

8 Summary 11

9 About the author 12

10 Endnotes 13

11 About AXELOS 15

12 Trade marks and statements 15

02 PRINCE2® and DevOps, a successful marriage or recipe for divorce? AXELOS.COM

PRINCE2® and DevOps, a successful marriage or recipe for divorce? 03AXELOS.COM

1 IntroductionMore and more organizations are incorporating DevOps into their working practices in order to get more done. With DevOps, a single team composed of collaborative, cross-functional members will:

z deliver features faster and continuously z have more time to innovate z enjoy a stable operating environment z be happier and more engaged z solve production issues faster.

In DevOps a business perspective1 the author Oleg Skrynnik provides the following definition for DevOps:

‘DevOps is an evolution of the ideas of agile software development and lean manufacturing, applied to the end-to-end value chain in IT, which allows businesses to achieve more with

modern information technology due to cultural, organizational and technical changes.’

Does this mean that having a DevOps team is the silver bullet that would solve all your problems?

I wish it was, but life is not that easy. What if you need more than one DevOps team to develop the solution? No problem, you can use scaling frameworks like Scaled Agile Framework (SAFe), Large-scale Scrum (LeSS), Nexus, and many more. This will probably solve several of your collaboration or dependency problems, but what if the initiative needs more than IT or product related changes? What if there are no permanent (DevOps) teams who have the necessary skills to deliver what is needed? In that case, you will probably need to implement a temporary project organization to combine the DevOps pieces with a project manager, who manages the dependencies between teams and performs stakeholder management, budget management, and so on.

In this white paper I will explore how PRINCE2®, Agile2, and DevOps can work together. I will start with an explanation of the PRINCE2 governance structure, followed by a brief introduction of DevOps. Next, I will compare a temporary PRINCE2 delivery team with a permanent DevOps team. I will then explore the relationship between the DevOps team and the project manager and how a DevOps team deals with PRINCE2 governance. In the last section I will combine the two approaches.

2 The PRINCE2 governance structureIn PRINCE2, the division between accountabilities and responsibilities in a project is clear. Where needed, the segregation of duties is safeguarded. Moreover, the effectiveness of delegating project work is crucial to a project’s success.

The project board has authority and responsibility for the project. Corporate, programme management, or the customer sets the boundaries within which the project board can act.

The executive is accountable for the project and has ultimate decision-making authority, within the project board.

The senior supplier (supplier representative) represents the interests of those designing, developing, facilitating, procuring, and implementing the project’s products. This role is accountable for the quality of products delivered by the supplier(s) and is responsible for the technical integrity of the project.


The senior user (or customer/user representative) specifies the benefits. They are held to account by demonstrating to the business (such as corporate, programme management, or the customer) that the forecast benefits that supported project approval, have been realized or are in the process of being realized. The senior user is responsible for ensuring that the product is driven by the need to deliver the stated benefits. These benefits may not be realized within the project’s lifetime.

Day-to-day management of the project is delegated to the project manager. The project manager manages the project on a stage by stage basis, based on an approved stage plan. As long as the project manager can deliver the stage within the planned tolerances, there is no need for the project board members to maintain close contact with the project work. The end of a stage represents a major milestone in the project and gives the project board the opportunity to review the previous stage and the next stage plan. Based on this review and whether there is still a viable business case (delivering value to the customer), the project board can decide to continue with the project.

The PRINCE2 project management team structure is illustrated in Figure 2.1.

Figure 2.1 The PRINCE2 project management team3

Management jobs do not need to be allocated to people on a one-to-one basis. PRINCE2 defines roles, each of which comes with an associated set of responsibilities. These roles might be allocated, shared, or combined according to the project’s needs.

The project board members each have a specific area of focus for project assurance, namely business assurance for the executive, user assurance for the senior user(s), and supplier assurance for the senior supplier(s). This can be delegated to one or more people (project assurance).

It is the project board’s responsibility to agree to each potential change before it is implemented. For example, if the project is likely to exceed the tolerances agreed by the project board to the project manager. This responsibility can be delegated to the change authority.

The project manager will run the project on behalf of the project board. The project manager can delegate the responsibility for delivering the project’s output to team managers and can delegate some of the support work, such as creating progress reports, to project support. Project support is a project information

Project assurance:

business, user and supplier

assurance

Corporate, programme management or the customer

Team members

Projectmanager

Changeauthority

Projectsupport

Teammanager(s)

Lines of authority

Project assurance responsibility

Lines of support/advice

Within the project management team

From the customer

From the supplier

Project board

Senioruser(s)

Seniorsupplier(s)Executive


repository and provides potentially useful reports.

In cases where the project manager uses self-organizing delivery teams (agile teams), the project management team structure could change slightly.

Figure 2.2 illustrates a PRINCE2 project management team structure that contains one or more agile and traditional teams. Compared to Figure 2.1, there are the additional roles of customer subject matter expert (customer representative), supplier subject matter expert (supplier representative), team quality assurance (customer and supplier), and coach. The team manager role could be created, omitted, or someone in the team could act as a single point of contact for the project manager. If there is no team manager, the project manager is responsible for allocating the team’s work with the customer (for example the team’s product owner or customer representative) and/or team representatives.

Figure 2.2 The PRINCE2 project management team4

3 DevOps in a nutshell

3.1 INTRODUCTION TO DEVOPSDevOps is not a method or a framework; instead it is a mindset or culture and a set of principles and technical practices. It provides automation to facilitate continuous integration, automated testing, and continuous deployment (CI/CD). It supports communication and cooperation between all people who plan, develop, test, deploy, release, support, and maintain a product or service.

DevOps can be used to bridge the gap between developers and operations, by bringing both together into one team, to deliver value to the end-user and eliminate indirect involvement between development and operations silos. In other words, to blur the

“DevOps is not a method or a framework; instead it is a mindset or culture and a set of

principles and technical practices.”


lines between development and operations, so that new functionalities flow easier from development into production.

The DevOps concept reduces the tension between the developers, who create the new functionality, and the operations staff who maintain the stability of the solution in production.

DevOps helps organizations to1:

z Reduce time to market: perform business idea testing and hypothesis evaluation by using Eric Ries’ concept of the minimum valuable product.

z Reduce technical debt: debt occurs when a programmer chooses a nonoptimal way to solve a problem to reduce the development time.

z Eliminate fragility: fragile systems need stability and must therefore be changed as little as possible; any changes that are made must be checked before and after the intervention.

DevOps is based on five principles1:

z Value stream: creating value in response to a customer’s request. z Deployment pipeline: the most automated transition step of the value stream, starting from the completion of development to deployment into operations, which includes continuous integration, delivery, and deployment.

z Everything is stored in a version control system: this includes, source code, tests, scripts, artefacts, libraries, documentation, configuration files, and development tools.

z Automated configuration management: any changes to an environment can only be made by scripts stored in a version control system.

z The definition of done: the creation of new functionality is achieved only when the application is running in the production environment and all the assembly, testing, and deployment activities are done automatically.

3.2 DEVOPS DIMENSIONS (CALMS)DevOps can be divided into five dimensions, often represented by CALMS5 or CALMR, which stands for:

z Culture: the most important dimension of the DevOps movement. Key practices in this area are system thinking, continuous improvement (Kaizen), fail-fast to learn fast, agile ways of working (for example Scrum, Kanban), reduction in silo mentality, reduction of technical debt, and the usage of retrospectives to adapt.

z Automation: this will help to accelerate the time to market by creating a continuous delivery pipeline (continuous integration, automated testing, and continuous delivery), and by using the concept of infrastructure as code.

z Lean: to achieve a continuous flow of delivery of new functionality by using small batches, manage/reduce queue lengths, and visualize and reduce the work in progress (WIP) limit.

z Measurement: measures are key as decisions must be made based on facts and data, not opinions. How long will it take to deliver a requested function? What is the mean time to repair a bug? How many open tickets, number of users, response time, and so on? Therefore, on the developer side, it is very important that they provide onboard monitoring services or application telemetry in the provided applications.

z Sharing: this is based on three components: visibility, transparency, and knowledge transfer.


3.3 PLANNING HORIZONDevOps teams (sometimes called manufactory teams) use a high-level uncommitted roadmap to achieve midterm or long-term goals. This roadmap gives an idea of when a piece of work (project, epic, or feature) could be developed. The roadmap is uncommitted, to make it possible for the team to react on new more value-added customer demand.

The most widely used way of working to meet short-term goals is Kanban. Scrum is also used.

Gene Kim describes in his book The Phoenix Project6 the four types of work for a DevOps team (classes of service). These are:

z business projects z internal IT projects z changes z unplanned work or recovery work.

Kim explains that development, quality assurance, compliancy, and operations must work closely together in the DevOps team. Within this team, three ways of working must be integrated by using a Kanban system:

z The first way is a left-to-right flow of work from development to IT operations to the customer. This flow needs to be maximized by managing the WIP and have continuous build, integration, and deployment practices (CI/CD).

z The second way is about the constant flow of fast feedback from right-to-left at all stages of the value stream.

z The third way is about creating a culture that fosters two things: z continual experimentation, which requires taking risks and learning from success z failure and understanding that repetition and practice are the prerequisites to mastery.

When using Scrum, the requested features must be included in the DevOps team product backlog, together with changes, and unplanned or recovery work.

“The most widely used way of working to meet short-term goals is Kanban.

Scrum is also used.”


4 A permanent DevOps team versus a temporary PRINCE2 delivery teamIf we compare a temporary PRINCE2 delivery team and a permanent DevOps team, we see similarities as well as differences. Table 4.1 shows the comparison.

Table 4.1 Comparison between a PRINCE2 delivery team and a DevOps team

5 How to cope with DevOps teams from a PRINCE2 project manager perspectiveThe DevOps team is a permanent team, so there is no need to build the team. DevOps teams are cross-functional, and every individual team member has a responsibility for the quality of the product. Consequently, each team member has individual ownership in the end result. The team members have common goals and have the same prioritization of system value. Collaboration and continual feedback mean that everyone knows what is going on in every step of the process. Team members are working together for the common goals.

With DevOps, no one is blamed when things go wrong. Failure is anticipated and used to achieve better quality products or services in the future. DevOps requires value-driven behaviours from the team members, where there is continuous learning with an end goal in mind. This practice enables fast delivery

PRINCE2 delivery team DevOps team

Strategy Team is moved to the work Work is moved to the team

Appearance Temporary Permanent

Management Team manager Self-organizing

Assignment Work package Customer demand (epic, feature, user story)

Composition Multidisciplinary Multidisciplinary, multiskilled ‘generalizing specialists’

Balanced To be structured by the project manager (for example, Belbin team role inventory)

Team is in place and is effective. To become a high performing team, they can still perform retrospectives

Team member availability

Part-time or full-time Full-time

Team size Small to large Small: 5-8 people, “If you can’t feed a team with two pizzas, it’s too large.” Jeff Bezos, Amazon15

Generic scope Change Change and run

Ways of working Any Lean, Agile, Scrum, Kanban, IT&SM

Quality assurance

Independent project assurance (of the team) Within the DevOps team (passing quality criteria, using retrospectives)

Approach PRINCE2: scope is fixed during this stage, budget and duration can fluctuate depending on delivery issues

PRINCE2 Agile: scope is flexible, duration, and budget (team set-up) are fixed

Budget (team set-up) is fixed, duration can be fixed (scrum) or flexible (Kanban), scope can change


and a higher level of quality, because the team is adaptable and changes with the project’s needs7.

When creating teams, the project manager must decide if they want to appoint a team manager or if they will be performing this role. A DevOps team does not ordinarily have a team manager, but the project manager still needs a single point of contact. This single point of contact could be anyone from the DevOps team. Most likely, it will be the scrum master or it might be the product owner (if these roles are used).

The project manager uses a work package as a vital interface/link to blend the project environment with the DevOps team. This work package will be collaboratively defined between the project manager and the DevOps team, as a single point of contact. It contains the agreed levels of detail, formality, and transparency with respect to reporting, tolerances, and product descriptions. These are defined at the right level and quality criteria, guidance on behaviours, risk and the frequency of releases, as well as guidance on quality checking techniques. The work package helps the DevOps team to understand the wider project context. Furthermore, the work package must be flexible to make management by exception easier and to enable rich communication (for example, using workshops, face-to-face meetings, and visualizations).

The project manager builds a high-level project plan (roadmap) around features. If some or all of these features have to be delivered by the DevOps team, these features have to be part of the work package (product descriptions).

The project manager must understand that the DevOps team has a responsibility to manage customer product demand. The DevOps team must also maintain the stability of the product, service, or solution in production, which includes changes and unplanned work or recovery work.

For the DevOps team, the demand from the project manager will be positioned as a business project (see section 3.3). The project manager must agree where on the DevOps team’s roadmap the project will fit and how much work they can handle in a given time period (the WIP limit). This means that the project manager must accept that the DevOps team will not be constantly available for the project manager and the agreed utilization will be part of the work package. If needed, timing conflicts can be escalated to the project board and/or portfolio committee.

To control a stage and more specifically the DevOps team’s work package, the project manager focuses on what is being delivered in terms of scope (the features and quality criteria) and they will monitor the risks. The features could be divided into user stories by a product owner or customer representative. The customer representative or product owner in the DevOps team can decide to change user stories if the feature itself will be delivered (in-line with the described tolerance levels in the work package). Where possible, this work package control will be a joint or collaborative empirical inspect and adapt exercise. For example, meetings, ceremonies or events between the project manager and the DevOps team, making use of information radiators, stand-up meetings, and demos.

6 How to cope with the PRINCE2 governance from a DevOps team perspectiveDevOps teams prefer to be led and coached as opposed to managed. They will not accept that a project manager assigns a team manager role to manage the DevOps team. Common agile guidance does not have a project manager role, but PRINCE2 sees this role as mandatory within a project. The DevOps team has to understand that the project contains more than the product, service, or solution the DevOps team is responsible for. The DevOps team must accept that a project manager will coordinate work between the DevOps team and other teams and stakeholders. To make this possible, the project manager needs a single point of contact.


The DevOps team members expect servant leadership and a good understanding of the overall project objectives from the project manager. The project manager is to be its servant. The focus of the project manager must be on empowerment (empower to self-organize), collaboration, and facilitation. Fortunately, there is nothing in PRINCE2 that limits the use of servant leadership.

The project manager must manage by exception with the emphasis on empowerment, the amount being delivered, rich information flows, and the value being delivered. This means the project manager will be pulling information from the information radiator (pull) rather than having it delivered by means of additional regular progress reports (push). The project manager trusts the DevOps team, focuses on collaborative working, and avoids a blame culture, to promote experimentation and a learning culture.

The information radiator shows the Kanban board, including the swimlane with the business project. This is also the place where the DevOps team members draw their burn-up and burn-down charts, visualizing the actual status of the business project’s progress. The project manager can use these graphs to understand if the DevOps team is on track, behind, or ahead of the agreed schedule.

The DevOps team8 expect that the project manager will use the feedback from testing, staging, and deployments from real customers to re-plan: “scope may need to be added and/or removed frequently based on the new information.9”

The DevOps team expects the project manager to finds ways to break a large project into smaller parts, which enable the business to gain incremental value (for example, based on prioritized business requirements and corresponding business value). If needed, the DevOps team can deliver features accompanied by feature flags, to launch a feature to a subset of users or postpone the go live stage to the right moment.

When talking about governance you must also think about risk management10. A popular risk management framework used when considering governance is The Three Lines of Defence Model 11 (developed by the Institute of Internal Auditors). The three lines of defence are:

z 1st Line: who owns the risk? The DevOps team members. z 2nd Line: who sets policy and monitors the risk? The senior supplier in the project board and risk functions that set policy and monitor risk daily. When the project is part of a programme, the 2nd line of defence is the programme board.

z 3rd Line: independent assurance. Internal audits that provide independent insurance and report directly to the audit committee or the board.

In addition to this enterprise risk management model is an informal 4th line that is external to the company, but works with them hand-in-hand to properly implement governance. It is the responsibility of the senior supplier in the project board to act as the intermediary.

z 4th Line: external partners. Auditors and regulators who must be brought into the conversation and given full transparency on development processes and risk management.

“The focus of the project manager must be on empowerment

(empower to self-organize),

collaboration, and facilitation.”


7 Blending PRINCE2 and DevOpsDevOps offers plenty of good working practices, but, it is not a silver bullet for business success12. Command-and-control leadership is not the way forward. Leaders are engaging more with their teams. Leadership is moving towards a facilitating, delegating, and long-term strategy-focused way of working. DevOps teams are not autonomous, they must know what is happening in the organization, and they must understand their part in the product lifecycle. Gartner released a Product Management Framework13, which lists 22 areas to reduce risk and maximize benefits. DevOps is only related to a few steps in the process, for example, in building compelling CX and accelerating time to market.

This means that the DevOps team needs to bridge the gap across various functions and groups in the organization. The project board members as described in PRINCE2 can help to overcome this gap. The project executive or project sponsor can help to align the DevOps team with the company’s strategy and ensure that the DevOps team is aware of strategic changes.

The senior user in the project board plays a very important role in the creation and maintenance of a solid product management strategy. For further information, see the product planning section of Gartner’s Product Management Framework.

The technology stack and how the product is organized in terms of components or microservices are key factors to drive the right team topology, DevOps efficiency, and deployment effectiveness. This is also one of the reasons that many organizations are moving away from big, monolithic applications. This is typically the area of focus for the senior supplier in the PRINCE2 project board.

The role of the project manager will change in comparison with a more traditional project manager. Behaviours, relationships, and responsibilities might be emphasized differently. The project manager needs to adopt a servant leadership approach to be seen as a friend of the DevOps team and not just a figure of authority. Within a DevOps team, there can be a level of coldness and technicality when working with this streamlined, analytical system of product development, bug fixes, QA testing and launch14. But it is the project manager’s job to add that human element that technology can sometimes miss.

8 SummaryPRINCE2 is already enabled to work with Agile and can be very effective in an agile context. Tailoring, as one of the seven principles, is about creating an appropriate blend of the two. The use of Agile is always a question of ‘how much can be used according to the situation?’

Like marriages, success cannot come from just one side. But if both parties, in this case a PRINCE2 project management team and DevOps team members, have the right (agile) mindset to work together to make this work, the results could be outstanding. DevOps should be blended with a proper PRINCE2 project management team structure with shared goals, the right leadership mindset, a comprehensive product management strategy, and an overarching application architecture to contribute to timely customer value generation. Finally, the project manager can provide the DevOps teams with a human goal.


9 About the authorHenny Portman is partner of HWP Consulting. He has 40 years of experience in project management. He was the thought leader within NN Group of the PMO domain and responsible for the introduction and application of the PMO methodologies (portfolio, programme, and project management) across Europe and Asia. He trains, coaches, and directs (senior) programme, project, and portfolio managers and project sponsors and has built several professional communities.

Henny Portman is accredited in a variety of qualifications, including: P3O, PRINCE2, MSP, MoP, PRINCE2 Agile, AgilePM, AgilePgM, and AgileSHIFT trainer and is also a SPC4 SAFe consultant and trainer. He is a P3M3 trainer and assessor and PMO Value Ring Certified Consultant (PMO Global Alliance). On behalf of IPMA, he assesses mega and large projects for the IPMA Project Excellence Award. In addition to this, he is an international speaker and author of many articles and books in the PM(O) field and a blogger at hennyportman.wordpress.com.


10 Endnotes1 Skrynnik, O., (2018). DevOps - A Business Perspective. Van Haren Publishing, s’-Hertogenbosch

2 Note that for those wishing to learn more about how to combine the governance structure and tailorability of the PRINCE2 method with the flexibility and responsiveness of agile ways of working, AXELOS has developed the supporting guidance and certfication PRINCE2 Agile (2015)

3 AXELOS (2017) Managing Successful Projects with PRINCE2. The Stationery Office (TSO), London

4 AXELOS (2015) PRINCE2 Agile. The Stationery Office (TSO), London

5 CAMS acronym was invented by Damon Edwards and John Willis, presenters of the famous Podcast DevOps Café (2010). Jez Humble added the L for Learning and Lean.

6 Gene Kim, Kevin Behr, George Spafford, (2013) The Phoenix Project. IT Revolution Press, Portland.

7 Introduction to DevOps for business managers (2020). Available at: https://www.cprime.com/ resources/blog/devops-methodology-business-analysts/ [Accessed 27 October 2020].

8 How to rethink project management for DevOps (2017). Available at: https://enterprisersproject. com/article/2017/10/how-rethink-project-management-devops [Accessed 27 October 2020].

9 ibid

10 Governance in a DevOps Environment (2018). Available at: https://medium.com/capital-one-tech/ devops-and-governance-56f6ecae1181 [Accessed 27 October 2020].

11 The three lines of defence (2015). Available at: https://www.iia.org.uk/policy-and-research/position- papers/the-three-lines-of-defence/ [Accessed 27 October 2020].

12 3 problems DevOps won’t fix (2020). Available at: https://enterprisersproject.com/article/2020/2/ devops-wont-fix-3-problems [Accessed 27 October 2020].

13 Gartner Priorities Navigator™ for Product Management Teams (2020). Available at: https://www. gartner.com/en/industries/high-tech/trends/product-management-framework [Accessed 12 October 2020].

14 Project Managers Role in a DevOps World (2020). Available at: https://www.techwalls.com/project- managers-role-devops-world/ [Accessed 27 October 2020].

15 Inside the Mind of Jeff Bezos (2004). Available at: https://www.fastcompany.com/50541/inside- mind-jeff-bezos-4 [Accessed 27 October 2020].


Further readingThe CAMS model to better understand the DevOps movement (2018). Available at: https://medium.com/@brunodelb/the-cams-model-to-better-understand-the-devops-movement-ffe6713c3fd7 [Accessed 26 October 2020].

ITIL® 4 and DevOps White Paper (2020). Available at: https://www.axelos.com/case-studies-and-white-papers/itil-4-and-devops-white-paper [Accessed 27 October 2020].

ITIL 4 and DevOps: a cultural perspective Discussion Paper (2019). Available at: https://www.axelos.com/case-studies-and-white-papers/itil-4-and-devops-a-cultural-perspective [Accessed 27 October 2020].

11 About AXELOSAXELOS is a joint venture company co-owned by the UK Government’s Cabinet Office and Capita plc.

It is responsible for developing, enhancing and promoting a number of best practice methodologies used globally by professionals working primarily in project, programme and portfolio management, IT service management and cyber resilience.

The methodologies, including ITIL®, PRINCE2®, PRINCE2 Agile®, MSP®, RESILIA® and its newest addition AgileSHIFT® are adopted in more than 150 countries to improve employees’ skills, knowledge and competence in order to make both individuals and organizations work more effectively.

In addition to globally recognized qualifications, AXELOS equips professionals with a wide range of content, templates and toolkits through the CPD aligned My AXELOS and our online community of practitioners and experts.

Visit www.AXELOS.com for the latest news about how AXELOS is ‘Making organizations more effective’ and registration details to join AXELOS’ online community. If you have specific queries, requests or would like to be added to the AXELOS mailing list please contact [email protected].

12 Trade marks and statementsAXELOS®, the AXELOS swirl logo®, ITIL®, PRINCE2®, PRINCE2 Agile®, MSP®, AgileSHIFT®, M_o_R®, P3M3®, P3O®, MoP®, MoV®, RESILIA® are registered trade marks of AXELOS Limited. All rights reserved.

Copyright © AXELOS Limited 2019.

Image credits: Front cover ©/Getty/Tara Moore

Figure 2.1, 2.2 ©/AXELOS Ltd

Reuse of any content in this White Paper is permitted solely in accordance with the permission terms at https://www.axelos.com/policies/legal/permitted-use-of-white-papers-and-case-studies

A copy of these terms can be provided on application to AXELOS at [email protected]

Our White Paper series should not be taken as constituting advice of any sort and no liability is accepted for any loss resulting from or use of or reliance on its content. While every effort is made to ensure the accuracy and reliability of information, AXELOS cannot accept responsibility for errors, omissions or inaccuracies. Content, diagrams, logos and jackets are correct at time of going to press but may be subject to change without notice.

Sourced and published on www.AXELOS.com


@AXELOS_GBPWWW.AXELOS.COM AXELOSAXELOS Global Best Practice

and DevOps, a successful marriage or recipe for...EO.CO PRINCE2® and DevOps, a successful marriage...

Documents

Transcript of and DevOps, a successful marriage or recipe for...EO.CO PRINCE2® and DevOps, a successful marriage...