• manage priority changes. An unpleasant challenge for almost all companies. Your requirements will definitely change if you are doing the project that lasts at least a few months.What about commercial development, the problem is that programmers, analysts and designers never know what customer who pays us and users need. The usual approach is: until the user tries the site or application, you do not know whether it is needed or not;

• improve cooperation between IT and business. This is a headache, especially for large companies. Business requirements change from time to time, everyone speaks their own language. As a result, the parties do not understand each other.

Before diving into Agile, it is important to learn terminology in order to lay the foundation for our understanding of this approach. We will analyze all the terms in more detail during the dive, so do not be afraid that at the very beginning they will seem abstract and difficult to understand:

The very idea of Agile is to learn how to work with the unknown and fill blank pages of our work due to an iterative approach (working on short sprints6 of 1-2 weeks).

This helps not only to keep up with the industry, but also to meet customer expectations and remain competitive.

Implementing Agile while building a software development process we start revealing practices:

• first of all Stand-Ups (Daily Stand-Ups)7. This is an easy practice: your team should meet regularly to synchronize the development process. Communication is key to developing effective teamwork, and poor communication can be one of the biggest reasons why a project fails in Agile teams. A daily stand up is a part of the agile methodology because it helps with improving communication among team members. Integrating effective communication with face-to-face contact as a part of the team’s culture helps in creating a more Agile workplace;

• the second is Sprint Planning8. Your team should plan the work for the nearest iteration. It is an iterative approach, allowing teams to accelerate the delivery of value to customers and avoid unnecessary headaches. Instead of releasing the entire product as a whole, the agile team performs the work within small but convenient increments. Requirements, plans and results are constantly being checked for relevance, so that teams can quickly respond to changes;

• unit-testing9. This is a software testing method by which individual units of source code (sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures) are tested to determine whether they are fit for use. Unit tests are typically automated tests written and run by software developers to ensure that a Chapter of an application or a program (known as the "unit") meets its design and behaves as intended. This is one of the simplest engineering practices that you can start using quickly. About 60-70% of bugs can be caught by unit testing;

• Release Planning10. We plan it in large parts: what and when we will release. Agile release planning is a product management method where you plan incremental releases of a product. It differs from raditional software planning where you focus on major releases. Using a release plan helps you plan which product increments (versions) get released to the market and when. And it’s an integral part of the Agile SDLC (Software Development Life Cycle) because it can also give higher-ups peace of mind that there’s a structure and plan beyond just the next sprint, and helps the individual Agile teams stay on track. What about Scrum, we can measure it with sprints (sprint planning).

It’s no secret that change is hard and can be difficult to be taken, especially with complex projects. Making even slight changes to existing systems can often feel laborious and not worth the effort. Studies show (Identifying the Reasons for Software Project Failure and Some of their Proposed Remedial through BRIDGE Process Models. INTERNATIONAL JOURNAL OF COMPUTER SCIENCES AND ENGINEERING. January, 2015, 3(1):118-126) that 60-80% of project failures can be caused by poor requirements gathering, analysis, and change management. The agile mindset is the best approach to variable and challenging environment as it offers an opportunity to embrace change, rather than continuously avoid it. It isn’t something that teams achieve, but rather something that is continuously cultivated. Developing teams should strive to optimize, solve problems, reflect, and continuously improve in the process.

Both Agile principles and values contain a very correct message, but they look quite abstract from the first sight. Agile methodology practices add to understanding of this approach. In order to investigate how Agile works, let's turn to the diagram and take a detailed look at the meaning of each link in Agile software development process:

LET'S SUMMARIZE WHAT WE’VE LEARNED IN THIS CHAPTER:

in brief, flexible methodology emergence was as natural as IT industry development. Deviation from out of time methods and software development flexibility request were influenced by huge expansion of the IT market and the subsequent demand for faster value to the consumer delivery.

Besides, now we know:

• Agile methodology started from 4 values which were followed by 12 principles;

• An iterative method of software development is in the base of agile approach;

• It gives developers an opportunity to deliver value to the consumer faster.

Let's see what approaches also exist in the world of software development besides the agile approach. First of all, this is the previously mentioned cascade methodology, also called "waterfall". We have already learned that in 1970 Dr. Winston Royce defined Waterfall methodology and suggested its basic principles:

• Program design comes first. Program designers work on the design of the system, not developers. Designers allocate e data processing models: database scheme, resources, some kind of non-functional requirements, interface, etc. Then an overview document must be prepared. The document should be understandable, informative, and current. Each team member must have an understanding of the system, and at least one person must have a deep understanding.

• Document the design. Some (in fact most) developers may wonder how much documentation is needed. Royce gives a simple answer: “Quite a lot”. Moreover, he says: “If the documentation is in serious default, my first recommendation is simple. Replace the project management. Stop all activities not related to documentation. Bring the documentation up to acceptable standards.”

Why documentation is important? Royce gives some points:

• documentation is a way of effective communication;