The Agile Manifesto (Agile Software Development Manifesto) is the series of principles that were suggested by 17 software gurus in 2001 in the state of Utah, USA after the brainstorming to evaluate the experience and methods related to software processes and to reveal more productive methods. These principles have become a serious trend applied in software development projects in Turkey as well as all over the world. The following 4-item final declaration, on which a consensus was reached as a result of the meeting and which emerged as the result of the meeting, was published with the name "Agile Software Development Manifesto".

We are experiencing a period in which agile methods are commercialized, and the underlying purposes of the Agile philosophy are tried to be applied "in appearance" without understanding them. Rather than trying to own and apply an agile framework such as Kanban or Scrum, our basic principle is to understand four key messages of the Agile manifesto and apply them independently of the process, tool and method.

• Working software over comprehensive documentation: The Agile approach defends to prepare a document to tell "what has been done, not what will be done". Because, according to the Agile approach, the customer demand is a content that is defined as "speculative content" until the end of the project, naturally open to change. In this sense, it is both difficult and costly to make a content that is open to change in a written form and keep it up to date. Our aim is to present the work to be performed, as visualized tangibly with coding of the customer requirement and a prototype work in the requirement analysis stage, instead of writing word documents on the first day. The analysis phase of our projects is no longer a process that can be successfully carried out by people without technical skills. The role of analyst today needs to have technical know-how and skills in the level with which the prototype can be produced together with the customer. That is why, in the CALIGO organization, employees in the "Consultant" profile, who can solve the customer's needs end-to-end, are trained rather than setting a division of labour focused of the role of "Software Developer" or "Analyst".

• Individuals and interactions over processes and tools: Requirements entered by business units but disappearing in demand management applications, requirement documents that have emerged as a result of the approach "You need to communicate your requirement to IT definitely by writing a document”, but are just waste of time since they do not express their intentions fully show that it is inevitable to support software tools and processes with effective communication. It is an integral part of our successful project approach to support existing processes and tools with effective communication and cooperation, to come together, and to act by accepting that there is no more successful communication methods than face-to-face communication, instead of being attached blindly to rigid processes and tools.

• Customer collaboration over contract negotiation: We are conscious that the project success depends mainly on the active participation and support of both parties in IT-business unit cooperation. We are acting with the conscious that a successful IT project is not only a project that is completed on time and within the planned budget; but also a productive solution in which an added value is contributed by the customer. The flexibility of project plans when needed and as a result, the emergence of a product that really meets the needs of the customer is a principle that we especially consider in our projects.

• Responding to change over following a plan: It must be naturally accepted that today's rapidly changing technological, economic and sociological factors are constantly changing the way to do business. Instead of long-term rigid IT plans, we are acting with the acceptance that flexible plans are more efficient to meet the changing needs of the customer. In addition to the methodological changes, the possibility of change in data behaviour should be particularly taken into account, and the impact of data changes on the existing developed solutions needs to be constantly monitored. Data-focused projects have turned into disciplines that need to continuously take the required change actions for the developed solutions to comply with today’s conditions, rather than just designing automated solutions on a turnkey basis and leave it running.

Prototype & Requirement Gathering

Thanks to prototype works, we reveal the results of the customer requirement in a short time and tangibly and we improve the missing or open points of the requirement together with the owner of the requirement. It is the only way for the customer to be confident of the efficiency of the demand before long IT development processes, and to determine the factors that cause the change at the beginning of the project and take the necessary actions accordingly.

Technical Works & Documentation

The completion of long developmental works, such as documentation, preparation of target data models, development of ETL processes in accordance with design standards, after the prototyping works means the completion and finalization of technical works in one go. Thanks to this method, we can get rid of inefficient cycles such as repeatedly changing documents and data models, redesigned ETL processes. In addition to the efficiency of technical works, we argue that the optimal documentation method is to write the project documentation at the end of the project from the point of view of writing "what has been done, not what will be done". We see it as the most effective way of achieving the "Excellent project document" standard, avoiding the differences between the project documents and the ETL jobs.