Thus, the Agile method is applied to:
• accelerate the product launch to the market. If you want to develop software faster, you need to apply Agile. For example, two similar business companies. The first one creates the technical task for software development, designs the structure and interface consistently, this is a waterfall model, implementing it can take several months. Another team can already release a website and software applying Agile, start earning money and hijack the market;
• 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 sprints[6 - A short time period during which a scrum team performs a given amount of work.] 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 - A short meeting from 5 to 20 minutes a day, at which team members tell share what is happening in their work tasks.]. 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 Planning[8 - The meeting that starts each sprint, and is intended to determine the team's work plan throughout the sprint.]. 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-testing[9 - This is a software testing method by which individual units of source code are tested to determine whether they are fit for use.]. 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 Planning[10 - This is a product management method in which you develop a strategy for its phased release.]. 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.
CHAPTER 2. WHAT ARE THE OTHER METHODOLOGIES? LET'S COMPARE WATERFALL AND AGILE
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;
• during the early phase, the documentation is the specification and is the design;
• during the testing phase, the documentation can be considered as acceptance criteria;
• the documentation help newcomers to understand the system better.
• Do it twice. If your system is original, you want to verify your ideas or concept. Royce recommends creating some kind of MVP (Minimum Viable Product)[11 - The product or service test version with a minimal set of functions (sometimes even one) that delivers value to the end user.] of your product to check the ideas. Then, the second version of your product will be finally delivered. The first version may not be provided to final customers/users, but stakeholders[12 - A person or an organization that has rights, interests, requirements or interests regarding the system or its properties that meet their needs and expectations.] want to see a prototype of the product. It may lead to requirement changes, and it is an effective way of the development process. The final version of the product will be closer to market needs.
• Plan, control, and monitor testing. Testing is one of the most important phases of the SDLC (Software Development Life Cycle)[13 - The information systems creating concept, including their planning, development, testing and deployment.]. You check your ideas and concepts, verify implemented system comparing it with system design. Royce recommends inviting the other persons to verify your system. He says that it would be more effective to give a big part of the testing to people who did not contribute to the system during the previous phases. The documentation will help them to test the system better.
• Involve the customer. Your project customer and stakeholders should be involved in all phases of the development. They will help to design and implement a system that will meet their needs closer. Moreover, the stakeholder may change their opinion about the system and give new requirements. As a Project Manager you should meet the changes with pleasure because after all your customer will be satisfied.
Waterfall is based on a logical sequence of steps that must be taken throughout the software development lifecycle. Each stage is coordinated by competent employees, documented and passed on.
Although the popularity of the Waterfall model has waned in recent years, but the nature of the sequential process used in the waterfall method is intuitively close to developers.
The model proposed by Dr. Royce is extremely simple and clear. It consists of several blocks, each of them covers its own area of responsibility.
Let's look closer at the difference between Agile and Waterfall methodologies.
In management, there is a concept of a project management triangle[14 - This is a model, illustrating the three constraints interdependence: time, money and scale, as well as how changing one factor requires changing others.]:
It includes the amount of work, time and quality. It is important to note that the balance in any methodology is created due to a system of assumptions, so in cascade approach quality can be reduced, and in Agile the amount of work can easily grow.
The project management triangle clearly displays the so-called triple limitation problem associated with the need to balance the scope of the project, its cost and time for implementation without compromising the quality of the final product. Taking into consideration the concept of project management triangle, the difference between approaches will look like this:
In recent years, the waterfall model has been losing its leading position to more flexible methodologies. This is due to the general dynamics in IT, when teams of 5-9 people are responsible for software development, and the deadline can be easily shifted due to the increase in functionality.
Nevertheless, the cascade model is still relevant for large projects and organizations:
• It is resistant to personnel changes. Developers can come and go throughout the life cycle of the project, but thanks to detailed documentation, this practically does not affect the timing of the project;
• Waterfall model forces developers involved in the project to be disciplined and to stay within the plan. If necessary, a management body responsible for decision-making is added to the general model, while performers are required to work within the system framework[15 - A ready-made set of tools that helps a developer to quickly create a product: a website, an application, an online store etc.];
• Flexibility in the early stages. Changes in early phases can be made immediately and with minimal effort, since they are not backed up by code. Thus, the customer and the contractor have a significant time margin for a radical change in the concept of software work;
• Focus on deadlines and finances. Due to the fact that each stage completely outlines the contour of the future software, all developers understand their role, the boundaries of work and deadlines. This allows you to cooperate with the customer knowing the real cost of development and makes, therefore, the project model attractive.
In the 1970s, Royce's ideas were relevant. But after almost 50 years, the cascade development method is less and less suitable for IT:
• non-adaptive software structure. At the first stages, the waterfall model can be flexible, but if problems in the overall structure are identified during the testing phase, this entails deplorable consequences in the form of disrupted deadlines and even customer failures;
• ignores the end user. The lower the process progresses in the waterfall, the less the role of the customer in it, not to mention the users he represents. Making any changes to the functionality of the software starts the entire chain of stages anew, so the products obtained by the cascade model are far from targeting the mass user;
• later testing. It is here that mistakes made at each of the stages are most often identified. More flexible methodologies use testing as a fundamental operation that occurs continuously. Waterfall, on the other hand, admits low qualifications of employees at each stage and poor quality of execution, because with late testing, problems cannot be solved fundamentally, only with the help of "patches".
Let's fix both approaches pros and cons:
Everything seems to be transparent, but in practice the question often arises which methodology to apply in each specific case. This scheme helps us mostly to make the right choice:
It turns out that the cascade methodology is an excellent solution in terms of deadlines and reporting, but very weak in terms of quality.
Despite the fact that these 3 points are increasingly rare in real practice, the cascade model will be popular and in demand for a long time because of its clear organization. This means that any professional developer should understand its basic principles and be ready to exist within the framework of this approach.
LET'S SUMMARIZE WHAT WE’VE LEARNED IN THIS CHAPTER:
Agile and Waterfall are the most common but opposite to each other software development approaches. While commending the waterfall methodology, it is necessary to move forward and look ahead, addressing contemporary challenges here and now. Agile is just what you need for this. We have also learned, that:
• software development methodologies should be evaluated using project management triangle;
• Agile methodology gained great popularity and changed software development forever by now;
• Waterfall or Cascade methodology is still in demand, so developers should be ready to exist within this approach.
CHAPTER 3. IMPLEMENTING AGILE APPROACH IDEAS INTO PRACTICE. LET'S BREAK DOWN THE INSTRUMENTS AND TECHNIQUES
Let’s look at frameworks that are used to implement Agile Approach ideas into real practice, but first let’s explain what a framework is.
