Agile technologies. Agile development methodology (Agile)

Staff

Everyone knows the example of the Toyota plant, which was included in classic management textbooks, where each employee had the right to stop the conveyor in order to eliminate a defect or make a rationalization proposal. It is this approach that formed the basis of the Agile philosophy.

Agile, which appeared as a method of software development in small teams 10-15 years ago, is now becoming the new culture of managing large companies. The term Agile is included in the lexicon of all modern Russian managers.

What is Agile and why is this method called almost the only correct one?

There is a classic approach to creating products and services, which is primarily characteristic of the IT industry. This approach is called a waterfall or iterative development methodology. In English terminology, this approach is called waterfall development (from English - waterfall). Why is it called a waterfall? Because with such a development scheme, once you have approved a software product plan, you will not be able to stop or change this plan before it is created.

Agile is an innovative approach to rethinking the creation of a new product or service. It is based on a very simple idea: each participant in the process, each employee of this “conveyor assembly” should be involved in the process of rethinking their tasks and the common cause. Everyone can stop the conveyor and make their own rational proposals.

In most organizations, when creating software products , the people responsible for certain stages of the project are located in various, often conflicting, departments.
It's no secret that operations staff, testers, and developers are usually in conflict with each other. And if the product does not work and does not bring profit to the business, then everyone strives to blame the other. Although in fact, in such cases, as a rule, everyone is to blame.

The Agile method involves the involvement of all participants in the software product development process, leaving the participants with familiar competencies. This approach makes it clear that they all work for the same end goal - a quality product for their customers.

So there is a change in the business culture of the enterprise itself. As part of the MBA programs, there is a whole course that deals with the organizational structure of the company. There is a concept of equilibrium in it, when everyone does everything inside start-up companies and start-ups, which is often why a friendly team is born there that effectively acts on the market. And in terms of efficiency and bringing new ideas to market, this is the ideal organizational structure.

Of course, there are organizations that do not need Agile at all. For example, government departments. Their activities are based on legislation. We will not be able to interact with the state if the rules of the game change every day.
Thus, we have two radical opposites of organizational infrastructure.
On the one hand, there is the strictest bureaucratic formalized organization, which is used in certain cases and works well in certain situations. And the complete diametrical opposite of it is young startups, teams of like-minded people who really create something new, and Agile is much closer to the state of an emotional team that works for the ultimate goal, a workable high-quality (software) product. And therefore, the problems that arise at any stage are the problems of all people, and everyone who is able to solve them is involved in this process.

The transition of a large classical business (Enterprise) to Agile

This is an extremely important question, and it is very interesting.
The whole world is talking about this, German Gref said the same. He said: “Guys, we are a bank, our competitors are not banks, our competitors are young companies bringing digital to society.” An advanced business is based on three pillars: experience and knowledge in the industry (in which the business operates), development of products and services using the Agile methodology, and most importantly, an innovative culture.

Leading IT companies, having easily copied banking products and services, begin to complete (or transform) them to a level that the bank cannot bring them to, since a traditional financial institution does not have a sufficiently developed innovation culture.

A very simple example is microfinance organizations. These are firms that literally create a service with a snap of their fingers. Today the company appeared, issued a loan at an incredibly high interest rate - tomorrow it will have a profitability many times greater than that of a bank. Such organizations can instantly rebuild their services and products, quickly enter new markets, displacing classical banks.

Similar things are happening not only in the banking industry, it happens in all industries and business areas. Mobile operators are starting to deal with payment systems. Uber has changed the way they travel around the world in a few years, and Airbnb has done the same with the hospitality travel industry.

Flexible planning

With waterfall development, you have to plan a year ahead. But if something changes - for example, more servers or other components are required, then such a scenario is possible when the project is stopped - after all, it will be necessary to conduct a new tender, buy new infrastructure, etc.

That is, Agile becomes not just a methodology for creating new software, but a system of flexible planning for the development of the entire company.
Such an infrastructure should be built that also flexibly responds to requests from customers and requirements that change during the development of a software product and its operation (this, by the way, implies a total transition to cloud technologies). Agile planning requires understanding and analysis of each business process. And this is the next stage in the development of the company - its digitalization.

For a modern digital enterprise, there should be three components: agile development methodology, agile infrastructure that adapts to it, and big data analytics.
Here is what happened to my colleague from the USA. He was driving a taxi to the airport, missed his plane, tweeted that he missed his flight due to a traffic jam. When he arrived at the airport, he received an SMS: “Please follow the link - an electronic boarding pass is ready for you. XXX Airlines has rebooked you for the next flight." This is a real example when an airline's system analyzes disparate information and makes decisions based on it in order to improve the quality of services for its customers.

A separate question: do I want something to happen in the outside world for every sneeze I make?
Another example is the Sundance Institute, a global platform for supporting independent auteur filmmaking.
Over the past 30 years, the Sundance Institute has acquired a wealth of information about films, crews, and audience activity. The more information accumulated, the more difficult it was to structure it and use it accordingly.

The fragmentation of data and the lack of a single database did not allow the involvement of specialists from past projects and slowed down new ones.
The festival management invited engineers from Pivotal (a company that is part of the EMC federation) to create a single portal that combined all the information related to Sundance.
As a result, the platform is used by festival staff, volunteers, industry professionals, and film lovers alike.

How can classic enterprises implement the Agile philosophy? What needs to be done to turn the disparate departments of a large company into a team of like-minded people, as in startups?

Leadership and responsibility is the only answer. The leader must first of all bring something new to the company every day, and this desire for innovation will become the basis of the corporate culture of the organization.
An innovative culture is laid down in the principles of forming a team of managers, the topics of discussions that take place at all meetings, setting strategic goals, the mission and vision of the company. And without it in any way.

- And about the implementation strategy and scope of Agile and SCRUM from Mikhail Sofronov **

Don't lose. Subscribe and receive a link to the article in your email.

Have you ever been involved in projects or at least take part in project work ? If yes, then you have probably noticed that getting the team working can be quite difficult. And even if it is established, there is a risk that all efforts will be in vain, because the requirements for the desired result often change.

However, it is possible to significantly simplify the work on the project and learn how to manage it, thereby increasing the efficiency of the team, using a flexible project management system called Agile (“Agile” or “Agile”). In general, we have already briefly talked about it in our (fourth lesson), but now we will talk about this topic in more detail.

Agile Method: Definition and Brief History

No matter how unusual it may sound, the serious development of software and project management began already in the 70s of the last century. It was in 1970 that the American computer scientist Winston Royce wrote a paper called "Managing the Development of Large Software Systems." In it, he criticized sequential development, pointing out that software development should not be like running an assembly line (as is done, for example, in car manufacturing), where new parts are added one by one in successive phases.

Instead of waiting for each stage (phase) to be completed in turn, Royce proposed a phase approach. Its essence is that initially all the requirements necessary for the project are collected, after which the entire architecture is completed, the design is created, the code is written, etc.

Based on this, in the 90s it was possible to create a set of flexible software development methods that can replace complex and time-consuming methods. It happened like this:

In 1991, the rapid application development method RAD was born.
In 1994, a method for developing dynamic systems DSDM appeared
In 1995, the Scrum agile development platform (framework) appeared.
In 1996, the Crystal Clear agile development methodology was born, as well as XP Extreme Programming.
In 1997, an iterative methodology for developing FDD software appeared

Together, these methods have come together under the general name of agile software development methods.

Four years later, in 2001, seventeen software developers gathered at the Snowbird resort in Utah (USA). As a result of the discussion of development methods, the “Agile Software Development Manifesto” was published . He set the pace for all further work on the creation of software.

Agile Manifesto

The manifesto, created by programmers, includes 4 basic ideas and 12 principles of effective project management. Any of the Agile-based project management systems (we will talk about systems later) relies on these ideas and principles, although it uses them in different variations.

People and their interactions are more important than processes and tools
Working software is more important than documentation
Clients and cooperation with them is more important than a contract and negotiation of conditions
Willingness to make changes is more important than the original plan

Agile principles:

Satisfy customers by delivering software early and consistently (customers are happy when working software arrives regularly and at regular intervals)
Change the requirements for the final product throughout the development cycle
Deliver working software as often as possible (once a week, every two weeks, a month, etc.)
Maintain collaboration between developers and the customer throughout the development cycle
Support and motivate everyone involved in the project (if she does her job much better than a team whose members are dissatisfied with working conditions)
Provide direct interaction between developers (the possibility of direct contact contributes to more successful communication)
Measure progress through working software only (customers should only receive functional and working software)
Maintain a continuous pace of work (the team must develop an optimal and sustained work rate)
Pay attention to design and technical details (thanks to effective skills and good design, the project team gets the opportunity to constantly improve the product and work on its improvement)
Try to make the workflow as simple as possible, and the software - simple and understandable
Allow team members (if developers can make decisions themselves, organize themselves and communicate with other team members, exchanging ideas with them, the likelihood of creating a quality product increases significantly)
Constantly adapt to a changing environment (thanks to this, the finished product will be more competitive)

While learning Agile, in addition to an overview of ideas and rules, be sure to check out this short video, where Alexey Tachenkov, a project management specialist, consultant and business coach, talks about the basics of the system.

In order to actually put into practice the above ideas and principles, it is necessary to adhere to several rules. Only then can Agile project management be effective.

Key Points in Applying Agile

Agile methodology is based primarily on visual control. Most often, project participants, working on achieving results, use special color cards. One color indicates the completion of the planning of some element of the final product, the other - the completion of its development, the third - the readiness, etc. Visual control allows the team to have a visual representation of the current state of the process and ensures the same vision of the project by all its members.

Team members and the client in most cases work together and side by side. Thanks to this, many work processes that are associated with informing project participants are significantly accelerated. In addition, working together contributes to creating a healthy environment for fruitful and effective cooperation and the fastest achievement of results.

When the project manager, team and client work together, there is no danger of misunderstanding of goals and loss of information. All work processes become as transparent as possible, which means that any problems that arise can be resolved almost instantly and find the best options for solving them.

Particular attention should be paid to the project manager. He cannot be called a man who gives instructions left and right. The leader here acts rather as a leader who sets the direction and determines the rules for cooperation and work. In other words, Agile management is adaptable.

Another important point of the Agile methodology is the division of the entire scope of the project into several smaller components. This approach greatly simplifies the development process, and individual groups of the team can each focus on their specific task.

Working on one cycle, the project participants master new skills and gain new knowledge, as well as analyze the mistakes made in the process. All this reduces the likelihood of making such mistakes in the future (in the next cycles and other projects) to almost zero.

And finally, the last significant element of the approach is sprints and daily meetings. Sprints are called limited by specific deadlines (deadlines) periods of time during which the team manages to complete certain tasks. It is thanks to sprints that the team can see the results of their actions.

If we divide all the time allotted for the project into several sprints, we get a specific number of them; let there be 15 of them. Each sprint lasts, for example, two weeks. That's just during these two weeks (the time allotted for the sprint) participants meet every day to discuss the process and progress.

Daily meetings should not exceed 15 minutes. They are organized so that each team member gives himself the answer to three questions:

What did I do yesterday?
What will I be doing today?
What's stopping me from working?

Answering these questions allows you to keep the process under control, understand at what stage each of the team members is, and eliminate potential problems on the way to the goal. To summarize, the implementation of the Agile methodology is possible if several conditions are met:

The meaning of the project is clearly indicated
The client is actively involved in the implementation process
The total amount of work is carried out step by step
Focus on specific results
Number of one working group: from 7 to 9 people

Currently, Agile-supported project management is mostly distributed in the IT sphere, however, the business sphere is also beginning to master it. This system is used in education, marketing, business. Agile project management is adopted by many companies and government agencies.

Examples: New Zealand government, Nigerian government, Norwegian Pension Fund, Return Path (software), Oreo (cookies), Aviasales (largest airline ticket search engine), Hewlett-Packard (largest US IT company), Sberbank (you probably know what it is).

These and many other organizations use a variety of Agile-based project management methods in their work. And talking about these methods is no less important than talking about the methodology itself.

Popular project management methods

There are many project management methods that are used by various modern companies. But the most famous and popular among them are considered to be Scrum (Scrum) and Kanban (Kanban).

Scrum method

Among all the methods of the Agile Scrum system, it differs in that it emphasizes the quality control of the workflow. Japanese strategic management specialists Hirotaka Takuechi and science and technology professor Ikujiro Nonaka, who first described it, call the method the “rugby approach”, where Scrum is “fight for the ball”.

The method is that the development of the project is divided into sprints, after which the client receives improved software. Sprints are strictly fixed in time, and can last from 2 to 4 weeks. The workflow in one sprint includes several stages:

The scope of work is determined
Every day, 15-minute meetings are held so that team members can adjust their work and summarize intermediate results
The results are shown
Sprints are discussed to find good and bad decisions and actions

In most cases, Scrum is used to work with complex software and to develop a product using incremental and iterative methods. Thanks to him, the productivity of the team is seriously increased and the time spent on .

Scrum improves results, helps the project adapt to change, provides more accurate estimates with less analysis effort, and gives you more control over work steps and the project scenario. All this is the best fit for business goals.

Kanban Method

Kanban is another method that makes teamwork more efficient and productive. Its meaning comes down to giving the development process maximum transparency and even distribution of the load among the project participants. An important feature of Kanban is that it motivates people to constantly collaborate, improve and learn.

The work of the Kanban method is built on several principles. Firstly, all information about the project must be visualized, which allows you to see overlays, errors and shortcomings and actively eliminate them. Secondly, work on one task should be carried out simultaneously by the whole team - this helps to balance efforts and results, eliminates uneven distribution of workload. And thirdly, the time to complete all tasks is strictly controlled, which optimizes the process and saves time.

Unlike Scrum, Kanban gained popularity much later, but this in no way detracts from its merits and does not make it less effective. The method is useful both in the IT field and in the business field.

These are just examples of the main Agile project management practices. But do not neglect other methods such as PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall and others. In addition, Agile, along with the advantages, has some disadvantages.

Pros and Cons of Agile

When learning Agile, it is important to be aware of both the positives and the negatives of this methodology. Let's start with the positives.

First of all, it is worth noting that Agile management is very flexible. If, for example, the traditional methodology points to specific stages of work, then Agile easily adapts to the consumer of the final product and customer requirements.

Actually, the number of defects in the final product is minimized, because it is the result of a thorough quality check, which is carried out at the end of each sprint stage.

In addition, Agile is quick to launch, responsive to change, and allows the development team and clients to stay in constant real-time communication. The advantages are obvious, but let's talk about the cons.

The shortcomings of the methodology are that, firstly, constant feedback can lead to the fact that the project deadline will be postponed all the time, thereby creating the threat of endlessly ongoing work. If the customer sees, for example, only the results, but has no idea about the efforts required to achieve them, he will constantly demand improvements.

The second drawback is the need to adapt project documentation to changing project conditions. If the team is not properly informed about changes or additional features , functional requirements or architecture documents may not be up to date at the current time.

The third significant disadvantage of Agile is the need for frequent meetings. They, of course, help to increase work efficiency, but still, the constant distraction of team members can negatively affect the process, because people's attention systematically moves away from the tasks being solved.

This also includes such things as the need for the constant presence of the client, the inability to build long-term plans and the need for motivated and highly qualified specialists. By the way, the latter applies to a large extent to the implementation of Agile management in the organization's activities. And, comprehending Agile, you also need to get acquainted with the topic of its implementation.

Agile Implementation

There are quite a few examples of the implementation of Agile in the work of companies. And almost all of them say that it requires a whole range of important measures.

To begin with, a specific method is selected, which depends on the conditions of the project. Then the tasks and goals, the main deadline and sprint dates, the size of the team and other components of the work on the project are determined. It is important to choose a method that meets the maximum number of requirements.

As we said, Agile implementation requires a team of professionals. All its members must know the basic ideas and principles of the methodology and be able to apply them. If the company does not have such people, employees need to be trained. The management of a company that has decided to switch to Agile must also clearly understand whether the organization is ready for change, whether the system can be applied to its projects, etc. Most often, to answer these questions, you have to turn to Agile specialists.

At the next stage, a person with experience in working with the system is invited. He demonstrates it, explains the essence of sprints and actions, the functions of the members of the future team, the features of interaction between them and other issues. And only after that a new team is formed, roles, tasks and responsibilities are assigned, tools for analytics, reporting, etc. are selected.

The final stage will be the first experience with Agile, i.e. first project using it. You need to understand that mistakes, shortcomings, inconsistencies, and lags are inevitable. We will have to abandon some tools and replace them with others, perhaps changing roles between people in the team. The first experience is a process of adaptation, and adaptation is two-way: the company gets used to the methodology, and the methodology adjusts to the company.

Conclusion

Summing up this review, we recall that theory and practice are two different things. New methods and technologies and their implementation are a kind of challenge to the team, and how to achieve greater efficiency is always an individual matter. Agile is not a panacea or a guarantee of success, but it allows you to set the right course and find landmarks along the way.

To implement any project, you will definitely have to change something, look for new solutions,. It is only by adapting to ever-changing working conditions and customer requirements that the right course of action can be found. And the flexible project management methodology Agile can become a faithful assistant in this matter.

Postgraduate student at Netology Maxim Pimenov talks about Agile, an agile software development methodology.

If you write a complex program without a plan, then nothing will come of it. It's like making a car: you need to pick an engine, study the market, work out the design, create a design and assemble everything on an assembly line. When you do not know what to do and in what order, then neither the machine nor the program will start.

In order for the process of creating a program to proceed correctly, programmers use methodologies. A methodology is a set of strategies and ways to create a product. There are many of them and the beginner does not know what to choose: RUP, XP, Waterfall or another set of letters.

Back to sprint. During it, the team works according to a model close to the cascade. Every new feature is designed and programmed, then tested and documented. When the sprint is completed, the team has a workable, useful, and improved version of the product.

Before the next sprint, the team plans the next push. At this stage, the customer can add tasks that were not there before. Agile encourages what is unthinkable in a waterfall: "Requirement changes are welcome, even late in development." At the end of the project, the product may be very different from what was planned at the start.

Pairs of "plan - sprint" go one after another, while the project lives.

The team does what it wants

The internal and external communications of an agile team are as democratic as possible. One of the reasons why the methodology practically does not work in Russia is that the leaders do not understand how it is possible to “dissolve the team to such an extent”. According to Agile, a team is a self-organizing unit. No one has the right to specify how she solves problems within the sprint. If they want, let them walk on their heads.

The team is a single entity that is not divided into specific people. Responsibility lies with the whole team: if they punish or encourage, then everyone at once. The main thing in the workflow is communication. The team sits in the same room without partitions and "cubes", constantly communicating with each other. Communication with the customer is also daily.

At the end of each sprint, the team discusses how to work more efficiently. This is called retrospective. The essence of Agile is not only in the constant improvement of the product, but also in the constant improvement of teamwork.

In fact, not everyone loves Agile

Agile has detractors who don't share the same enthusiasm. The main problem of the methodology is chaos at a distance. After each sprint, priorities change and new tasks appear, so the team does not have a vision for the final product.

Two weeks ago, the customer wanted an online store, but now he realized that it would be a social network for individual entrepreneurs. The team accepts chat and likes in tasks for the sprint. The next time a customer sees that a new James Bond movie has taken the internet by storm. It adds online movie theater features to the sprint. As a result, the project architecture is sprawling, and the useful action of the product becomes blurred.

Another problem is bad code. Agile preaches the maximum number of useful product changes per unit of time. Since the goal is beneficial changes, programmers have no job to make the code as robust and understandable as possible.

Agile encourages the thought that the fact that a feature works is much more important than how it is implemented. At a distance, this approach leads to problems. The only insurance is a super-disciplined and organized team.

If you forget about philosophy, nothing will come of it

There is another problem in which the authors of Agile are not to blame: the methodology has become too popular and even poppy. People say that they work according to Agile without even understanding its essence. They break into small teams, cut the project into small tasks, plan sprints, release regularly, but there are no fewer poor projects.

Remember, at the beginning of the article, I talked about principles? Despite their naivety, principles are the most valuable thing in Agile. First you need to realize them and only then take up the tools and practices.

People and interaction are more important than processes and tools.

A working product is more important than comprehensive documentation.

Cooperation with the customer is more important than agreeing on the terms of the contract.

Being ready for change is more important than sticking to the original plan.

People mindlessly follow instructions, forgetting that Agile is an ideology and a philosophy. And we must not forget: if you do not imbue the spirit of the methodology, a "waterfall" will break through it in half with anarchy and bureaucracy.

Agile is a mindset, not a set of tips. Embrace Agile before you start practicing.

Agile (“agile”) is a word that has been heard from every iron lately. But what is Agile and, most importantly, why is this Agile needed?

If you open an explanatory dictionary, for example, Oxford, you can read at least two definitions there:

Able to move quickly and easily.
Able to think and understand quickly.

That is, to be agile, you must be able to move quickly and easily and think quickly. Seems to be quite useful qualities, especially in business. Thinking fast and reacting quickly is exactly what the doctor ordered for our time, otherwise you simply won’t survive: competitors will devour you. There are fewer and fewer industries in the world where these competitors do not exist. Moreover, the speed of copying makes it practically impossible to bring the product to the market and rest on its laurels. Without the ability to quickly adapt to change, which gives the so-called "Agile methodology", it is increasingly difficult to survive.

It is not by chance that I take the expression “Agile methodology” in quotation marks, because you can often hear it, but it is not entirely correct. If you do not go into technical details, then Agile is not a methodology, but a collective name for various methods and approaches to management that:

Focus the team on the needs and goals of the clients.
Simplify organizational structure and processes.
They offer work in short cycles.
Actively use feedback.
There is an increase in the powers of employees.
They are based on a humanistic approach.
They are not an end state, but rather a way of thinking and living.

Nothing supernatural, right? Let's go point by point and see why the above is important in order to be fast and agile, and how Agile achieves these goals.

Focus on customer needs and goals

I think it is not worth explaining why the most successful business is the one that satisfies the needs of its client better than competitors. It is more interesting to understand what tools in Agile help to achieve this.

Most importantly, the focus on the client with the Agile approach appears not only in the head of the business owner (it already exists there), but in everyone who is working on creating a product or service. Each participant in the process must understand who the client is, what he wants, what problems we solve with our product, what he loves, what he fears, and so on. Such a global focus allows you to create an order of magnitude better solutions. I have repeatedly come across a situation where people who were previously responsible for some small piece of work, having understood the goals of the client, began to give out wonderful ideas, and the people who are responsible for product development took notes with surprise. Or - how in group sessions of product development, such ideas are honed by different people and complement each other, turning from just good ones into excellent ones. And, of course, how they are then implemented.

“Tools of work” in this case are short, but intense sessions (meetings) of all participants in the work or the key majority, where various ideas are generated and tested. These same meetings serve to level understanding and focus: all participants in the exit meeting understand what they are doing, why, and why it is important for the client. And the democratic format of the workshop, unlike boring presentations, guarantees greater inclusion and motivation of all participants.

Examples of such tools are Lean Canvas, Impact Mapping, User Story Mapping and other Agile methods for describing hypotheses and processes.

One of the cornerstones of Agile is extreme simplicity. And the organizational structure of the organization, and the processes by which people work, and the rules should be as simple as possible. This will allow people to focus on their work, on the value they create, and not on compliance with regulations and rules. Great examples of this approach can be found in many teams working on Scrum, the most popular way of organizing workflow in Agile. In fact, all the agreements and rules of a team of 10-11 people, current tasks for a couple of weeks, goals, as well as strategic plans can easily fit on 2-3 sheets of A0 paper. On one sheet there can be a so-called “sprint backlog”, a list of everything that the team is going to do in the next iteration. If you hang one in the room where you work, you can save yourself the trouble of remembering all this. The same goes for processes. For example, in Scrum, the place and time of all meetings are rigidly fixed. Any participant knows for sure that, for example, on Monday at 10-00 the next iteration is planned, and on Friday at 17-30 - a meeting to improve the work process.

And the larger the organization, the greater the value of this simplicity, because complexity has a habit of growing exponentially, and Agile is a good way to defeat this complexity, or at least contain its growth.

Examples of simplification (and flattening, but this is a topic for another discussion) in Agile are Scrum, Nexus, LeSS (Large-Scale Scrum, or Scrum on a large scale), as well as the Agile manifest itself.

In the Agile world, it's not customary to lock yourself in a workshop for three years to sharpen something interesting there. The risk is very great, to spend a sea of \u200b\u200bforce and time on something that no one needs or is outdated.

To avoid this, the so-called iterative-incremental approach is used, when:

work is carried out in small fixed periods of time, for example, in one, two or four weeks,
and, most importantly, at the end of each period of time, not just some kind of intermediate result is created, but, albeit a small, truncated, scanty, but workable version of the product , which you can already start using .

As the simplest example of such a working model, we can imagine the “calculator” program standard for all computers, which at first only allows you to add two numbers, then we add subtraction, multiplication, division, transcendental numbers, trigonometric functions, and so on, in order of frequency of use. At the beginning, the functionality is small, but we can already see how the calculator looks, how convenient it is to use, and imagine how to develop it further. And, most importantly, some customers (say, primary school students) can already start using it.

Another advantage of this approach, in addition to early entry into the market and making changes in the early stages of work, is the ability to measure progress more accurately. We didn't just "done 15% of the work", which is pretty abstract. We "made 15% of the functionality" that is already working.

All process approaches in Agile have short cycles, be it the previously mentioned Scrum, Nexus, LeSS, SAFe or , plus the need to work with such cycles is mentioned in the Agile manifest itself.

Active, systemic use of feedback

This point, in my opinion, is the most important for any process, as it allows you to adjust your work over time, based on experience, removing errors and losses from the process and the product being created and adding something useful.

In any field of human activity related to the creation of something new, you will find a similar work through the experiment . Rocketry, aircraft engineering, pharmaceuticals, physics, medicine, construction, psychology, economics - any field of activity began with experiments and thoughtful processing of feedback from them.

Agile offers a systematic use of this approach everywhere: in creating a product (we release it on the market, or show it to the customer, or conduct tests and use feedback to correct it), in building processes (periodically we “stop” work and analyze the process itself, to improve it, get rid of losses and problems), even in building the structure of the organization and fine-tuning relationships in teams.

Again, examples are everywhere: retrospective meetings in Scrum, Kanban, Nexus and LeSS, I&A cycles in SAFe, Design Thinking approach to creating products, etc.

Why give more authority when you can give a piece of paper with instructions? There are at least three reasons to do this.

Firstly, people engaged in mental work do not like to feel like monkeys (well, or robots), and by taking away the ability to make decisions from a person, we take away mental work from him in itself. And that is definitely demotivating.

Secondly, by giving more authority, we give more responsibility, and people are forced to learn to make decisions on their own and, most importantly, to bear responsibility for them. It's long, hard, but worth it. The work will not stop if a self-organized team encounters an unfamiliar, previously unknown problem. And who will argue that at work, mature and responsible adults are more useful than big children who are unable to think for themselves?

Thirdly, it's still the same speed. If a person can solve a problem himself, in his place, without asking anyone, this reduces the time for making decisions. No more sending the question "up" and waiting for a response from management. This advantage is not so noticeable if you have 3 people working, but if you have 30, or 300, or 3000 ... In large organizations built on purely hierarchical decision making, paralysis of will can be quite common.

Popular ways of building work in Agile, especially those based on the Scrum framework, involve a system of self-organized teams and encourage leadership at all levels.

Why treat people like human beings? That is, the moral side of the matter is clear, but what benefit will it bring to the owner of the enterprise?

The answer is pretty simple. If the creation of what you are selling does not require mental labor, but only mechanical actions, you can not bother. Just pay according to the work done, and that's it. But as soon as the brain of workers comes into play, you will have to reckon with the principles of motivating mental work. And they say that the possibility of self-realization, improvement of their skills, bringing something valuable into the world, independence in decisions and a number of other factors are important for people. And a motivated person (not to be confused with a stimulated person!) will invest more in the work, and the result will be better and faster. And in general, a pleasant atmosphere at work adds to the desire to come and work there - hardly anyone can argue with this either.

And, what is nice, if you dig into the same Scrum, it turns out that all the key factors for motivating a worker of mental and / or creative work are already included in it. In each iteration (“sprint”), we set a goal that we want to achieve; we are given the opportunity to decide how exactly to achieve the goal; at the end, we look at how much we have become better (or worse) to work than before; we see people who are interested in the product and their emotions from getting to know it. It is especially good if these emotions are positive.

The conclusion is: happy people work better, and Agile technologies help to establish a process in which people feel happier. And the first point of the manifesto is just about this: people and how they communicate are more important than anything else.

Agile is not an end state, but a way of thinking and living

This point is about how Agile in general is the path, not the goal. You can’t “implement” Agile and relax. If you choose this path, you will always have something else to do better, some other challenge to answer, some other problem to solve, another height to conquer... This is movement. endlessly, because there is no ideal process or product, development and competition never stop, just as the struggle for survival in nature never stops.

And if everything was successful: people in the company understand and share the values and principles of Agile and work according to them, then the management will not have to “drag” any changes or “kick” employees so that they start doing something differently.
The enterprise will become a single organism, the management of which will take less effort and bring more pleasure. And where there is more pleasure from work, and the result is higher. This applies not only to specialists, but also to management, and to an even greater extent.

It is difficult to find a person who would not want to be treated with respect. But there must be a reason for this state of affairs. For example, when a person is a highly qualified recognized specialist in the field of software development. And for this you need to study. And within the framework of this article, we will consider what Agile is, what is the use of it, and how to understand this technology.

general information

First, let's deal with the technical issues. What is Agile? The translation (literal) of this word from English is “living, mobile”, “flexible” is mentioned a little less often. And by the way, it's an abbreviation. The full name of this approach is Agile software development. But since it is too long, it was decided to cut it. And now they just say Agile. Translation as "flexible" is used due to the fact that it most closely matches the real situation.

What is included here?

We continue to consider what Agile is. Here I want to focus on the fact that this is a flexible approach, which is based on many different XP, "Kanban", Lean). In order to better understand the topic, let's draw parallels. Let's say that Agile technologies are the process of the birth of the Universe. The final product is the actual world itself. And the big bang is the most painful problem you have to face - changing the list of product requirements. Typically, creation processes involve the use of a waterfall model. In this case, everything goes sequentially and step by step. This approach can be expressed briefly: I see the goal - I go to it. And if the requirements for the final result change, then sometimes you have to redo almost everything anew. What further complicates this situation is the attempt to pretend that everything is fine and that we need to move forward.

And here is the management, designed to deal with all this thanks to its flexibility. This hodgepodge minimizes various risks through the use of sets of principles. All of them are reflected in the Agile Manifesto, released in 2001. Briefly, they sound like this:

The main thing is people, not things.
Collaborate, don't read the contract.
Documentation should not interfere with work.
Change as quickly as possible.

It may seem too vague and not accurate, but let's detail.

Process design

Considering what Agile is, let's turn to one of the most popular methodologies known as "Scrum" (Scrum). What does she offer? To get started you need:

Select a product owner. This role is suitable for a person who sees what goal you need to go to, and what will happen in the end.
Decide on a team. This requires a group of three to ten people who have the skills to get results.
Choose a responsible person. This is a person who will monitor the development of the project and help the team get around difficulties.
Deal with difficulties. All existing product requirements should be collected in one place and prioritized. The product owner should collect all his wishes here. Then the team evaluates them and understands whether it can be implemented, and how much time is needed for this.
You should break the entire scope of work into periods of time, a week or two long, during which the team will perform certain sets of tasks.
Meetings should be held daily, no longer than fifteen minutes. The agenda should discuss what was done yesterday, what are the plans for today, and the obstacles that prevent us from taking the height.
Make reviews at the end of the week (two), during which the team talks about what has been done. At the same time, it is necessary to demonstrate the performance of parts of the product.
After each time period, problems should be discussed and solutions sought. Moreover, all developments must be implemented immediately.

How to recognize Agile?

The management methodology, regardless of the chosen direction, always has the following features:

Risk minimization. This is the main goal pursued by any flexible approach.
Iterative development. In this case, work in small cycles is implied.
The most important thing is people and communication between them.

Let's imagine a river. On one side of the customer. The second is the team. In this case, agile development methodology has advantages for everyone:

The customer wants a minimum viable product. At the same time, conditions may change during its creation.
It is useful for the team to communicate with colleagues and the customer. In this case, the risk of being misunderstood is minimized, the transparency of processes is increased, problems are quickly resolved, and the chances that there will be a surprise when creating a product are reduced.

social factor

When talking about what Agile is, they usually talk only about positive things. Indeed, communication within the team is improving. All people focus on one idea, do not create secrets among themselves, make commitments. As a result, the team works in comfortable conditions and at a fast pace. This approach allows you to streamline the chaos.

Since its formation, it has been able to find recognition in the technology industries. At the moment it is widely used for designing new software products. But in general business practice, this approach is still little known. Therefore, those who have not met Agile before are cautious about it. It should also be understood that it should be used only in cases where people are faced with the task of intellectual labor.

Small example

Let's take a look at how these software development methodologies work. Let's say we have Peter, the owner of the product. He does not know the technical details, but he has a vision of the big picture. He knows why the product is needed, what problems it will solve, and whom it will satisfy. There are also interested parties. They can use the product, support its creation, or otherwise be involved in its creation. You can also add user stories that express the wishes of interested parties. For example: the system for booking tickets for regular buses Moscow-St. Petersburg should have a search for flights. Peter will help interested persons. It will take control of the implementation from user story ideas. There is also a development team. These are the people who will build the working system.

Since the development methodology is agile, user stories are not accumulated until a big release, but are released immediately after completion and as often as possible. The number of requests processed is the team's weekly throughput. In order not to lose momentum and get bogged down in manual testing, the team should work on automated integration. What is it? An automatic test is written for each working moment. If there are too many stories, then there can be rush, loss of motivation, loss of productivity and quality. For such cases, the method "yesterday's weather" is provided. It lies in the fact that you need to set strict limits on the amount of work and carefully choose what exactly will be implemented. The previously mentioned "Kanban" suggests setting a task limit.

What to do with the queue?

Okay, so the team decided that they could process four stories a week. But how to navigate in everything that is? Let's say users upload ten stories a week. Four are being processed. Thus, the queue will constantly grow. In this case, there is only one effective method - the word "no". For the product owner, this is extremely important. Saying "yes" is not difficult. It is much more difficult and more important to decide what not to do. Moreover, it is also necessary to bear responsibility for this. Therefore, it is necessary to decide what to pay attention to now, and what should be postponed. To get it right, the product owner needs to understand the value and scope of each story.

We make decisions

Some of the stories are extremely necessary. Others are just a nice bonus. Some stories will take several hours to develop. Others will take months to complete. Many often draw a correlation between the size of a story and its value. But this is not always correct. More is not the same as better. The complexity and value of the task at hand helps Peter to prioritize correctly. How can these characteristics be quantified? No way. This is a real guessing game. And for greater effectiveness, it is necessary to involve a lot of people in it. This is the development team, which will inform about the scope of work, and interested parties. But it should be understood that all data obtained in this way are approximate guesses. There are no exact numbers here. Initially, there will be misses. But as you gain experience, their number and scale will decrease.

Possible risks

To avoid problems, it is necessary to give honest answers to a number of questions. This:

Are we doing the right things? This is a business risk.
Can we implement what we need?
Will the project work on this platform. This is a technical risk.
Is there enough money, and will we have time? These are risks of terms of implementation and cost.

In this case, knowledge is required. They can be seen as opposites of risks. When a significant level of uncertainty is fixed, then we acquire knowledge - for example, we create interface prototypes or technical experiments. And already possessing them, we make decisions about the direction in which we should move.

How to learn?

The IT industry is developing extremely rapidly, and in order not to lose in the end, it is necessary to constantly learn, improve skills and work efficiency. Therefore, the issues of training and implementation are more relevant than ever. Where to begin? The best option is to cooperate with a company that already uses Agile. The training in this case will be conducted by people who know not by hearsay what agile development is. But, alas, this is not always possible. Most often, a third-party specialist is involved who knows what Agile is. The implementation of this approach is carried out under his supervision. True, the services of such a specialist cost money. But if you get a really knowledgeable person, then all the expenses will pay off handsomely. Indeed, in the modern world, the efficiency of employees plays an important role.

What's in store for the future?

Software development methodologies are constantly evolving. Looking for new ways and opportunities to improve the efficiency of activities and work. It is rather problematic to say what the future holds for us. Probably, the flexible development system will be integrated with the automation of production processes. For example, it will be possible to solve problems even while being at a distance from the location of the company. In many ways, the future is determined by new information technologies . After all, when they arise, you need to master new methods of working with them. And in this case there is a development closed in a cycle.

Finally

So the excursion into flexible ones ended. But it should be recalled that theory is one thing, and practice is quite another. New information technologies that are constantly emerging are challenging the large developer community. How can you make your team more efficient? Everyone finds the answer to this question himself. The information presented here can be used to form the backbone. But in practice, you will have to work with the existing model and bring the state of affairs to a state of compliance with existing challenges. Then the team will be able to effectively fulfill its goals.