News

Formula 1 (F1 for short) is and has been a favourite sport of mine since I was a kid. Extreme commitment, phenomenal engineering and precision skills are just a few of the attributes necessary to compete and succeed. I’ve been meaning to write this article for some time, having long observed some fundamental principles of Agile working in the world of F1, leading me to believe there is no better example of organizational agility in sport. The unprecedented situation we currently find ourselves in – and furlough leave for me personally – has presented the opportunity for a brain dump! Before I get into the detail, let me first clarify my position. A disclaimer if you like! I am not an Agile practitioner per se (i.e. Developer, Business Analyst, Project Manager), however, my current role involves the promotion of Agile Project Management guidance and supporting certifications, and I feel I have a decent understanding of the core principles of Agile working and development. In short, I’m not professing to be an Agile expert in any way, shape or form. But based on my understanding of the core principles, I see some striking similarities between the world of F1 and the Agile way of working. Additionally, I am assuming that readers have a prior understanding of the core principles of organizational agility.  

F1 for the uninitiated

Not everyone that reads this will be a Formula 1 fan, so I should start by setting the scene a little. Formula 1 is the pinnacle of global motorsport consisting of 10 teams (constructors), each with two drivers. Often billed as the world’s most extravagant travelling circus, the competition sees teams travel the globe racing in over 20 different countries, each contributing to the sport’s two major crowns: The Constructors (for the teams) and Drivers World Championships. Teams spend millions every season designing and building their cars, and continually seeking performance gains over the course of the season. In most walks of life a few tenths of a second sounds quite insignificant, but in the world of motorsport – in terms of a deficit to your competitors – it's a significant gap to bridge. A two-tenths deficit could be the difference in qualifying five or six places down the grid, rather than on pole position.  

What makes F1 so Agile?

An F1 season is a development race, driving the necessity for constant adaptation and evolution to enhance competitiveness. During pre-season, teams develop their latest challengers through extensive design and simulation, supported by limited on-track testing. Teams arrive at the first race of the season with the fruits of their pre-season development work. But this is far from the finished product. F1 cars are constant prototypes; throughout the season cars continually evolve through mechanical and aerodynamic modifications. In this article I am focusing on three core Agile principles – the minimum viable product, user testing and iterative development – and how I see them in the world of F1.  

The car at the first race: the Minimum Viable Product (MVP)

Unfortunately, it’s not a simple case of paying your entry fees and bringing along your glorified soapbox to the starting grid. There are detailed regulations covering all aspects of F1 car design & development, from the power unit that drives the wheels to the complex aerodynamics and suspension setups that determine a car’s fundamental performance. Additionally, the rules effectively require you to be competitive. For a team and driver to take their place on the starting grid for each race, the rules stipulate you must post a qualifying time that is within 107% of the pole position time. So, come qualifying for the season opener if you have a car that.… Adheres to the sport’s technical regulations; and Is competitive (i.e. can achieve a lap time within 107% of the pole position time) .…then you have your minimum viable product for going F1 racing. But that is just the start; never in the history of the sport has a team arrived at testing or the first race with the perfect car for all rounds of the ensuing championship. Teams know that this initial concept is simply the basis for ongoing development and fine-tuning.  

The Driver: user testing

Modern F1 is data-driven. An incredible array of sensors blankets the modern F1 car, measuring everything from the tyre and brake temperatures, to suspension, aerodynamic and engine performance. This array of sensors enables teams to gather huge amounts of data over the course of a race weekend (well over 3 terabytes in fact!), revealing various aspects of car performance and highlighting potential areas for improvement. But there is one more, somewhat larger ‘sensor’ that offers tremendous additional feedback on performance – the driver. The driver is comparable to the user of the software or a product delivered by an Agile project or development team. And as any Agilist knows, user testing and feedback are vital. It is no different in F1. Whilst the teams benefit from huge amounts of data via the sensors outlined above, it still all comes down to the driver. If all the data suggests you have the perfect car, but the driver is unable to extract the perceived performance, you have a big problem. While sensors are great, they are no substitute for the feelings a human being experiences during mind-bending cornering speeds and travelling over 200mph a matter of centimetres above the ground. The driver (user) and his/her feedback are therefore crucial for developing and upgrading the car, just as user feedback is critical in helping a development team design a new software package.  

Constant evolution and iterative development

Just as fast and furious as the battle on track, the race to bring car updates and out-develop rivals across the course of the season is often where championships are won and lost. There’s a romantic desire amongst us enthusiasts to see championships won purely on the skill of the drivers or the brilliance of the initial technical concept, but the reality of F1 is that success requires a third element: the speed at which the team can develop through the season and continually reinvent their car. Engineers are constantly searching for improvements to gain those vital milliseconds and improve other key areas of performance such as stability and reliability. Seldom will a car be the same from one race to another. With (currently) 21 races over the course of an 8-9-month season, there is a phenomenal amount of iterative development going on in the background. Each and every lap over the course of a race weekend (three practice sessions, qualifying and the race) provides the data that teams and their engineers use to fine-tune setup and components of the car, generating a constant stream of upgrades. Evolution and development are constant. If they are not, you simply will not succeed in F1.  

The need to adapt, and fast

One of the fundamental challenges of all racing is that no two racetracks are the same. Similar, perhaps, but definitely not the same. These differences can fundamentally affect a car’s performance and lap time compared to its competitors. Consider the Monza circuit in Italy, dominated by long straights with a limited number of corners, versus the tight, twisty & bumpy confines of the Monaco street circuit. Each requires a fundamentally different setup for the car from engine mapping to aerodynamics. Even the nature of the track’s asphalt surface will impact on car performance, particularly how it looks after its tyres; crucial to race-long performance. Of course, there is another major factor at play – the weather! Cars perform and behave very differently based on the track and climatic conditions (e.g. hot/cold track surface, wet/dry track, wind speed, etc). The varying nature of the specific challenges of each race weekend throughout the season demands a level of adaptability more, arguably than any other sport. F1 teams know this and embrace it.  

Summary

Formula 1 teams and their operations have evolved significantly over the years to become highly efficient and adaptive, enabling rapid development and constant evolution of their cars and performance. There is much for organizations, leaders and teams to learn from agility in F1 and I would encourage a review of the articles below for more. Agile principles are no doubt prominent in many other sports, but I personally struggle to think of another that demonstrates Agile working principles at such scale. I have only explored a few of the fundamental Agile principles here too. No doubt I could have gone much further with planning, sprints, backlogs, etc. Maybe for a follow-up article! Original article published in May 2020 and reproduced with kind permission of Mark Constable, APMG International.     

Mark Constable

Mark is a Marketing Manager at APMG International and works closely with the Agile Business Consortium on the promotion of Agile guidance, training and certification for project, programme, business analysis and Scrum professionals. Mark Constable on LinkedIn  

One thing you cannot deny in business is change. Change is not always negative or positive, however it is always different. Change is omnipresent - whether driven by technology or economic or other factors; the indisputable fact is you are asking people to change. Change is present in any organisation at any size. Some organisations, especially the bigger ones, have specific departments that focus on change. However, that does not mean that change does not happen in smaller organisations, it might just not be recognized as ‘change’. Change is becoming more and more important and will be so in the future too. Organisations in any kind of field are experiencing changes under the current digital revolutions. Whether it is the digitization of documents, automation of processes or machine learning, change is everywhere and constant. To be able to guide this change, organisations need to recognize it and embed change within their organisations. Their staff will have to get used to a different way of work, change their mindset and change their habits and behaviour. With this outset, the Change Management skills people and organisations are going to need are only becoming more important as technology moves on.  

Key Skills to Prepare for the Coming Years 

You can divide skills into five different types namely:

1. physical & manual skills,
2. basic cognitive skills,
3. higher cognitive skills,
4. social and emotional skills
5. technological skills.

In the coming decade, we can expect a net loss on physical & manual skills and basic cognitive skills. There shall be again in higher cognitive skills, social and emotional skills and technological skills.   Within these three skill types that are expected to grow over the coming years are many diverse skills. The ones that fall under higher cognitive skills for example are:

• Project management
• Creative thinking and decision making
• Complex information processing and interpretation

  Skills that fall under social and emotional skills for example are:

• Advanced communication and negotiation
• Leadership and managing others
• Adaptability and continuous learning

  Skills that fall under technological skills for example are:

• Advanced IT skills and programming
• Advanced data analysis and mathematical skills
• Scientific research and development

 

Key Change Management Skills

Change is increasing and organisations can no longer ignore it. To help embed this change within the organisation, an organisation can benefit from Change Management. Change Management includes a very rich skillset. A skill set that helps to increase people engagement and includes many different soft skills. The key Change Management skills are very diverse and most of them fall under the type ‘social and emotional skills’. For example, while preparing your staff in a different way of work, you need great interpersonal skills, but also a great deal of empathy. To get people to change the work they have been doing for years is not as easy as it sounds and it is important to listen to their worries and needs. Connected with this are both advanced communication and negotiation skills and teaching and training skills. Entrepreneurship and initiative-taking are also skills that are needed within the Change Management department, together with creativity. This will help find solutions and adapt when sudden changes do arise. Adaptability and continuous learning will help the whole organisation to learn from ongoing changes, but also from past changes (both failed and successful). Leadership and management skills will help manage the people and the organisation and provide direction.  

The Change Journey 

Change is not something that will happen overnight and needs a vision of where the organisation wants to go. However, it is important to not only focus on this vision but also to see the journey. Change comes in little steps and if you recognize these little steps and share them with the people, you will create the needed engagement. This is another Change Management skill, to manage and control the transitional phase. Communication, problem-solving and influencing are all part of this. Change is about people and they need to be ready for change. It is important not to introduce too much change at once and the change needs to be delivered in phases. To do this, there needs to be input from the senior management and if possible, can be connected to existing Portfolio Management.  

Change Management Certification

Do you think your organisation can benefit from a solid change approach? Our Change Management course is designed to help organizations and their people manage the impact of change and provide techniques to effectively plan and implement successful transformation initiatives. Our course explores how change affects and is affected by, individuals, teams, organizations and change leaders, equipping individuals with the knowledge, theories and techniques to:

• Unlock resistance to change
• Provide effective support and motivation to individuals and teams to embrace change
• Draw from a range of professional approaches to implement change smoothly and effectively
• Manage and inform key stakeholders throughout the change process
• Speed up the implementation of change initiatives

  Source: APMG

A Team Leader is a specific term used in the AgilePM methodology while a Team Manager is a term used in the PRINCE2 methodology. Both organize the production in a constantly changing context while ensuring the team cohesion. They provide direction, instruction and advice to a group of people, also known as a team, in order to achieve a certain goal. An effective Team leader/manager will know the strengths, weaknesses and motivations of all of his/her team members.  

Team Manager Role in a PRINCE2 Project

Team Manager is the person responsible for production. This within the limits that are set by the project board, regarding quality, timescale and costs. The Team Manager is allocated by the Project Manager and this is defined in the work package. The Team Manager role reports to and takes direction from, the Project Manager. If a Team Manager is not assigned, the Project Manager will undertake the responsibilities of the Team Manager role.  

Team Leader Role in an AgilePM Project

Team Leader ideally acts as the servant-leader for the Solution Development Team. It ensures that the team functions as a whole and meets its objectives. Team Leader works with the team to plan and coordinate all aspects of product delivery at a detailed level. This is a leadership role rather than a management role. The person holding it will ideally be elected by his or her peers as the best person to lead them through a particular stage of the project. It is therefore likely that the Team Leader will also perform another development team role, in addition to their team leadership responsibilities.  

Team Leader and the Team Manager Responsibilities

 

Team Leader and the Team Manager Competences

The Team Leader Manager must have:

• significant managerial / leadership and organizational skills
• a developed sense of teamwork
• great technical knowledge to be able to understand all tasks carried out by his team
• time management and problem-solving skills
• great knowledge of the software used in the project

And the Project Manager, how is that role defined?    

Are you looking for an IT framework but you don’t know whether ITIL or COBIT would be the best fit for your organisational needs? Read on while we will try to help you by comparing the two most famous ITSM frameworks. Before we do so, we like to make sure that you are aware of the differences between IT governance and IT service management.

• In an IT environment, doing the right thing can be summarized in what the IT team decides to focus on to achieve the business aims. This is considered IT governance.
• When this has been decided, the IT team will focus on doing things right. In practical terms, this translates to how the IT team will carry out this task. This is considered IT service management.

IT governance works closely together with IT management. IT governance ensures that IT activities and processes are aligned with the overall objective, such as enterprise priorities. IT service management is the methodology used by IT teams to meet these objectives. There are multiple certification schemes to support IT service management. The two main certification schemes are ITIL v4 and Cobit. Essentially, COBIT and ITIL are two different methodologies that will support you in achieving the same objectives. At a certain point, these two frameworks can and will also complement each other.  

What is ITIL v4?

ITIL, developed by Axelos, is the most widely accepted approach to IT Service Management in the world. It is a set of specialized organisational capabilities for enabling value for customers in the form of services. It lays down the foundation for international standard practices that organisations and businesses alike can adopt, in part or in full, to deliver service value to their customers. ITIL 4, the latest evolution of ITIL, provides a tool that supports organisations in the era of digital transformation. It encompasses emerging practices such as Lean, Agile and DevOps and provides an end-to-end IT/Digital Operating Model. It covers the full delivery of tech-enabled products and services. ITIL guides and even lead how IT interfaces with the wider business strategy.   ITIL 4 helps with:

• Digital transformation
• Improving processes
• Helping teams work more collaboratively
• Transparency between IT operations and development teams
• Enabling automation

  The ITIL 4 framework consists of the following key elements:

• 7 guiding principles
• 4 dimensions of service management
• Service Value System (SVS)
• Service Value Chain (SVC)
• 34 Practices

  The focus of ITIL has steadily evolved over the years. Currently, its objective is to deliver value to the customer in the form of services, also mentioned as value co-creation. The key objective is to understand the parameters and needs involved in good service delivery. This is viewed from the service provider’s perspective, looking at the customer and/or business.  

What is COBIT?

COBIT is an IT governance framework developed by ISACA to help businesses develop, organize and implement strategies around information management and governance. COBIT Foundation 5 is the latest version of the ISACA framework. It provides a general end-to-end overview of a company's IT governance system, highlighting the central role of ICT in the process of creating value for businesses of all sizes.   COBIT 5 helps to:

• establish, communicate and impose the rules (policies) to be followed
• provides tools to verify alignment (compliance) with the rules
• measure the level of compliance of the organization
• manage/mitigate policy deviations

  The COBIT framework consists of the following key elements:

• 5 Fundamental principles for the governance and management of the IT Enterprise
• 7 Enabling elements
• A reference model for the process approach

The focus of COBIT has, just like ITIL, evolved. Its key objective is to ensure services are delivering stakeholder value from a business perspective, looking at a service delivery engine.  

Difference ITIL and COBIT

COBIT focuses on the overall enterprise when creating and managing the governance system. On the other hand, ITIL v4 focuses on even the smallest opportunities for value creation between service providers and service consumers. This means that COBIT is concerned with the overall system, whereas ITIL 4 is concerned with every process within the system regardless of its size. ITIL v4 has been continually evolving by applying an active and modular approach to IT service management. Consequently, ITIL 4 can be used by any organisation to manage and improve its IT services at all levels and at any size. COBIT is equally comprehensive in its coverage of IT governance. However, unlike ITIL v4 it would be difficult to scale down COBIT for use in a smaller organization. Yet, ITIL 4 and COBIT have been created for different purposes, so it would be unrealistic to expect them to apply to the same situation. IT governance is normally considered the study of ‘what’ an organization needs to achieve, whereas management is usually about ‘how’ to achieve it. In other words, COBIT is the governance framework and ITIL is the execution framework. Organisations need to take a comprehensive look at IT services and govern them with the assistance of a robust governance framework. Moreover, the framework will need strong support from the top of the organisation to achieve its aims. It is evident that COBIT can work in harmony with ITIL v4 in any complex IT environment. Particularly, the implementation of a COBIT governance system will be greatly supported by the existence of ITIL 4 practices in that IT environment. Whereas COBIT focuses on the governance of enterprise IT, ITIL v4 focuses on management and execution of IT in the enterprise for value creation. Enterprises should use COBIT for deciding the ‘what’ part of the IT service value equation and should depend on ITIL 4 for seeking answers to the ‘how,’ ‘when,’ and ‘where’ questions. Both frameworks can be applied in a specific environment to work together. The presence of one in a certain environment will benefit the implementation of the other.     Source: ITIL® 4 and COBIT® Axelos white paper written by Vishal Vyas COBIT® is a registered trademark of ISACA® in the United States and other countries. ITIL® is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

Once you have followed an ITIL course and obtained your certificate, you are ready to put all you learned into practice. But that is easier said than done. One of the ITIL 7 guiding principles is to ‘start where you are’, which means you have to assess your current situation and use that as your base. This means that you should work with all that you have built up over the years and use every source of information. Once you know how to start, the question is ‘how’? To help you support along the way of this journey, we strongly advise you to use a professional that can coach and guide you. Another option is to learn from situations in different organizations and talk with other ITIL users. In order to provide you with these contacts, QRP set up her very first ITIL online user event; ITIL Trial & Error. We invited a group of ITIL users from very different backgrounds and organizations and all we did was provide the discussion topic, based on a completed survey upfront. All that followed was in the user’s hands.  

From ITIL v3 to ITIL 4: what happened?

Based on a quick poll, the topic for our very first ITIL online user event was: - From ITIL v3 to ITIL 4: what happened? Last year Axelos updated the content of the ITIL certification scheme and added some additional modules. ITIL v3 changed into ITIL v4. Of the users that participated, much work with their v3 knowledge and created big value with the ITIL v3 implementation. Others started with ITIL 4. Many questions arose regarding the differences between ITIL 3 and ITIL v4. But also about the extra topics in ITIL 4 and the need for it. The topics of discussion were:

• What are the biggest differences between ITIL v3 and ITIL v4?
• Can we use ITILv3 and ITIL4 concepts together?
• Can we have different versions within the same company?
• Is it possible to merge both?
• Is it easier to start from scratch with ITIL4?

 

ITIL 4 provides more customer inclusion

One of our participants took the word to explain why his organisation decided to move from ITIL v3 to ITIL 4. He stated that the organisation decided to go from waterfall development to Agile development (including DevOps). In order to adhere to this change, the overall organisational perception was that ITIL v3 was not flexible enough and does favour a quick change pace. As ITIL 4 includes a lot more agility, ITIL 4 will respond easier to the change and make the use of ITIL more suitable to Agile development.

Others were in line with this and there was an overall understanding that ITIL v4 focuses more on customer inclusion and value co-creation. One of the many challenges that we discussed is: - How do you prioritize between customers? - Which customer needs more attention? - And how do you know this?

One of the ideas that were discussed is to provide each customer with a number of points (eg 100). The customer can use these points to prioritize the importance of the topic. Whether this works or is the right action to take, is a topic that is to be discussed in a future ITIL online user event.

 

Do you need to start with ITIL v3 to move into ITIL 4?

One participant of the event expressed doubt about where to start with an ITIL implementation. Whether to first implement ITIL v3 and then ITIL 4 or start immediately with ITIL v4. This especially in regards to old IT systems and little time and money spent on the IT department over the last couple of years. This doubt was answered by an explanation of our expert Kaȉs Albassir present, who explained that ITIL has 4 integrated dimensions. One of the dimensions is Information & Technology, in which you assess your situation regarding tools and technology. However, regarding the ITIL guiding principle ‘start where you are’, you can start implementing ITIL from your current state, ITIL v3 or ITIL 4. There is no need to first transform your organisation, ITIL can be part of that. If needed, you can simply adapt ITIL to your needs.  

Differences ITIL v3 and ITIL 4

If we have to sum up the differences that can be found between the different versions of ITIL, we can divide them based on their KPI’s. ITIL v3 has more IT-driven KPI’s while ITIL 4 has business-driven KPI’s. This reflects the ongoing changes that we can find in all organisations. IT was asked to do many things over the years and successful IT departments went from order picking by the business to enable business with co-creation of value. Nowadays IT enables the business to do more and adapt faster. ITIL can offer strong support to help guide this new role in IT.  

ITIL needs complete organisational involvement

As we spoke about how to start with ITIL, we also wondered how ITIL can thrive within an organisation. One of our participants explained why he believes it is key that ITIL is supported by senior management. He says that without their involvement you should not even start. However, you should also have buy-in from the whole company at each level, especially in ITIL4. This was strongly supported by another participant that made it clear that it is key that the ones that actually work on a daily basis with the ITIL concepts, have to support and adopt it. Implementing ITIL is a change and should be accompanied by change agents in the organisation. It is an implementation that needs strong support from inside and outside (consultant or coach) the organisation to be able to reach its full potential. If you do have to ‘sell’ it to your senior management, make sure that you mention that ITIL adds value. Value is the promise, the key and the main objective of ITIL.   We look forward to the ITIL user events we will have in the future to learn more from those that use ITIL on a daily basis. Would you like to join? Please contact us directly.  

I and my coworkers were seated at the table in our big co-working space. Employees from different sectors were brought together, ready to share their knowledge and skills with each other. It was 2014 and it was the first time we organised something alike. I just obtained my ITIIL V3 certification and was preparing the training of 60 of my colleagues. It happened that a young guy, who just finished his studies, gets the attention that he seeks. He believes he has something important to add to our meeting. His speech is rather absolute and he seems pretty convinced by himself and has a strong desire to criticize ITIL. I hear him say: ‘It is absolutely necessary to eliminate the bureaucracy due to the implementation of ITIL in organizations. I am defending a Service Management design that is much more flexible and effective. My reference system is easy to apply and it can quickly replace ITIL. After all, ITIL costs too much and blocks organizations in heavy and unnecessary processes. All organizations that have implemented ITIL are regretting it nowadays because they would like to get out, but do not have the opportunity to do so. And here I am. I just invested a week of my time and was about to sign a purchase order of €40 000 to train a complete team on the ITIL best practices. Just imagine my concern! At the same time, I realized that this was an opportunity to broaden my knowledge. I needed to know more.   So I decided to challenge the guy. Our conversation went as follows: “How are accidents resolved within your framework?” “Well there is are almost no more incidents, so a return to Excel is more than enough” “Wow Ok...So just for me to understand; Is there an upstream contingency management approach? A proactive resolution to potential incidents based on observed events?” “Not even, the systems are stable by nature...” “Due to a specific set of technological choices?” “Yes of course, but above all thanks to a development method which removes any bug source…” “An Agile method” “Well yes, are there any other development methods?” At this point, I was triggered and thought «Let’s continue»! “So tell me, do you have any concrete examples of organizations that are locked with ITIL and like to leave? I would be very interested to understand their experience so that I can avoid making the same mistakes in my Service Management". “Like I said. All of them!”   At this point, I understood that I was dealing with a brilliant young guy that had lots of talent for argumentation and public speaking. However, no experience whatsoever with Service Management. I decided to end our discussion and postponed my interrogation to a later moment. While we were all going back to our workplace, I went over to ask him the name of the magical Best Practice method we just discussed. He replied absently; “it is called DevOps". This was my first contact with DevOps. The brilliant young guy had learned the DevOps lessons well but had not yet captured its essence. So I decided to investigate the methodology independently. I found my path and I finally entered the world of DevOps.   But without ever leaving ITIL! At that time, there was very little documentation on DevOps. Initially, they were just good ideas that together formed a magma full of good intentions of which we could only feel the enormous potential. In that same year, the first DevOps book was published. It is a book on IT and DevOps called ‘The Phoenix Project". It tells the story of an organization’s transformation through the radical change of its IT services. It is a book full of lessons, just reading it will provide you with experience on the topic. It is true that at the beginning of the book some ITIL processes are criticized for their complexity. However, it does not tell you to discard the practices completely. Going forward in the book, you realize the essential influence of Best Practices such as ITIL on the success of the DevOps transformation. Another key lesson is that while applying a Best Practice, it is important to eliminate everything that does not produce value. Doing this will provide you with a Lean-ITIL concept that covers part of the path towards DevOps. Over time, DevOps has gained maturity, as have its users and experts. It is clearly indicated in the first pages of the Foundation training, that the three sources of inspiration for DevOps are ITIL, Lean and Agile. Just to make my point even stronger, ITIL’s obsolescence is considered to be one of the false myths about DevOps. I strongly believe that IT Service Management and the DevOps movement are not opposites. On the contrary, they offer a perfect cultural marriage (these are the words of Gene Kim, co-author of "The Phoenix Project" and the ‘DevOps Handbook’). This quote dates back to before the release of ITIL 4, which with its update has become more agile. If DevOps did not contain interest in ITIL V3, needless to say, it did not contain interest in ITIL 4.   It, therefore, remains essential for IT services to acknowledge and apply ITIL practices in order to successfully use DevOps. I often think about that young and brilliant guy. I can only thank him for initiating my DevOps journey. I don't blame him for his carefree lightness ... On the contrary, I wish him to have gained maturity at the same rate as the movement we represent together today! Want to continue reading about DevOps? We strongly advise you to read the blogpost ‘The DevOps Skills’ to understand the skill set that is needed to work in a DevOps environment. Curious about the journey of DevOps and want to know what to expect from the Best Practice method this year? Read ‘10 DevOps trends to watch in 2020’.    

Xavier Heusdens

ITIL 4 and DevOps expert and trainer

Xavier has over 20 years of experience in project and program management. In addition to his consulting activities, Xavier is a multilingual trainer for PMP, PRINCE2 and DevOps. Xavier has an outstanding knowledge of different Best Practices and holds AgilePM, ITIL, COBIT, MOP and Change Management certifications.