agile tools. What is an Agile approach and why does a business need it? Agile methodologies versus traditional project management approach

To start. Scrum and Agile - what's the difference? In short, Agile is a philosophy, a family of flexible approaches to software development. Scrum is one such approach. He has a brother - Kanban. It is also the approach used in Agile.

Elena Truskova says:

This week, I took a two-day Agile/Scrum training (pronounced "agile" and "scrum"). Agile development methodologies software written a lot of abstruse and not very literature, I read a lot. But only after two days of immersion in the topic did I finally have a basic understanding of the subject from which I am writing this note.

Agile and Scrum help organize the process of teamwork in such a way as to release a product that is interesting to the user regularly and often.

In some banks, thanks to agile, the path of an idea to users was reduced from two years to six months - in other companies, a six-month development cycle was compressed into three. In our hectic times, it's true competitive advantage especially for small players.

Scrum principles can be applied to absolutely everything: for example, to work on a creative product. This, of course, is not “canonical agile”, Scrum evangelists will grind their teeth, but your processes will move more cheerfully. Checkers or go?

Some of Agile and Scrum can even be taken into individual work. Ensure regular publication of posts, measure the load on the performer, evaluate future tasks in terms of time and do not forget to analyze the quality of the work done - look, everything has already been thought of for us. It remains to implement.

Agile

(English agile - "agile, smart, quick-witted")

Flexibility concept:

Substitute your type of activity instead of the word "development" - and these principles will become close and understandable.

“A working product is the main indicator of progress”, “simplicity as the art of minimizing unnecessary work” and “people and interaction are more important than processes and tools” - does it sound reasonable?

Scrum

(eng. scrum - crush in the fight for the ball in rugby)

It is worth recalling here that this is my personal and subjective point of view on Scrum. Here I reflect on the applicability of Scrum elements as in creative projects, far from IT, and in individual work (say, on a blog). Many precise details for this will have to be omitted; I try to keep the text simple and not overfeed the reader with terminology.

The rigidity of Scrum lies in the structure. There is a certain set of approaches that work better together than separately. Pull something out and use it for you, I hope no one forbids.

Scrum usually occurs where there is a certain product that has value for users and customers, and you need to understand as quickly as possible on the way to the goal whether we are running in the right direction or if we need to correct the course. The Scrum format allows you to release the next version more often, receive regular feedback and quickly refine the product, as well as improve the work process.

If you work in a team, Scrum requires all participants in the process to strive for interchangeability, the ability to “pick up” a sagging task if a neighbor is sick, the exchange of skills and collective responsibility for the product. There is little individualism in Scrum. Decisions are made collectively (according to strict principles), no one can pressure and force them to choose another solution if the team is sure that they have settled on the right one.

Having such confidence in Scrum is not scary, since each march lasts exactly one sprint (a clear period of time, usually from one to four weeks). After the sprint is over, there comes a moment of analysis: how did we get through it? What could be done even better next time?

Therefore, even if we all confidently ran in the wrong direction, we will have at the end of the sprint the opportunity to correct it and fix what is leading us in the wrong direction. The team in Scrum is self-organizing and self-tuning.

Team in Scrum

The standard size of a Scrum team is 7 plus or minus 2 people. That is five to nine. There is scrum scaling: you can build a system of work on a giant task out of 25 teams. But the basic unit of Scrum is the team.

Each team has:

• participants (in the case of IT - developers, who are these seven people you have - decide for yourself)
• product owner (product owner, product owner). His role: to understand the market and the user, to formulate tasks in the language of business and users, to keep in mind the awareness of the direction in which value and benefit should develop, to invent and select tasks for product development. Something like a product (not a team) leader.
• scrum master (scrum master, scrum evangelist). His role: follow the process, observe the inner life of the team, motivate people, remove obstacles. Kind of like a coach.
  Around the team there are users and stake-cholers (stakeholders, customers). The product owner goes to these people for advice.

Device sprint

Scrum work consists of sprints. All sprints are set up the same way. It is assumed that with each next sprint, the team becomes more cooperative and efficient. In Scrum, you learn from your mistakes, but quickly - every sprint you analyze what exactly you did and how you want to fix it.

The product owner has a list of business ideas to keep users happy. It's called a "product backlog" (a list of product ideas). In it, ideas are sorted by importance and significance.

Each sprint has a sprint backlog (sprint backlog, list of tasks for a sprint) - a sorted list of ideas that the team decided to do in the next sprint. The meaning of Scrum is that the team itself evaluates the complexity of each task and decides which tasks will be included in the next sprint.

The task in the sprint has a weight known to the team (it is known how long it will take), a performer is attached to it, it is understandable and important. If you don’t know how long a task will take, you need to break it down into smaller parts.

At the beginning of their life, the team always plans badly. This is an objective reality. But she keeps statistics of what she manages to do in a sprint, and plans more accurately over time. She is helped by the final meeting of the sprint - a retrospective. There you can discuss the weak points of the outgoing sprint and come up with ways to do it differently.

Usually 5 plus or minus 2 ideas fit into a sprint. If the ideas are too big, the team splits them up so that in each sprint there is something small to show.

In Scrum, ideas are called user stories (user stories, stories about users) and are formulated as follows: “I like (role?) want (what?) in order to (why?)”. Thus, the team sees not only the functionality, but also the meaning of its creation, and for a specific role: user, customer, buyer.

The result of a sprint is always something to show. Shows the work of the team on the demo at the end of the sprint.

In my opinion, the Scrum process is similar to working on a team blog. Such a process would help maintain regularity, bring together the expertise of the authors and not recruit so much that you can’t do it.

Sprint Structure

The sprint begins with planning: the team sits down and discusses: we take this idea, we don’t take that one. In IT, this process can drag on for a couple of hours, because the discussion goes down to the details. In the case of working with a blog, this can turn into a discussion of topics and a plan of articles, which you then have to sit down and write - understanding what we write, when and why.

Every day there is a stand-up meeting (stand up meeting, standing meeting) for 15 minutes. It is important to do it while standing: if someone talks, the rest will eloquently shift from foot to foot and scratch their ear. You can use some object so that only one participant speaks at a time, and pass it around in a circle.

Each stand-up participant takes turns answering three questions:

• what i did yesterday
• what will i do today
• what slows me down

All the detailed conversations that are tied up in the process go beyond the limits of stand-up. Stand-up is a point at which you can catch problems or find out that for some reason a colleague and I are doing the same thing at the same time, which means that one of us can do something else.

In general, the maintenance of all these clear rules of behavior should be handled by the Scrum Master. These are usually the ideologues of technology, who believe in it and are ready to build a process for the maximum efficiency of the time spent together. Without a Scrum Master, processes will degenerate into the minimum possible, because a person is lazy and economical.

At the end of the sprint, there is a demo (demo, demonstration) showing what we managed to create during the sprint, a sprint review (sprint review, sprint review) with a revision of the product backlog and talking about WHAT we do, as well as a retrospective (retro ) - what we did not do the best way the whole sprint and want to improve further - about HOW we do it.

“If I had eight hours to chop down a tree, I would spend six hours sharpening an axe.” (Attributed to lumberjack and President Abraham Lincoln)

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 development method appeared dynamic systems DSDM
• 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

Manifesto, created by programmers, includes 4 basic ideas and 12 principles effective management projects. 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.

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

Agile principles:

1. Satisfy customers by delivering software early and consistently (customers are happy when working software arrives regularly and at regular intervals)
2. Change the requirements for the final product throughout the development cycle
3. Deliver working software as often as possible (once a week, every two weeks, a month, etc.)
4. Maintain collaboration between developers and the customer throughout the development cycle
5. 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)
6. Provide direct interaction between developers (the possibility of direct contact contributes to more successful communication)
7. Measure progress through working software only (customers should only receive functional and working software)
8. Maintain a continuous pace of work (the team must develop an optimal and sustained work rate)
9. 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)
10. Try to make the workflow as simple as possible, and the software - simple and understandable
11. 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)
12. 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 helps to create a healthy atmosphere for fruitful and effective cooperation and faster 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 Agile methodology is the division of the entire scope of the project into several smaller ones. constituent parts. 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:

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

Currently, Agile-supported project management is mostly distributed in the IT field, however, business area starts to learn 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 J).

These and many other organizations use a wide variety of Agile 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 methods of project management that are used by different 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 specialists who first described it strategic management Hirotaka Takuechi and science and technology professor Ikujiro Nonaka call the method the "rugby approach", where Scrum is "fighting 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 is to give the development process maximum transparency and uniform distribution workload among 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, in the final product, the number of defects 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, documents with functional requirements or architecture may not be up to date on this moment 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.

On the next step a person who has experience 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 flexible management methodology Agile projects can become a faithful assistant in this matter.

• Translation

"Any case always takes longer than expected, even if you take into account Hofstadter's law."
- Hofstadter's law

Most viewed agile YouTube video. 744,625 views at the time of this article's publication. Light style of presentation, pictures and only 15 minutes - the best I've seen. TED is resting.

Roles

This is Pat product owner. She does not know the technical details, but she has a vision of the big picture, she knows why we make a product, what problems it will solve and for whom.

it interested persons. They will use the product, support it, or be otherwise involved in development.

it user stories. They express the wishes of interested parties. For example, "the system for booking airline tickets, the user must have a search for flights."

Stakeholders have a lot of ideas, and Pat helps turn those ideas into user stories.

it development team. Those who will build working system.

Bandwidth

Since the command uses agile development methodology, they don't hoard all these stories for a big release, on the contrary, they release them all at once and as often as possible. They usually release 4-6 user stories per week. It's theirs throughput . It is very easy to measure - the number of user stories in 7 days.

In order to maintain this rhythm and not get bogged down in manual regression testing, the team is working hard on automatic testing and ongoing integration. Therefore, you have to write autotests for each feature, and most of the code has built-in autotests.

The problem is that there are a lot of interested parties and their requests cannot be satisfied with 4-6 stories per week.

Every time we implement a user story, they come up with a few more ideas, from which even more requests flow.

What happens if we do everything they ask us to do? We will be overloaded.

Let's say the team undertakes to make 10 new stories this week. If the input is 10 and the output is 4-6, then the team will be overloaded. Will be in a hurry, switch between tasks, lose motivation, as a result, productivity and quality will decrease. This is a clearly losing strategy.

Scrum and XP use the “yesterday weather” method in this case. The team says: “Lately we have been doing 4-6 features per week, what 4-6 features will we be doing next week?”

The task of the product owner is to wisely choose which user stories will be implemented this week.

Kanban recommends limiting yourself to a few tasks - WIP limit. Let's say the team decides that 5 is an acceptable number of user stories that they can work on simultaneously without being overwhelmed, without jumping from one to another.

Both of these approaches work well and they both create a queue of tasks, which in Scrum is called Backlog, or a prioritized list of tasks.

This queue also needs to be managed. If stakeholders request 10 stories per week, and the team implements 4-6 stories, then this queue will get bigger and bigger. And soon your Backlog will be scheduled for six months ahead. That is, one story will wait for the release of 6 months.

There's only one way to keep your to-do list under control and that's the word "no"

This is the most important word for a product owner. He has to train it every day in front of the mirror.

Saying yes is easy. But the more important task is decide what not to do and take responsibility for it. The product owner also determines the sequence of what we do now and what we do later. This is a complex job and should be done together with the development team and at least one stakeholder.

In order to properly prioritize, the product owner must understand the value of each story and its scope.

Making decisions

Some stories are essential, and some are just bonus features. Some stories will take a couple of hours to develop, others will take months to develop.

How does the size of a story compare with its value? No way. More doesn't mean better. The value and complexity of the task is what helps Pat prioritize.

How does the product owner determine the value and scope of a story? No way. This is a guessing game. And it is better for everyone to participate in it. Pat constantly communicates with stakeholders to know the value of each story, communicates with the development team to know the scope of work, but these are all rough guesses, no exact numbers. There will always be misses in the beginning, and that's okay. Communication is much more valuable than super-accurate numbers.

Every time the developers release something new, we learn more information and can better navigate.

Prioritization alone is not enough. To release stories quickly and often, you need to break into pieces that can be done in a couple of days. We want small and clear stories at the beginning of the funnel and large and vague stories at the end. By doing this breakdown in time, we can take advantage of our latest discoveries regarding the product and user needs. This is all called clearing the Backlog.

Pat hosts a backlog cleanup meeting every Wednesday from 11 am to 12 pm. It usually brings together the entire team and sometimes a few stakeholders. The content of the meetings varies. Focus on evaluation, breakdown of stories, acceptance criteria.

The owner of an IT product must constantly communicate with everyone

Seasoned product owners identify 2 components of success: passion for work and communication. What tasks does the product owner solve with the team.

Balance between development complexity and user story value

At an early stage, the balance sheet is threatened by uncertainty and several risks at once.

Risks

Business risk: "Are we doing the right thing?"

Social risk: “Can we do what needs to be done?”

Technical risk: "Will the project work on this platform?"

Risks with cost and timing of implementation: “Will we succeed and will there be enough money?”

Knowledge can be seen as the opposite of risk. When uncertainty is large, we focus on knowledge acquisition - interface prototypes, technical experiments,

Trade-off between values ​​of knowledge and values ​​for the client

From the customer's point of view, the curve looks like this:

In terms of customer value, this curve looks like this. As uncertainties decrease, we can focus on customer value. We know what and how to do. It remains only to do. After we have implemented the main stories, we will make bonus features or launch a new project.

Trade-off between short-term and long-term thinking

What to implement first? It is urgent to fix bugs or start developing a stunning feature that will amaze users. Or do a complex platform upgrade that will speed up work in the future. There is a constant balance to be struck between reactive and proactive work.

Do the right things, do things right, or do things fast?

Ideally, all three at the same time, but in reality you have to choose.

Let's assume we're here. Trying to create the perfect product with the perfect architecture. If we spend a lot of time, we may not get into the "marketing window" and we will have problems with money.

We make a quick product prototype. For the short term, this is good. In the long run, we get technical risk. And the development speed will drop to zero.

We're here building a beautiful temple in record time. But the user didn't want a temple, they wanted a camper van.

There is a healthy opposition between roles in Scrum.

The Product Owner focuses on building the right things. The team focuses on building things the right way. The Scrum Master or Agile Trainer focuses on reducing the feedback loop.

Separately, it is worth emphasizing the importance of speed, since a short feedback loop speeds up learning. This allows us to quickly learn what things are right and how to build them right.

Trade-off between developing a new product and improving an old one

A product can never be fully completed because it constantly needs changes. When a team starts working on a new product, what happens to the old one? Transferring a product from one team to another is very costly and risky. Usually the team supports the old product while developing the new one. Therefore, rather, the concept of “Backlog” refers not to the product, but to the team. The backlog is a list of things the product owner wants from the team. And a set of stories for different products. The product owner needs to constantly choose relevant ones for implementation.

History destruction schedule

From time to time, stakeholders will ask Pat: “When will my feature be released?” or “How many features will be released by Christmas?”. The product owner must be able to manage user expectations. And manage expectations realistically.

Two trends - optimistic and pessimistic (you can see it by eye). The distance between the trends shows how unstable the speed of the team is. Over time, these trends will stabilize and the cone of uncertainty will decrease.

Suppose a stakeholder asks when this feature will be made?

This is a matter with a fixed content and an indefinite time frame. Pat uses two trend lines to answer. The answer is April or May.

A stakeholder asks Pat, "How much will be done by Christmas?" This is a question with a fixed term and indefinite content. Trend lines cut off on a vertical scale a probable segment of what will be realized in time.

A stakeholder asks, “Will we be able to make these features by Christmas?” This is a fixed time frame and fixed content issue. Focusing on trends, Pat replies, “No.” Adding: "We'll have so much done by Christmas, but this is how long it will take us to complete all this work completely."

It is usually better to reduce the content of a project than to increase the time. If we reduce the content, we will have the opportunity to push back the deadlines. We may release some here and the rest later.

The product owner makes calculations weekly and uses only empirical data, and does not wishful thinking. He talks honestly about uncertainty. The team maintains the pace of work, and Pat does not pressure them, forcing them to speed up.

We explain what the underlying methodology is, reveal the main concepts, explain how an agile team works and how its effectiveness is measured.

Agile is a whole family of agile project management methodologies. Interestingly, the concept of control itself is not quite correct here. It would be more accurate to use the formula "Agile is a way of team collaboration that allows you to jointly create products." However, we are too accustomed to the power of vertical, hierarchical connections, so the use of the word “management” has become stable here too.

uncomfortable questions

• How to make sure that the delay in the work of one department does not stop the rest?
• How to cope with the fact that the development of a project plan does not take up to 30% of the time of the entire scope of its implementation?
• How, in the end, to ensure that these plans are respected?

Managers of different levels, from low-level managers to corporate directors and government officials, have been wrestling with this for decades. But as long as the only known way of more or less controlled creation of products and development of projects was step by step, one by one, nothing could be done about these challenges.

In order to move to a qualitatively new level design work required a fundamental paradigm shift.

It turned out that there is simply no need to look for answers to most of these painful questions. They need to be removed, and the concepts that gave rise to them, if possible, should be abolished. So, in place of the phased waterfall development, flexible methodologies arose.

Do it right away!

The main measure of effectiveness adopted in the agile methodology is the product. While others are only preparing the documentation, agile teams strive to provide a workable prototype. It's like the famous motivating formula "done is better than perfect." Implement the first function and start testing it while creating the next one over and over again - this is the main rule.

The development stage in Agile, this is the most “time after time”, is called iteration. Iterations have the same duration throughout the project and average two weeks. Within a separate iteration, a specific task is performed, the main property of which is that its solution must update the product to new version or increase its effectiveness. It is on this basis that such tasks are selected.

How does an iterative approach provide flexibility? Thanks to separate processes can run in parallel and independently of each other. Yes, it must be admitted that this can increase the deadline for development from an idea to a fully finished product. But the fact of the matter is that a product that is working, functional and already able to meet competitors and please users is created in Agile much earlier, and the cyclical improvements allow us to achieve a much better study of such functions and features that would not have been reached during planned work. never.

Horizontal organization

An agile team is built on the principles of self-organization and the relative equality of all participants. Even the person whom many people think of as the head of the project, the product owner, is really just a personification of the requirements for the product. He plays the role of a carrier of knowledge about how the end result is expected, but is by no means a manager in the standard sense. Since the habit of hierarchy is difficult to eradicate, in many teams, the product owner, alas, has to take on control functions as well. But the ideal of agile development is collective responsibility team members in front of each other.

The principles of forming agile teams vary depending on the specific project. For example, in the Spotify music service, they are built like this:

Another important value of agile teams is knowledge sharing. A team member should not be locked into his narrow field, he should strive for cross-disciplinarity. This does not mean that a programmer should also be a seller, and a designer should be a marketer.

But to have basic knowledge about related specializations in agile development is necessary.

Initially, it was assumed that this would simply increase the efficiency of work and the level of mutual understanding in the team, but today, with the development of neuroscience, it has become clear that this approach, in addition, maintains the brain in good shape and dynamically creates new neural connections. This cross-pollination of knowledge in Agile is called t-shape. The illustration below will explain why this is so, better than any words.

How to implement Agile?

The transition from waterfall development, which is still familiar to many organizations, to agile project methods can be quite painful.

Firstly, you have to abolish hierarchy and at the same time ensure that all participants in the processes can equally share responsibility for the result.

Secondly, the transition to iterative development will force you to focus on ensuring that each of the stages is guaranteed to bring something new to the product. It's not easy, the inertia of planned development will haunt you for the first few months.

The Toyota plant system has already become a classic and successful management model. Each employee of the enterprise had the opportunity to stop the conveyor at any time in order to eliminate a defect, malfunction or make his own rationalization proposal. It is on this approach that the Agile philosophy is based. Initially Agile methodology about 10-15 years ago was a method of developing software in small teams. At the moment, Agile methodology is a new culture for managing large enterprises. Today, any progressive manager knows what Agile is.

Products and services are created, as a rule, according to a single classical scheme. This is especially true for the IT industry. Such a scheme is called a waterfall, or iterative development methodology, and in English language- waterfall development ("waterfall"). Why is the scheme so named? The point is that if you have already approved a software product plan, you cannot suspend it or make adjustments before implementation. It has a completely different principle. Agile methodology. Waterfall is a concept that does not apply to it. This is a qualitatively new approach to product development. The methodology is based on a simple idea - each participant has the opportunity to make useful suggestions for optimizing the process, stop the conveyor in order to rethink the tasks and the common cause.

Agile methodology has a framework endowed with a number of characteristics. Among them:

• Quick response to changes.
• Independent organization production process.
• Predictability.
• The presence of continuous and constant feedback.
• Separation of risks.

In many enterprises, when developing products, specialists who solve important tasks for production are distributed among different departments, often in conflict with each other. This is especially true for employees of the operational department, developers and testers. If the products are not sold properly and receive income from this, the conflicting parties blame each other. At the same time, everyone is usually to blame in such situations.

Agile methodology - an approach that involves the presence of everyone who develops software. At the same time, each specialist does his job. Agile methodology makes it possible to see that all participants in the process are united by one goal - the creation of quality products for their customers.

When Agile methodology is applied, the whole business culture of the company changes. MBA programs contain a full-fledged course on the organizational structure of an enterprise, in the study of which one can come across the term "equilibrium", when all employees and participants in start-ups and start-ups solve common problems. Practice shows that it is at such enterprises that the teams are more united, work with high efficiency and efficiency. When it comes to bringing new ideas to the market and increasing efficiency, Agile methodology is the best tool.

Of course, some companies do not need Agile methodology. We are talking, for example, about government departments, since the basis of their activities is legislative norms. Interaction with the state is impossible if the rules of the game change regularly.

That is, the organizational infrastructure can be presented in two versions, radically different from each other. The first is a strict bureaucratic company that observes a number of formalities. This option has the right to exist and works fine in certain conditions. The second type is start-ups that bring together people with the same point of view and a common goal, who create something fundamentally new. Agile methodology, of course, is closer to the emotional team working on the production of a quality product. If problems arise at any of the stages, they are solved within the framework of the Agile methodology by all specialists of the enterprise or startup participants.

Basic principles of Agile methodology

There is an Agile manifesto that talks about the basic principles of the methodology:

1. The most important thing is to deliver a valuable product regularly and in advance, thereby satisfying the needs of the customer. In accordance with this principle of Agile methodology, product creators are obliged not only to implement the requirements indicated in the project documents, but also to let the consumer know as early as possible what kind of product it will be, with what features and characteristics. If the product does not satisfy the customer, it is urgently necessary to correct it, taking into account the comments. Since there is a big risk of making a mistake when introducing a new product into the market environment, it is logical to use technical requirements to the creation of a minimum viable product (MVP), the main task of which is to check how much key qualities are in demand among buyers, and to assess the level of demand.
2. Requirements can be changed, and this will be perceived positively if we are talking about improving the competitive qualities of the product. Usually they are changed at the end of the final stage of development. This principle of Agile methodology is very important today, because the products of high-tech industries in as soon as possible becomes obsolete and gives way to a new one. You can form a number of requirements for the product already at the end of its creation. This is usually caused by changes in the market or in the competitive environment. Note that the implementation of this principle is impossible if we are talking about a cascade management model, or it is real, but it will cost the sponsor a round sum. But the more technologies merge, the more relevant it will be to prepare the next version of the product to stay ahead of the competition.
3. The team and the customer must continuously interact at all stages of product creation. This rule is approximately the same as the wishes of the client. It is most important. If there is no constant interaction, it is difficult to achieve the set goals.
4. Agile methodology states that only motivated professionals should be involved in the implementation of projects. Take care of creating the proper conditions and trust the experts. In this case, the probability of high-quality implementation of the project is very high. Modern science says that it is difficult to stimulate intellectual work with financial incentives. Therefore, you should cooperate only with those specialists for whom the main motivation is the project itself. All they need is to be able to work in acceptable conditions and gain the trust of the customer.
5. The best way communications - personal contact. It is desirable that all persons involved in the project are located on a common territory. Let it be one building. Ideally, the customer himself should also be there.
6. The project progresses if the product works. The customer is interested finished goods with certain characteristics. Another successful step in the process means nothing to him. The customer must see that the product is developing, and most importantly, it works and meets the stated requirements. If its shape and content are close to the desired model, then the developers are working effectively.
7. Sponsors, customer and developers need to take care of ensuring a constant pace of activity. If all participants in the process operate in a stable rhythm, then they stop worrying about the likelihood of a rush job or failure to meet deadlines.
8. Attention should also be paid to technical excellence and design quality. Agile methodology states that the development of a project should be flexible, without compromising the quality of the product and simplifying its characteristics. Note that this is often resorted to in order to speed up the process of creating a project and optimize it.
9. Do not forget about the principle of simplicity. By applying it, you reduce the likelihood of performing unnecessary actions to a minimum. The point is not to simplify the characteristics of the product, but to get rid of unnecessary operations and not include in the project something unnecessary for its intended use.
10. Self-organizing teams always generate best ideas architectural, technical and other plan. The authors of the Agile Manifesto are convinced of this. Therefore, all team members must develop requirements and make decisions together. If team members have common interests and common goals, self-organization becomes more effective.
11. External conditions are constantly changing. In this regard, one should constantly analyze and adapt to the situation, look for ways to improve the efficiency of activities. Agile methodology is focused specifically on the flexibility of developers. This is what you should strive for.

Expert opinion

Perspectives of Agile methodology in Russia

Andrey Kocheshkov,

Chief Analyst of OAO Publishing House Prosveshchenie

Agile methodology has a number of advantages, the main of which is flexibility and the ability to adapt, adjust to any environment and organizational process. Agile methodology is the best option for projects whose end is "open". This may be the creation of a computer game, an operating system or an Internet service. At the same time, due to flexibility, you can eventually lose focus and reduce predictability.

It is extremely important to distinguish the errors in the use of an agile approach from the shortcomings of the Agile methodology. It will take some time before the benefits of the methodology are realized. It is necessary to adapt the approach to the current situation in a particular business, and during this period it is possible to make many mistakes. But the fact remains: Agile methodology is becoming one of the most popular paradigms both in Russia and around the world.

Agile methodologies: Agile, Lean, Scrum and others

The Agile Manifesto defines specific principles. Based on them, an agile development methodology Agile has been formed.

• Agile Modeling (AM). Modeling procedures (including verification by model code) and documentation during software development are applied here. Less attention is paid to the procedures for designing and building diagrams in the UML. It does not say about areas such as development, testing, project management, deployment and maintenance.
• Agile Unified Process (AUP) is a unified version of the RUP (IBM Rational Unified Process) methodology, which was formed by Scott Ambler. AUP defines the software development model for business applications.
• Agile Data Method (ADM) is an iterative methodology for agile software development in a complex, which emphasizes the development of solutions and requirements. Different cross-functional teams collaborate with each other.
• Dynamic Systems Development Method (DSDM) is an incremental and iterative method based on Rapid Application Development (RAD). The emphasis is on maximizing the involvement of the end consumer in the creation of products.
• Essential Unified Process (EssUP). The author of the approach is Ivar Jakobson. The approach is endowed with methods of iterative software development. The emphasis is on product architecture and team best practices drawn from RUP, CMMI and Agile Development. The essence of the idea is to use only those methods and techniques that are applied in a particular case. It is their choice that is the basis for determining the target process. This approach differs from RUP with interrelated methods and practices. There is also flexibility and the ability to isolate the necessary elements from everything that is available.
• Extreme Programming (XP), or extreme programming. The essence of the method is to use the existing best techniques in the field of software development and improve them. This approach and common practice differ from each other, in particular, in that in the latter case, the programmer conducts a sequential check of the code written by his colleague. Extreme Programming involves parallel testing, which leads to faster product releases, but also increases risks.
• Feature Driven Development (FDD). As part of the use of the method, there is a main prohibition, which consists in the fact that the implementation of each function should be carried out within two weeks and no more. Ideally, it is developed in one go. If this is not possible, the function is split into several and implemented smoothly.
• Getting Real (GR) - when using the method, do not resort to the procedures of functional specifications used for web applications. Development starts with reverse side, that is, first they think about the design and interface, and then about the functional content.
• OpenUP (OUP) - RUP is the basis for the development of the approach. The method defines an iterative-incremental way to create software. As part of the approach, it is said about life cycle development (phases of launch, refinement, development and transfer to the customer). The method is implemented in several stages, checking certain control points, which helps to increase the efficiency of control and monitoring of the implementation of the project. All decisions concerning the project are made on time.
• Lean Software Development. The approach is based on the concept of lean manufacturing company management (lean production, lean manufacturing).
• Scrum is one of the most sought-after agile software development methods and defines the rules for managing the production process using well-known methods. The emphasis in this case is on the involvement of the customer in the development (when the next stage is completed, it is possible to change or clarify the requirements for the products being created). This allows you to identify shortcomings and correct the product.

Agile Scrum methodology is one of the popular technologies

Almost the most common Agile methodology is Scrum (“Scrum”). The name comes from rugby. This is currently the name of the most structured Agile development methodology. "Scrum" in the sports field is an intense team action aimed at achieving the goal - getting the ball for the subsequent attack of the opponent.

Scrum period is short. The best athletes with excellent training take part in this phase of rugby, as it is quite traumatic. If there are no trained and strong players, Scrum is simply not carried out. The Scrum methodology in Russia is becoming more and more widespread. Let's dwell on it in more detail.

Scrum is based on sprints. This is the name given to short-term fixed actions to create and provide the consumer with a working product with new characteristics. Its capabilities at the same time exceed those that were previously. The term of the "sprint" is fixed, and the predictability and flexibility of the creation process depends on it. If the time frame is short, the flexibility and predictability readings become higher, but the relative cost of each iteration, as well as the time spent on organizing and meeting with the customer and team members, also increase.

An important element of the methodology is the product backlog. This is a list of requirements for end result. The requirements here are clearly structured according to the level of importance. It is from the list that tasks are taken for subsequent sprints. The list can be amended and supplemented in the course of clarifying the characteristics and sales of products.

There is a planning stage at which new functional qualities of the created product are determined for the next sprint. After solving the problem, a sprint backlog is compiled (Sprint Backlog). It remains unchanged throughout its duration.

The methodology also defines structured roles in the project:

• Scrum Master is an intermediary between the team and the client.
• The Product Owner represents the customer, forms, prioritizes the Product Backlog and accepts the intermediate results of the work.
• Team - a project team where there are no separate roles. It is a self-organizing system that includes cross-functional motivated professionals.

The methodology provides financiers with a number of advantages, namely:

• provides an opportunity to save money by not working through project documents for a long time;
• allows you to fully control the budget of the project;
• makes it possible to make adjustments without significant financial losses for the enterprise;
• allows you to launch products early and get the first income from it.

The main problem in this case is the question legal registration this type of activity and interaction with the external development team.

Why you need an Agile management methodology

• The system allows you to feel good in a crisis period and in uncertain situations, earn income, protect your business, and competently use available resources and opportunities.
• Agile methodologies are preferred by both large enterprises involved in the implementation of flexible management methods, and small companies. For the latest Agile methodology − the best option. We are talking about catering establishments, dental clinics and offices, car dealerships; in addition, Agile methodology allows you to "tuning" business processes in areas such as organization foreign economic activity, building sales systems and crisis management.
• Agile methodology is applied in management, marketing, financial industry, personnel management. Thanks to it, you can achieve ultra-fast project implementation and excellent results.
• Agile methodology is first of all flexible thinking and only then tools. To use it successfully, you must certain changes into the mentality, culture of working with projects at the enterprise.
• Agile has many methods. The most popular today are Scrum and Kanban.
• Agile methodology helps to bring your business to a new level, taking into account existing capabilities, resources and practical skills of employees.
• Agile methodology is suitable for any enterprise focused on generating more income and increasing influence in the market environment.
• Agile methodology provides the search and introduction of new technologies associated with a breakthrough, the development of internal entrepreneurial activity, creativity approach and thinking in large organizations.

All of the above is just the beginning. Many business experts and executives large enterprises sure: Agile methodology is the future of the modern economic industry.

Expert opinion

Implementation of Agile methodology to improve staff efficiency

Maria Onuchina,

Director of the Asset Management Department at Becar Asset Management Group, Moscow

We have modified our office space to move towards Agile management:

Stage 1.Organization of workplaces.

Over the course of a month, we studied the workplaces of personnel, identified departments where complete silence is required to conduct effective activities (for example, accounting), drew attention to departments that employ specialists who are constantly away and spend no more than 3 hours in the office. hours a day. We received a schedule showing the number of employees and the specifics of their job duties. Based on the information received, we started the reconstruction of the office.

For employees whose activities involve a permanent presence at work, permanent places have been equipped. Mobile staff were provided with temporary space in the open-space area. You can come there, take your favorite place and turn on remote access. We also paid attention to informal areas: rooms for recreation, negotiations, and a working cafe.

We tried to organize the space in the office so that employees have the opportunity to change the location at any time:

• if necessary, be alone;
• get together in mini-groups;
• hold a meeting between departments in any composition.

The number of such zones within the project was influenced by what proportion of the business the process belongs to.

Stage 2.Adaptation of workers.

Further, we provided assistance to specialists in adaptation. Many are afraid of the changes that the Agile methodology implies, even if they are for the better. After a few weeks had passed, it became clear that the workers liked everything, and they left the offices. At this stage, it is worth letting the staff understand that in the absence of changes in business processes, the enterprise risks leaving the market space.

Stage 3.Introduction of unusual solutions.

We introduced a number of features: we organized a cinema in the common area, where presentations are shown during work, and films are shown in the evenings, as well as a wall with a picture of a tree on which the values ​​of the company are written.

The new office is unusual, but comfortable. We equipped it with multi-level furniture: bar stools, bean bags, leather and fabric sofas, glass tables. Agile management is characterized by such details as:

• modern engineering solutions;
• IT infrastructure;
• comfortable furniture;
• surfaces for recording ideas during negotiations, etc.

Design and repair work was carried out within two months. During this period, the company's specialists performed labor obligations in the old office area. The amount of repair costs was about the same as the cost of a typical reconstruction. The price was affected only by furniture and the latest technology.

Result. A few months of staying in the improved office showed that the work has become a team, and communication between specialists from different departments has improved. Managed to save on rent. On average, there are 12-40 m 2 per person in the office of a large-scale organization. Previously, we had 10 m 2 , and this figure was reduced to 6 m 2 , effectively distributing jobs. The payback period of the project was 1.5 years.

We have equipped all meeting rooms with Wi-Fi and conference calls. So we got rid of the need to rent conference rooms in order to hold external meetings in them. Comfortable conditions attract employees, thanks to which they spend more time at work and perform duties more efficiently.

What problems can arise when an Agile methodology is used

Problem 1.Role habit.

Specialists in project team at first, with a little willingness, they switch to performing work that is unusual for them, even realizing that it will be better this way. For example, analysts often do not like testing a system, although who, if not they, knows everything about the features of its functioning? These kinds of problems are easy to spot in a team and are usually easy to fix.

Problem 2Documentation habit.

First, the developers are waiting for the requirements from the customer - project documentation with an explanation of all issues. This method of passing information is not the most efficient, and therefore it is better for developers to get used to direct communication with the client. Over time, after communicating with the customer, it will become easier for developers to delve into the intricacies of the business and solve obvious issues. Even if they make a mistake, the client will quickly notice it at the end of the iteration, and the defect can be corrected in time.

Problem 3.New team.

The project manager runs the risk of facing the difficulties of working with a new team. Participants still cannot communicate properly with each other, there is no contact between them, they are embarrassed to ask for help and are afraid to criticize someone for a wrong decision. The project manager is responsible. He is obliged to help team members in establishing informal relationships, the existence of which is implied by the Agile methodology. It may be useful to organize a joint trip to a restaurant, a team building event or a sports competition.

Problem 4.Communication problems.

The task of the project manager initial stage– holding rallies with team members to achieve productive and efficient activities.

Problem 5.Timing pressure.

Often, customers put pressure on developers, rush them. Customers want to receive the desired product in minimum term. The team needs to accurately implement the requirements without sacrificing quality. Otherwise, in the long run, the speed of creation will decrease, as the cost of changes due to poor quality will increase. In addition, the lack of quality has a negative impact on the motivation of developers. The project manager should regularly remind mentees of the need to maintain high quality.

Problem 6.Creativity.

Tasks in the project are both interesting and not very. Developers often enjoy making decisions that hurt the project but are technically interesting. Here it is worth remembering the principles of KISS (keep it simple, stupid) and YAGNI (you ain't gonna need it). Let the main characteristic of design decisions be simplicity. You should not do what is not particularly necessary at the moment.

What should be done to make the team make simple decisions? Sometimes it is useful to let specialists make a one-time mistake, so that later they can carefully analyze it and let the developers understand what should and should not be done. Almost any project is supplemented in one way or another with research tasks (new technologies and engineering fields of knowledge). This is where you need to try and experiment.

Problem 7.Time estimate.

Determining the time to solve the problem, experts take into account only writing code. And at the same time, the task includes at least the creation of design and testing. At the very start of the project, the developers think that they will finish the project earlier than possible. At the end of the process, experts note mistakes and draw conclusions for the future. Time runs and the team learns to properly assess the situation. Usually, after 3-4 iterations, the level of accuracy and performance improves.

Problem 8.Management problem.

The expectations of management are the availability of certain functionality by the specified time. But Agile methodology does not guarantee the implementation of plans by 100%. It is only logical to wait for the priority tasks to be solved. It is useful to coordinate plans at the release level with management. The high level of the release plan allows the manager to vary the scope of development of even individual characteristics of the system within a fairly large time frame. For example, the task of creating a search subsystem may include accounting for morphology. Savings are possible at this stage.

Problem 9.Problems of non-team behavior.

In the process of implementing Agile methodology, the following situation is not ruled out. There is a rally, and suddenly one of the participants gets up and starts talking about his ideas. He does not accept objections, but after some time he speaks about the decision made, offering to begin consideration of the second issue. Of course, the team did not make a decision. In fact it did this member taking that right away from her.

There are several options here. It is possible that the person was simply in an overly enthusiastic state, which should soon pass. But often there are those who simply cannot be part of the team due to their nature.

Agile methodology without mistakes

Mistake 1.Top managers do not understand what Agile methodology is and for what purpose it should be implemented.

It requires an accurate understanding of what result we are interested in, what deadlines and budget we have. Fuzzy goals and beautiful wording, such as “Become number one in your field” or “Become more efficient” are not suitable. Let the tasks be expressed in numbers. For example: "Achieve a turnover of $ 3 billion in 2018", "Reduce the time to create a product to 3 months", etc.

Error 2.Wrong diagnosis.

Often, when introducing an Agile methodology, a company wants to solve a number of specific problems, such as overpriced costs or poor quality of goods. But you need to figure out in detail where there are gaps. Otherwise, the manager will wait for the Agile methodology to change everything. However, here he risks only worsening the situation.

Mistake 3.The introduction of Agile only in a separate area of ​​business processes.

This is a logical continuation of the second error described above. The reason for her admission is the same: a lack of understanding of the problem and where it hides. All branches of the enterprise must change: production and marketing parts, accounting and sales. Otherwise, nothing will work. If you introduce changes only in marketing and do not wait for the desired effect, you will have a strong opinion that the Agile methodology is ineffective.

Mistake 4.Downplaying the importance of involving all employees in the company.

You must be allies with your colleagues. If this is not the case, it is better to save resources, time, and do nothing. Agile methodology implies initiative, mobilization and responsibility of all those who take part in the process, at least the managers of the enterprise. If these people are strong and authoritative leaders, able to achieve good discipline in solving problems and introducing new rules at work, then everything will work out. According to statistics, 85% of enterprises do not have strong managers with sufficient professional training.

Mistake 5.The illusion that everything is possible only thanks to human efforts.

Of course, the competence, motivation and professional level of the staff are important in achieving the goals. But attention should also be paid to the proper technical equipment of the company, software, with the help of which the management and planning of activities becomes more efficient. In this regard, whether you like it or not, you will have to invest in the purchase of machines, equipment and software.

Mistake 6.Reluctance to change frames.

Almost 90% of success depends on the team of the enterprise. Continuous attention should be paid to the development, training and proper motivation of employees. Many specialists are not ready to work according to Agile methodology, they are not interested in new knowledge and opportunities, mastering business processes. About 25-30% of the company's personnel do not want to give their best and strive to high earnings. It is better for such employees to say: "Goodbye." Weak links can be quite difficult to identify, and therefore HR managers often do not do this.

Mistake 7.Loss of interest and participation of top managers.

It usually takes 8-16 months to implement a project. In 70% of situations, after three months, the interest of the participants decreases. As a result, team members simply do not want to be part of the project. If this is the case, you, of course, will not be able to solve the problem.

Agile methodology: examples of unsuccessful application

Agile methodology attracts many professionals, and to date, a number of world-famous companies have tried to implement it. But almost no one managed to achieve the desired result.

Example: In 2015, there was trading on the New York Stock Exchange that had to be stopped for as much as 4 hours. At first it was explained by a cyberattack. But, as it turned out later, the problem was a bug in the process of the next update. Of course, 4 hours of downtime of the world trade center brought billions of dollars in losses.

And this example is not the only one. It is easier for brokers: they lost, and then they earned twice as much. The situation is more complicated for airlines. Approximately the same situation occurred with the Delta air carrier after a simple software update. The dispatching system stopped receiving data, which led to the forced cancellation of flights. The company not only suffered losses, but also paid with its reputation.

The most high-profile failure of the Agile methodology is associated with the launch of the Obama Care health insurance system in the United States. The meaning of the program was as follows: certain categories of American citizens were provided with free insurance policies. To obtain such a right, a person had to fill out a questionnaire on the site and wait for the decision of certain services. Of course, millions of people rushed to fill out the questionnaires. But the problem was that they were able to fill out the questionnaire, but they couldn’t send it, there was some kind of server failure. The Obama Care system ended approximately 6 months after launch. To get the job done, the stakeholders brought in a specialist from outside who assessed the situation. The consultant has come a long way, starting from the end - "production", putting the parts together and managed to achieve the correct functioning of the system.

Expert opinion

Example of successful implementation Agil-control

Sergey Buchik,

CEO NPM Group, Novosibirsk

The company, including all departments, has been moving to Agile methodology for 1.5 years. Previously, the HR department consisted of: a HR specialist, a training manager and a recruiter. Management of divisions, choosing new staff or conducting training, filled out applications in huge number. Now each department of the enterprise has its own HR. In development teams that work on the Scrum methodology, this place is reserved for the Scrum Master. The products here are a personnel service, and team members are internal consumers.

The new style of management according to Agile methodology has taken root well in the field of recruitment. The customer can plan his activities, taking into account the candidate's exit at exactly the specified time. During 9 sprints lasting 2 weeks, we managed to reduce the number of overdue vacancies by 2 times. A simple vacancy (for example, a caster) is now closed in 20 days, an average one (service engineer) - 32 days, a rare specialist (technologist for plastic molding) - 51 days. After completing the first sprint, it became clear to recruiters that the most important thing for department managers is not the speed of the search, but the transparent deadlines for closing vacancies and the period of time that they can spend on selecting an employee with subsequent training. At the moment, the manager tells the customer about the timing and stage of the search for the applicant. It is also the responsibility of recruiters to “pump” the technical competencies needed to effectively recruit manufacturing jobs, such as learning to read blueprints.

Let's give an example: the management of the department does not realize what kind of employee it needs, or this issue is decided by specialists from several departments at once. Let's say a company needs a storekeeper who will work in a tool warehouse. In this case, the production department and the logistics service order a vacancy. It is the responsibility of the recruiter to take into account the requirements of these departments for the applicant. Manufacturers need technical specialist who knows perfectly modern metal-cutting tools. Logisticians want to see any professional with experience and who knows perfectly what warehouse Logistics. Customers have not yet decided and have not deduced a common denominator, but the recruiter is already looking for a candidate, considering applicants. After choosing the best, in his opinion, applicant, he conducts a dialogue with all customers. If it is not possible to reach an agreement after the interview, the recruiter makes changes to the text of the vacancy.

At the moment, the departments are coming to the conclusion that the target group should include technical masters with excellent knowledge of the tool. The recruiter again searches, selects suitable applicants and meets with them. This continues until the vacancy closes.

Agile Project Management Methodology: 6 Rules for Effectiveness

Rule 1 Work on the project plan and answer the following questions: what tasks are the priority, what resources are required for this, what is the time frame for achieving the result?

Long-term plans have a rather low accuracy, so plan in three planes:

• a plan in the long term, indicating all the tasks required to be completed and major planning of the timing of the implementation of key milestones;
• monthly goal plans, based on the general plan (their implementation should not be less than 90%);
• define within a month the most detailed goals, clearly describing the results of their achievement.

Rule 2 Involve the team in the implementation of the project, inform the employees about it. All specialists must understand and share the goals of the organization, know what needs to be done to solve the tasks, even if these employees do not fulfill them within the framework of the project.

Rule 3 Meet with the implementation team from time to time. The frequency of meetings is 1-2 times a month. This is required to determine the solution of tasks and problems, timely adjustment of the plan in case of difficulties with implementation. However, to regulate acute conflict situations does not follow during the meeting, which is scheduled in a week. The authorization must be clear and prompt.

Rule 4 You should not stop the project if you see that it does not give a positive effect. Problems, as a rule, arise due to the dissatisfaction of the team, whose members have to leave the comfort zone and tune in to a creative way. Remember that the first results are usually measured after completing 80% of the entire path.

Rule 5 Say “Goodbye” to underperforming employees if you see that Agile methodology is not close to them.

Rule 6 Don't set yourself up for perfect problem solving the first time. About 95% effective tools and ideas were achieved after many iterations and adjustments over several iterations.

1. Andrew Stellman, Jennifer Green "Understanding Agile".

The book talks about the four main options in which the Agile methodology is presented. Their description is quite interesting and detailed. Thanks to the manual, mastering the art of applying techniques becomes easy and entertaining.

The book reveals the essence of the most popular Agile methodologies: Scrum, XP (extreme programming), Lean (lean programming) and Kanban (Kanban); tells how to use them to create quality programs and achieve your goals. The manual explains how the Agile methodology helps to change the thinking of project participants, unite them and strive for improvements together. The purpose of the publication is to talk about Agile methods, values ​​and principles, thanks to which teams can completely change the strategy of working on projects and approach it differently. The manual will be of interest to both project managers and managers, and just those who are fond of the flexible Agile development methodology.

2. Boris Volfson "Flexible project and product management".

The book combines theory and practice. It describes various aspects of the concept of Agile methodology, product development, management, and analytics. The theoretical part on project and product management contains information about the current state of Scrum and Kanban. In the practical, it talks about requirements management, teams, risks, business modeling, requirements analytics, time estimates, engineering practices for product development (mainly extreme programming), quality control and assurance, implementing and scaling Scrum.

3. Jeff Sutherland Scrum. A revolutionary method of project management”.

Jeff Sutherland has his own methodology, which he developed in an attempt to overcome the shortcomings of classical project management. Specialists in different companies it is often difficult to achieve effective, fast and coordinated work. They fail to complete most of their plans due to lack of time and resources, and departments and teams often solve or repeat tasks that are opposite in meaning.

Scrum has been around for 20 years, and during this time, not only software developers, but also auto manufacturers, pharmacists, the FBI and ordinary people who plan their time and opportunities have successfully used the technique.

By reading this book, you will look at project management differently and understand how to solve tasks that seemed unattainable before. It doesn't matter what your plans are: opening a startup, changing educational system, the introduction of new technologies or more effective team management. Thanks to Scrum, you will increase your productivity at times. The manual is perfect for project managers, managers and IT-specialists.

4. Roman Pikhler Product Management in Scrum.

The manual will be of interest to everyone who studies Agile methodology, especially those who own the technology. The book tells what role the product owner takes, how best to manage it, what are the main ways to do this. We are talking about visualizing the product, creating and improving the backlog, planning and tracking releases, and effectively using Scrum.

5. Kenneth S. Rubin "Fundamentals of Scrum".

From the book, you will learn all about Scrum, the terms of this methodology and understand how to benefit from its application. If you are interested in Agile methodology, the guide will tell you what it takes to achieve great results. The book is written by a leading Scrum training specialist. The author details the key principles, values ​​and norms of practice, touching on flexible approaches, the effectiveness of which has been confirmed by time.

Information about experts

Andrey Kocheshkov, Chief Analyst of OAO Publishing House Prosveshchenie. "Enlightenment" - Soviet, and later Russian specialized publishing house of educational and pedagogical literature.

Maria Onuchina, director of the facility management department at Becar Asset Management Group, Moscow. Becar-Exploitation LLC (Becar Asset Management Group). Field of activity: a systematic solution to the problems of managing objects (property management), projects (project management) and investments (brokerage, evaluation). Number of personnel: 5000. Territory: front offices - in Moscow and St. Petersburg; three offices and 55 separate subdivisions- in different cities of Russia.

Sergey Buchik, CEO of NPM Group, Novosibirsk. NPM LLC (NPM Group). Field of activity: production of equipment for the beverage industry; development of IT solutions for integration with equipment, mobile applications. Number of employees: over 300. Market share: 95% of beer and carbonated beverage bottling equipment in Russia. Number of patents for own products: over 80.