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

Happy to see that my white paper PRINCE2 and DevOps, a successful marriage or recipe for divorce? is now live on the AXELOS content hub.

More and more organizations are incorporating DevOps into their working practices to get more done. Many organizations will also use PRINCE2 to deliver projects. But can an organization really use these two approaches together? This paper will show that an organization does not need to pick and choose which approach it will take; PRINCE2 and DevOps can be used together and even share some similarities.

This paper will examine DevOps and the PRINCE2 governance structure separately and will compare a temporary PRINCE delivery team with a permanent DevOps team. I describe how a PRINCE2 project manager can cope with DevOps teams and how DevOps teams can cope with the PRINCE2 governance. The paper will combine both approaches to explore how they can be successfully implemented together.

I hope this white paper will be useful and feel free to give me your comments.

Review: DevOps for the modern enterprise

DevOps for the modern enterprise – winning practices to transform legacy IT organizations is a practical book based on the experience of the author Mirco Hering.

The book is divided into three parts. The first part explains how to create the right ecosystem for success. The second part puts the people and organizational dimension in the spotlights and the last part emphasizes on technology and architecture aspects. Every part contains four chapters and at the end of each chapter you get some steps to exercise to make it more practical.

The first part – creating the right ecosystem – starts with the usage of value stream maps to visualize your IT delivery process and a jump-start of the transformation with an initial roadmap and governance approach. As a next step you have to analyze your application portfolio (criticality of application, level of investment in application, preferred frequency of change, technology stack). Based on this analysis you should focus on a minimum valuable cluster (MVC) to speed up the complete cluster by uplifting the MVC. The following chapter discusses the added value of guidelines for selecting new applications and the strengthening of your architecture by creating and empowering ecosystem. The following aspects can be used to start the assessment of architecture maturity: auto scaling, self-healing, monitoring and capability for change. When looking at your packages, in case you can’t or don’t want to replace, the following approaches are explained: leverage your system integrator, leverage user groups, strangle the application and/or incentivize the vendor to improve their product. In line with the types of applications (differentiator applications, workhorses and true legacy) you have to find the right partner that fits your ambition and culture.

As stated, the second part put the people central. How can you provide your people with the right context for their decisions, what team structure you should choose to enable autonomy and purpose, how to shift from legacy thinking that has caused many test automations projects to fail, and how to manage your people better? Based on the “burger organizational chart” the author discusses delivery governance (with an agile governance function, DevOps governance function and quality assurance),  the test automation center of excellence, agile teams (maybe clustered in an agile release train, team by location, team by function and team by technology) and the platform team (test automation, automated app release and environment provisioning). A separate chapter is dedicated to testers and the importance of quality. The last part gives more generic people-oriented techniques and ways of working like one-on-ones, feedback, delegation, creating a blameless culture and measuring your organizational culture.

The last part looks at the right way to choose DevOps tooling, what makes a good DevOps architecture, how to evolve your application architecture, how to leverage the relationship between DevOps and cloud computing, what each delivery model looks like, and how these models impact your organization.

The delivery models are:

• Continuous delivery model deploys applications automatically into persistent environments (either cloud or on premises)
• Cloud-enabled delivery model deploys applications automatically after provisioning a new environment from the cloud or data center. Main difference compared to continuous delivery model is the maturing of the infrastructure practices – infrastructure as a code.
• Container-enabled delivery model deploys applications as a set of containers into one or more hosts that are dynamically created. Main difference compared to cloud-enabled delivery model is the maturity of the container practices and the more modular application architecture.
• Serverless delivery model (potential future model) where you don’t run services as such but rather write a function to perform some business logic. When the function is called, an instance is created just for the duration of the function call (e.g. Amazon Lambda).

To evolve your architecture over time you can use the strategies decoupling (two speed delivery model), going on a diet (paying down the technical debt and making the core more agile), let’s try it on the side (green field setting) and erode the core with microservices (a service that serves one purpose; it is self-contained and independent; it has a clearly defined interface and isolated persistence). The book ends with different aspects of levering cloud-based services. Benefits of the cloud are cost benefits, ease of setting up redundancy for resilience, the scalability of resources, and the strong ecosystem of related services that you would otherwise have to build yourself. on the risk side we see the dependency on a third-party provider, the challenges with data sovereignty, and the risk of being attacked because you are on a popular platform.

Conclusion. Reading this book and execute one or more of the exercises gives you one of the reasons why so many agile transitions fail. It’s not only about creating, sometimes only renaming teams into agile teams but you have to look at the complete ecosystem, your application landscape, the application architecture and your delivery models. A must read for those who are transforming their IT organization towards a more agile organization.

To order: DevOps for the modern enterprise

 

Recensie DevOps …… in beweging

Jan Heunks heeft met het boek DevOps …… in beweging – De handvatten voor een optimale DevOps toepassing (2019) een lijvig boekwerk opgeleverd.

Het boek bestaat uit drie delen:

In deel 1 komt de toegevoegde waarde van DevOps aan de orde en geeft een eerste introductie op DevOps aan de hand van Continuous Delivery en de agile-, ITSM- en Lean IT-werkwijzen. Daarnaast wordt DevOps in relatie tot de waardeketen en de demand-supply-structuur uitgewerkt. Dit deel wordt afgesloten met een stukje historie (met in de bijlage een tijdslijn van DevOps-ontwikkelingen).

Het tweede deel is een theoretische verdieping op een aantal DevOps-kaders en gaat specifiek in op de belangrijkste bewegingen die gelden voor DevOps, zijnde de Lean IT-, Agile- en ITSM-beweging. Binnen Lean-IT komen begrippen zoals her House of lean, Toyota Production System, lean thinking, Continuous Improvement, Kaizen en respect for people aan bod. Bij de Agile-beweging vinden we agile-basis, Scrum, het Agile Manifesto, agile-essenties en agility. Bij ITSM krijgen we een samenvatting van het boek Visible Ops, ITIL en agile binnen IT. Ook DevOps als beweging wordt nader toegelicht. Doorstroming, feedback en continu leren en experimenteren, DevOps-principes en een paradigma-shift staan centraal.

Het derde deel moet inzicht leveren wat het betekent om DevOps in te voeren in een organisatie. Eerst worden bestaande principes, werkwijzen en toepassingen en in het bijzonder het leveren van IT-services, het leveren van nieuwe functionaliteiten en het adviseren over IT-services, van organisaties zonder DevOps besproken. Vervolgens wordt DevOps afgezet tegen de ‘primaire’ ITSM-processen, softwareontwikkeling en projectmanagement. Vervolgens wordt ingegaan op de aanpak waarmee DevOps geïntegreerd kan worden in een bestaande organisatiestructuur en hoe operational excellence bereikt kan worden middels optimale samenwerking binnen cross-functionele teams. Aan de hand van een zestal anti-typen en negen bruikbare typologieën van DevOps teamstructuren krijgt men een goed inzicht in mogelijke verschijningsvormen. Het deel wordt afgesloten met een hoofdstuk over DevOps volwassenheid.

Conclusie: Heel, heel veel theorieën, aanpakken, invalshoeken, feiten en inzichten rond het begrip DevOps. Ik geloof er echter niet in dat dit boek nu al bruikbaar is om te gebruiken als handvat bij je eigen DevOps-reis. Waarom zeg ik dat? Het boek is m.i. nog niet af. Ik denk dat dit boek een voorbeeld is van een boek dat in eigen beheer is uitgegeven (ik kon geen andere boeken vinden van de uitgever). Een redacteur had m.i. wonderen kunnen verrichten en de kwaliteit van dit boek enorm kunnen verhogen.

Persoonlijk had ik moeite met de vele lange ingewikkelde zinnen (ik heb zinnen gelezen met meer dan 63 woorden). Daarbij had ik regelmatig het idee dat het ‘Google Translate’-zinnen waren en ik mij afvroeg wat staat er nu? Storend vond ik de vele, overvloedige Engelse vertalingen die tussen haakjes stonden en die soms weer vragen opriepen (bv. output en outcome zijn bekende begrippen in de project- en programmawereld en worden hier gebruikt als vertalingen voor korte en lange termijn) of andersom kwam het geforceerd gebruik van het Nederlands de leesbaarheid ook niet ten goede. Bijvoorbeeld dubbelslagleren en dan tussen haakjes (double loop learning).

Verschillende figuren worden niet toegelicht of de verwijzing in de tekst naar de figuur ontbreekt. Ook had ik het op prijs gesteld dat een paginagroot figuur over het Phoenix project voorzien was van een verwijzing naar mijn eigen blog waarvoor ik die figuur gemaakt had, maar dat terzijde. Mijn belangrijkste bezwaar is verder de opbouw van het boek. Ik was regelmatig de draad kwijt. Bij verschillende hoofdstukken en/of paragrafen vroeg ik mij af waarom staat dit stuk hier of is dit stuk niet veel te diepgaand. Daarnaast had ik in het derde deel graag concrete aanbevelingen gezien. Nu krijg je wel een toelichting op een aspect bijvoorbeeld Bimodal IT of Brownfield & Greenfield, maar wat dit nu betekent als je DevOps gaat implementeren ontbreekt.

Bestellen: DevOps …… in beweging

Reactie Jan Heunks:

“Met de recensie op het boek ben ik zeker niet ontevreden. De samenvatting die de recensent van de drie boekdelen geeft is een prima weergave, zeker in relatie tot de boekparagrafen ‘woord vooraf’ en ‘om te beginnen’. In deze paragrafen wordt aangegeven dat de DevOps-context erg breed is en het antwoord wat DevOps feitelijk is, niet eenduidig is te beantwoorden en van veel factoren afhankelijk is.

Het zonder eindredactie en het in eigen beheer uitbrengen van een boek is een soort van avontuur en een keus, waarbij input leveren aan de snelgroeiende DevOps-community het uitgangspunt is geweest. De DevOps-reis is in ieder geval sterk afhankelijk van de volwassenheid van een organisatie, nog los van de verschillende soorten organisaties. Als concrete aanbeveling voor een DevOps-reis, iets waar de recensent mogelijk naar op zoek is, verwijs ik graag naar de roadmap-beschrijving (als ‘raamwerk’ en als ‘bestemmingsplan’) in het boek ‘Lean IT – de theorie en praktijk van Lean in een IT-omgeving’. Deze beschrijving is ook zeer behulpzaam bij een DevOps-transformatie.

Al bij al, DevOps is in beweging en iets dat in beweging is, ontwikkelt zich verder op basis van feedback en voortschrijdend inzicht.

Ik beschouw het als een compliment dat de recensie verwijst naar de grote hoeveelheid theorieën, aanpakken, invalshoeken, feiten en inzichten. Want, waar vind je een dergelijke uitgebreide beschrijving, samenhang en inzicht? De vakgenoten/reviewers die hebben bijgedragen aan het tot stand komen van het boek geven dit als volgt aan: er wordt in detail ingegaan op alle zaken die van invloed zijn voor de vorming van DevOps, het geeft overzicht in de DevOps-aspecten en de relatie met andere bewegingen, complexe materie wordt toegankelijk gemaakt, DevOps wordt tastbaar gemaakt met veel handreikingen, volledig en goed beschreven.

Dat sommige onderwerpen (te) diepgaand zijn beschreven en de plaats soms onlogisch lijkt, is herkenbaar. Dit is in het boek ook expliciet toegelicht, als volgt: sommige onderwerpen worden op meerdere plaatsen (in meer of mindere mate) beschreven of herhaald, binnen de dan geldende context; als een verdere verdieping of toelichting.

De aspecten Bimodal IT en Brownfield & Greenfield zijn in het boek toegelicht in het kader van tegenstellingen. De betreffende paragraaf wordt met een belangrijke conclusie afgesloten, die de recensent mogelijk over het hoofd heeft gezien: een kritieke succesfactor, in het kader van DevOps, is het niet vergeten van de menselijke factor omdat het onverstandig is medewerkers met beide tegengestelde werkvormen te laten werken. Dit kan als aanbeveling worden beschouwd, maar dat terzijde. Er worden overigens veel meer van dit soort aanbevelingen (cq succesfactoren) beschreven met de bedoeling dit als overweging mee te nemen in de DevOps-reis. Een lezersreactie: veel nuttige tips en aanbevelingen, dank hiervoor.

De termen output en outcome worden niet ‘vertaald’ in hetgeen de recensent aangeeft, maar worden in een context geplaatst als korte en lange termijn resultaat, oftewel het projectresultaat als output (een korte termijn resultaat) en de te behalen gewenste bedrijfsresultaten, als eindresultaat/outcome (het lange termijn resultaat).

Dat het boek niet bruikbaar is als handvat voor de eigen DevOps-reis beschouw ik als een mening van de recensent. Dat mag, echter verwacht geen concreet stappenplan of een kookboek-achtige beschrijving want die is er niet. Er zijn namelijk erg veel factoren die een succesvolle invoering van DevOps bepalen en even zoveel factoren om in overweging te nemen. Overigens begrijp ik de stellingname van de recensent maar al te goed. Echter, het doel van het boek is de lezer te helpen met het creëren van inzicht in de vele factoren die in meer of mindere mate van invloed zijn bij het behalen van succes met de DevOps-aanpak. Verder beoogt het boek om organisaties, die met de vraag worstelen op welke wijze een begin kan worden gemaakt met de invoering van DevOps, aanknopingspunten te geven waar rekening mee te houden. Twee concrete handvatten zijn blijkbaar door de recensent niet herkend: de DevOps business case en het DevOps Manifesto.

De recensent verwacht concrete aanbevelingen, met name in deel 3. Er zijn op veel plaatsen impliciet en expliciet DevOps-succesfactoren vermeld. De rode draad is dat het succes van DevOps voor een groot deel afhankelijk is van menselijke factoren, een omslag in cultuur en het begrijpen van principes. Ter ondersteuning is de inzet van bepaalde tools en technieken een prima overweging. Dit analoog aan het Shingo-model waaraan een aantal concrete leidende principes zijn verbonden. Dit is ook terug te vinden in het boek.

Een aantal waardevolle opmerkingen van de recensent, die zeker ter harte worden genomen, betreft het geforceerd gebruik van het Nederlands, de vele, overvloedige Engelse vertalingen die tussen haakjes staan en de lange ingewikkelde zinnen. Dit laatste is, ondanks de nodige aandacht die hieraan is besteed, bij een aantal zinnen blijkbaar over het hoofd gezien.”

 

Review: DevOps a business perspective

Oleg Skrynnik wrote the book DevOps a business perspective. It’s the core literature for the EXIN DevOps Foundation certification and gives a good overview of DevOps.

Definition 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”

The book is built around 6 chapters. The first chapter explains DevOps in general. Next, we get key facts and challenges of lean production and agile as the foundation for DevOps. Followed by an explanation of the five DevOps principles.in a next chapter DevOps is compared with traditional practices and 10 DevOps practices are explained and ends with the practical application of DevOps.

The evolution of Agile software development methods created the need for a new approach to IT management. Management of IT infrastructure as a code enabled by virtualization and cloud computing provided the opportunity for the same new approach to IT management. This new approach was the inspired emergence of DevOps.

Why DevOps:

• reduce time to market (business idea testing, hypothesis evaluation)
• Reduce technical debt (the debt occurs when a programmer chooses a non-optimal way to solve a problem in order to shorten the development time)
• Eliminate fragility (fragile systems first and foremost need stability, they need to be changed as little as possible, and changes should be carefully checked both before and after the intervention)

DevOps is based on five principles:

• Value stream. Creating value in response to a customer’s request
• Deployment pipeline. The most automated transition of changes through all steps of the value stream, starting from the Development is complete’ point, down to ‘Deployment into operations’ (including continuous integration, delivery and deployment)
• Everything should be stored in a version control system: source code, tests, scripts, artifacts, libraries, documentation, configuration files, development tools
• Automated configuration management. Any changes to any environment can be made only by scripts stored in a version control system
• The Definition of Done. Creation of new functionality is done only when the application is running in the production environment and all the assembly, testing and deployment activities are done automatically.

Ten DevOps key practices:

• Unusual teams: not a temporary construct, responsible for a small domain, full time, cross-functional, small, versatile professionals, self-organizing, collocated, responsible for the tool in use
• Work visualization: helps to build a pull system, improves visibility of tasks in progress, remaining amount of work, prioritization, reduces the number of hand-offs and helps to identify inefficiencies
• Limit the WIP: helps to build a pull system, improves estimating of the lead time, identification, visibility, evaluation and elimination of constraints, decreases specialists’ work interruptions and work re-scheduling
• Reduce batch size: reduces total amount of work, lead time and number of defects, and improves the rhythm of the flow, the quality of the products
• Mind the operational requirements: the product owner as interested in the fully operational IT system, including both functional and other (or operational) requirements
• Early detection and correction of defects: testers develop tests and the test environments correspondent to the production environment as accurately as possible to support fast detection of defects
• Managed, not controlled improvements and innovations: banning any normal work during the time allocated for improvement, Kaizen Blitz (with a very definite and tangible result), hackathons
• Funding that enables innovations: funding of products rather than projects would be more appropriate, and this means a completely different way of budgeting and resource planning
• Task prioritization based on cost of delay divided by duration
• Continual identification, exploitation and elevation of constraints

The last chapter describes some practical applicability and limitations of DevOps, consequences when using COTS (Commercial Off-The-Shelf), an evolving architecture towards a microservice architecture, DevOps and ITSM, Cargo Cutting (thoughtless copying), start where you are, progress iteratively and use a value stream as the core for DevOps.

Conclusion: If you want to understand what DevOps really means, this is a good book to start your journey and bring it into practice.

To order: DevOps a business perspective

Book review: The DevOps Handbook

Gene Kim, Jez Humble, Patrick Debois and John Willis are the authors of the book The DevOps Handbook. how to create world-class agility, reliability, & security in technology organizations. If you look at the cover you see some similarities with The Phoenix Project. A novel about IT, DevOps, and helping your business win. And that is not a coincidence because Gene Kim is one of the co-authors of this book too.

Where The Phoenix Project is a business novel explaining the journey to set up a DevOps team, this book gives you the theoretical background, and the tools to build and use the DevOps philosophy by integrating product management, development, QA, IT operations, and information security to elevate your company.

The book is divided into four blocks: The first block (part I) introduces the three ways: The principles of flow, feedback and continual learning and experimentation. The second block (part II) explains where to start a DevOps movement in your organization. The third block (parts III-V) describes the technical practices of the three ways. The last block (part VI) discusses the technological practices of integrating information security, change management, and compliance.

In part II we see what it means to select the value streams with the most sympathetic and innovative groups to start with the DevOps transformation, analyse those value streams by creating a value stream map, and design the organization (functional, matrix or market oriented), fund services and products and not projects and create loosely-coupled architecture to dramatically improve the outcomes.

The first way describes the architecture and principles that enable the fast flow of work from left to right, from Dev to Ops to deliver quickly and safely, value to customers. Start with a single repository of truth for the entire system, make infrastructure easier to rebuild than to repair, enable fast and reliable continuous integration and automated testing and start with low-risk releases. Include running in production-like environments in your DoD.

The second way addresses the reciprocal fast and constant feedback from right to left by implementing feedback loops and use shared goals spanning Dev and Ops to improve the health of the entire value stream. The authors provide insights in telemetry from processes, behaviour and production issues, audit issues and security breaches that enables seeing and solving problems. Next we see, how we can integrate user research and feedback, peer reviews and pair programming and what it means when integrating hypothesis-driven development and A/B testing into our daily work?

The third way helps to create a culture of learning and experimentation. What can you learn from incidents, and how others can learn from your own learning by creating repositories and sharing learnings. How can you enable and inject learning into daily work by establishing a learning culture, have post-mortem meetings after accidents occur and communicate them, decreasing incident tolerances and organize game days to rehearse failures? And make sure you capture organizational knowledge by using e.g. chat rooms and chat bots.

In the last part, the three ways are extended by using them to achieve information security goals by making security a part of everyone’s job, by integrating preventive controls into a repository, by integrating security with the deployment pipeline, and integrating deployment activities with the change approval processes and reducing reliance on separating of duty.

Conclusion

If you want to start a DevOps movement, start with The Phoenix Project to make yourself enthusiastic about DevOps and continue with this book to get the real technical practices to make your DevOps a success. When buying this book, you will get a unique one-time access code to the DevOps X-ray individual assessment to benchmark your own performance against industry-wide data.

To buy: The DevOps Handbook

Book review: The Phoenix Project. A novel about IT, DevOps, and helping your business win

The book The Phoenix Project. A novel about IT, DevOps, and helping your business win written by Gene Kim, Kevin Behr, and George Spafford gives you great insights how to improve the success rate of your IT organization by transforming your organisation in a DevOps like organisation to deliver much faster (more than 10 deployments a day), still staying compliant and with less errors, the features your customers are asking for.

This heavy book, more than 380 pages is written in an entertaining, page-turning style. If you work in IT, you will definitely recognize many situations but also the typical characters in this novel.  It’s written in the same style as Dr. Eliyahu Goldratt’s book The Goal. Which was, as the authors mentioned one of their inspiration sources.

In the book we follow Bill who is an IT manager at Parts Unlimitted. Bill is asked to fix the mess of the Phoenix Project which is massively over budget and very late and will report directly tot he CEO. I fit can’t be fixed within ninety days Bill’s entire department will be outsourced.

Bill will get help from Erik, a prospective board member who teaches Bill that IT work has a lot in common with manufacturing plant work. Erik takes Bill several times to a manufacturing plant to show what he means.

We follow Bill and his team taking the five steps of the Theory of Constraints as described in The Goal.:

• Identify the constraint
• Exploit the constraint
• Subordinate all the other activities to the constraint
• Elevate the constraint to new level
• Find the next constraint

In this story it becomes clear that a developer Brent is the constraint. He is needed for every small or big change and the team puts all kind of measures in please like putting a Kanban board around his activities, prioritizing the work, reducing his workload et cetera.

During the journey we see Development, Quality Assurance, Compliancy, Operations working more and more together and becoming what we would call a DevOps organization.

Step be step Bill starts to understand that he has to create and integrate three ways of working:

• The first way is a left-to-right flow of work from Development to IT Operations to the customer. This flow needs to maximize by managing the Work In Progress (WIP) and have continuous build, integration, and deployment practices.
• The second way is about the constant flow of fast feedback from right-to-left at all stages of the value stream.
• The third way is about creating a culture that fosters two things: continual experimentation, which requires taking risks and learning from success and failure and understanding that repetition and practice is the prerequisite to mastery.

To understand the flow with the IT value stream Bill had to find out that there are four types of work: Business projects, Internal IT projects, Changes and Unplanned work or recovery work. See attached figure.

Following Bill we get, on one hand, a great story about his struggle to drastically improve the way the work within Parts Unlimitted and you, as reader, wants to know how he succeeds and on the other hand we get fantastic insight in the world of DevOps.

The final forty pages is called The Phoenix Project Resources Guide. Why do you want to implement DevOps and where DevOps came from? Explaining the three ways and the four types of work as well as a demystification of some of the top DevOps myths. The last chapter is a list of recommended reading and further resources to learn more about DevOps philosophies, tools, and techniques that were used in the book.

I would say a must for those who are entering the world of DevOps.