Basic Concepts of ITIL and Agile
There has always been a debate which method of programming and manufacturing is the best. While we do not pretend to be experts, we will review two of the most popular ways in the last several decades of the modern industrial revolution. Normally they are regarded as methodologies or frameworks, but it is more precise to review them as a set of values and principles.
ITIL and Agile have gained a tremendous popularity, especially with their adoption in most of the IT giants' production cycles. To name a few - HP, IBM, Lenovo, etc. The selection of which one to use as an engine to your business, depends on your goals. Here, we will outline some of the basic differences between these two. And even if this has been done a thousand times, we will try to underline the practicality of both.
ITIL or the Information Technology Infrastructure Library is the oldest of both and relies on a huge number of best practices, regarding the product/service/program as one entity - as one whole that has to be fully completed at the end of the production cycle. You get a time period, for which you will receive a final product with all its predefined features and necessary iterations and which you cannot build upon but only improve with new versions. The structure is from the top down - client and managers decide what is needed and the team of programmers works on that. It is strongly relying on process, and implements in itself also a help desk, it service desk, etc. - departments which are serving different functions of the product or service. The FUNCTION is the main fundamental notion of ITIL, as the whole production cycle is dedicated to it and it is measured by KPIs (Key Performance Indicators). ITIL has been divided in 5 basic stages and the time consumed for the final product is usually longer than the one in Agile. On the discretion of the Project Manager one of these, or some of these stages can be omitted but that is a private case/instance. The whole team is working together on the project and changes are made in one of the phases of the process. Here are the 5 stages, and what do they include in the development cycle:
- Service Strategy - I would say also product strategy - includes the vision and mission of the team
- Service/Product Design - includes the plan, the timeline and the sources used to accomplish the project
- Service/Product Transition - includes development to operational phase; Change Management, project management, release management
- Service/Product Operation - includes problem management, incident management, access management as well as service requests
- Continual Service/Product Improvement - take a note that this is an upgrade and not an update function. This includes implementation of new technologies and new features. Basically leads to a complete new product in most cases, due to significant differences in FUNCTION (not necessarily always).
This is the most simple explanation of ITIL I can come up with.
Agile on the other hand is the smaller but a bit more versatile brother of ITIL (or sister if you want). The concept is the division of the team in small groups - things are done in short spans of time, the team manages itself, there is constant feedback, goals are constantly changing, and there are usually weekly meetings. Succeed or fail quickly should be the motto of Agile, because you start building a base, and on that base you keep piling up new features. There are no long term goals as there is no information what the final product will look like, there is no notion of FINAL PRODUCT. All is build upon the need of new features and constant change. The structure here is from the bottom up, starting with the programmers and moving up the ladder, which gives immense flexibility. You get information boards, checklists and short term check-marks - whatever is done, gets checked on the board. On the weekly meetings you constantly have a grip on where the development is headed and the control is more reliable.
What worked well? What did not work well? What do we want for the future/ the week ahead? -
to just note a few of possible questions on those meetings.
Therefore, Agile, if in a constantly changing environment as today's technology is growing and extremely rapidly shape-shifting, gives more options to adapt, to be flexible and to stay open-minded for change. It stimulates the progress but preserves the core. The most important here is to define your mission and identify your values. When you focus on what you do right, you can keep building upon it and around it.
Agile has also been divided in two possible work processes. There is a defined time-frame development - SCRUM, where you get bi-weekly periods to implement new features, and what gets aside, stays aside and gets excluded. And there is the KANBAN, where you have no time frame but a certain set of features that needs implementation.
Here is an example for both practices:
If we have one year time to implement feedback system, backup system, rating system and an error-reporting system in a product, this is what we will get:
SCRUM - there will be a division of time chunks for each feature - in this case 3-months period for each and development will be defined in its own area for that time period. You cannot build the rating in the time frame for the backup.
KANBAN - you get one year to have the features implemented. That is it. There is no particular order, and no time boundaries which one should be first and when is needed (in an ideal world).
This is basically what ITIL and Agile are about. I hope it will be more clear now when you meet the terms and will not wonder anymore what the difference is.