Agile calculation. How programs are created using the Agile methodology. Disadvantages of the classical project management methodology

These approaches are also sometimes referred to as frameworks or agile methodologies.

Agile originated in the IT environment, but then it spread to other areas - from industrial engineering to artificial intelligence.

When working with professional teams we use Scrum, most often we choose a 2-3 week cycle with retrospective meetings that allow us to keep everything under control.

If we talk about what agile is, I would limit myself to such a phrase - it is a set of values ​​within the framework of which we build our work with products, with processes within the organization.

(ScrumTrek Managing Partner Alexey Pimenov on Rusbase)

A word to the experts

Vladimir Ovelyan

Owner and general director Dostaevsky

Depending on the tasks, we apply different methods within the philosophy - agile, scrum, kanban.

Scrum allows you to develop the necessary qualities in employees - proactivity, independence, organization, communication skills and foresight. The main point of the method is to perform tasks in self-organizing teams, where everyone has their own role and everyone is responsible for their part of the work. Using scrum, we conduct staff surveys, draw up graphs of the expected speed of task completion.

We use Agile in internal communications. We recently held another sprint to eliminate employee tardiness. All the bosses and specialists involved in the project spent the whole day in a meeting discussing the achievements, challenges and upcoming tasks in the new sprint.

Now we are actively introducing the kanban method in the company. The goal of kanban implementation is to increase production flexibility, better adapt to changing market demands. In practice, the method helped us to achieve a correspondence between the warehouse stock and the products actually used in production.

Vitaly Sotnikov

Creative Director of the Bureau of Visual Communications "Chernika"

Ilya Shikhaleev

ISpring Lead Developer and Scrum Master

Scrum brought rhythm and understanding to our team - whether we are on time or not on time. We see the speed of the team's work, there is no feeling of constant fucking. Previously, there were situations that before hard releases scrum disappeared somewhere and everyone just started to figure it out - now we have lost it, there is a constant feeling that we are on time. If risks arise, we discuss them with PD early on, adjust the plan, or reduce the scope of tasks in some way.

The work became more transparent, the working day began to fit into the 8-hour norm, and it felt like we began to do more. We understand that when you have a feeling that you are not doing enough, you feel that you need to work harder - this has a very bad effect on productivity, you need to get rid of it.

Evgeny Rossinsky

Technology director at ivi online cinema

For clarity and openness of the work of the development department, we put up a special board marked “to do”, “in progress”, “review”, “test”, “done”, where all team members stick stickers with tasks (in the column “to do” ), and as they are performed, they are moved to subsequent points. And a happy ending is the “done” end point. This helps to get the big picture and gives you the opportunity to see what each participant is working on.

A very important point of the method (and organization of the workflow): after approval of all tasks (“to do”), the list is blocked for insertion. Thus, new incoming tasks do not distract from the process and do not slow down the work.

All participants also assess each task in terms of time and material costs that will be required to complete. And the icing on the cake is weekly meetings at a specific time (Daily Scrum), where each team member briefly talks about what they are going to do today, what they did yesterday (and whether they faced any obstacles). This is important on the way to long-term goals - this is how you can understand in time that it is time to change your strategy.

"Of all the challenges NASA faced in sending a man to the moon, control was probably the most difficult task."

- Roger Launis, NASA Historian

Throughout history, mankind has accumulated an impressive list of successfully implemented complex projects. From the construction of the Pyramids at Giza to sending a man to the moon, the most daring human endeavors required the coordinated work of thousands of people. And this implies a complex project management system.

And although only a few of us will be faced with tasks of this magnitude, most of the readers of this blog are faced with project management in one way or another. PMI estimates that by 2020 there will be - and many other professionals often have to manage mini-projects, at least on a personal level.

In simple terms, Project Management is all about managing and organizing everything you need to achieve a goal - on time and on budget, of course. Be up to developing a new one software, conducting a marketing campaign or landing a man on Mars - project management allows you to succeed.

All projects are different. There is no perfect project management system for every type of project. Also, there is no system that would fit every leader and be convenient for all team members. However, during the existence of project management, many effective approaches, methods and standards have been created that can be adopted. We will talk about the most popular of them today.

The developed approaches are very different from each other. They differ in scope, detail, self-sufficiency, and formalization. In the title, we called them “methods” for convenience, but in fact, this article introduces the standards, concepts, methods, and frameworks that are used in project management. The purpose of this article is to provide the broadest overview of existing approaches in project management.

In this article we will look at:

• Classic project management
• Agile
• Scrum
• Lean
• Kanban
• SixSigma
• PRINCE2

And before looking at specific methods, let's answer the obvious question - "Why do we need project management systems and methods at all?"- consider, of course, briefly, the history of project management and define the basic terms of project management.

Why "project management"?

The names of Neil Armstrong and Buzz Aldrin will forever go down in history as symbols of one of the greatest achievements of mankind - the landing of man on the moon. However, the major contributors to this event were 400,000 NASA employees and 20,000 companies and universities who worked together on the Apollo mission.

In 1961, John F. Kennedy set the task of landing a man on an Earth satellite and returning him back - despite the fact that at that time NASA sent a man into space for only 15 minutes. Such an ambitious goal required an incredible amount of resources, cooperation, innovation and planning.

As NASA's book Managing the Moon Program states, the main problem was not, “ what to do?", but in that, " how to do so much in such a short time? " According to Dr. Max Faget, head of engineering at Lyndon Johnson Space Center (The Lyndon B. Johnson Space Center, JSC), then NASA had no idea how to put all the necessary actions in 10 years. Therefore, the first step was to "break the project into manageable stages."

Then it was important to expedite each phase and make sure that the teams and companies working in each phase communicate effectively with each other and deliver results on time. This task was entrusted to Dr. George E. Muller, who managed every part of the Apollo project, from the White House to the supplier of the smallest part. To make the project easier to control, he decided to split the project into 5 areas: Program Control, System Engineering, Testing, Reliability and Quality, and Flight Operation. The Apollo program control scheme is presented on Figure 1.

This 5-stage system - named "GEM Stages" after Dr. Müller's initials - was designed "to focus on product testing and product development with the intention of being tested," as Mueller himself notes. Program Control determined what needed to be done, managed budget and requirements, and managed the relationship of program elements. The field "Systems Engineering" was responsible for the development of new devices and assemblies, "Testing" for the fact that these new elements work, "Reliability and Quality" checked the developed elements for compliance with requirements and standards, and "Flight Operation" was responsible for the fact that these the nodes will work during the flight.

Many initially reacted with skepticism to the method proposed by Mueller, but in the end he managed to convince the members of the program to follow this algorithm. This system has shown its effectiveness - the project was completed successfully, and, one might even say, triumphantly, ahead of the announced deadlines. This was only made possible by breaking a large-scale project into manageable, repeatable steps that allowed multiple individual companies and specialists in a single rhythm. This is how project management proved its effectiveness in the Space Race.

A brief history of project management

Project management was not invented by NASA and Dr. Mueller. The Egyptian pyramids and the Great Wall of China are products of project management from prehistoric times. Unfortunately, documentary evidence of how the implementation and management of these projects was not preserved, and the current project management is divorced from the knowledge of past centuries.

The most obvious way to implement a project is to break it down into phases or separate tasks. Like a culinary recipe - buy ingredients, mix them correctly, cook and serve them. The simplest project management tool is a checklist of actions that need to be taken to achieve a goal. Simple and effective.

However, if you are a chef and cook more than one dish, but several, for example, a salad (preparation of which consists of 3 stages) and a dessert (which only needs to be served), then you will need a tool that allows you to track the time spent on each of elements and the time when they should be ready. And here one of the first modern project management tools comes to the rescue: the Gantt chart, presented on Figure 2.

Invented independently by K O Role of Korol Adamecki and Genry L. Gantt in the early 20th century, a Gantt chart shows a project schedule based on task completion and completion dates. Tasks, their durations and relationships are entered into it, and then the critical path is calculated - the longest chain of interrelated tasks that determine the duration of the project. The relationship between starting and ending different tasks is very important - you can't serve soup to your guests before you've cooked it, can you?

So, a typical project is very similar to a project for preparing and serving a dinner, only it has many more tasks, relationships, deadlines and types of resources. For projects with tight deadlines, the Gantt chart helps you decide when to start certain tasks in order to shorten the implementation time. And for projects with strong resource constraints, the Gantt chart provides the ability to build an event-driven process chain for resource planning.

Different projects need different level control. For example, if you are publishing a series of articles in, then tight deadlines are not that important. Much more important is a clear process whereby it is possible to structure each article, sketch each article, get feedback, make edits, finish the article, proofread and publish. Instead of managing time and resources, you control the process.

Agile project management techniques and related approaches such as Lean, Kanban, and others are better suited for such projects. There are also methods that allow you to manage both workflow and time and resources - 6 Sigma and Scrum.

Popular project management systems

Throughout the history of project management, many different project management methods have been created for almost any need. Even if you are not going to send a person to the moon and do not have the same amount of resources, you will still find a suitable tool for yourself. The key is to understand what is most important to your project - deadlines, resources, adherence to the process, or several factors at once - and then choose a project management method focused on achieving this indicator.

Before we start looking at the most popular methods, let's define some key terms.

Basic terms of project management

Agile: A flexible iterative-incremental approach to project and product management, focused on the dynamic formation of requirements and ensuring their implementation as a result of constant interaction within self-organizing working groups consisting of specialists of various profiles. There are many methods based on Agile ideas, the most popular of which are Scrum and Kanban.

Critical path: Continuous sequence of works and events from the beginning to the end event, which takes the longest time to complete.

Event chain of processes (EPC diagram): a diagram showing the sequence of the implementation of projects based on the availability and utilization of resources

Time reserve: The time by which the start of work can be postponed without affecting the overall duration of the project. Thus, the reserve for works on the critical path will be equal to zero.

Milestone (checkpoint,milestone): A key event that marks, for example, the end of a stage. Indicated on the Gantt chart is a task with zero duration.

Project manager (project manager,projectmanager,PM ): The project team leader responsible for project management (planning, implementation and closing of the project).

Resources: Elements required for the implementation of the project. Resources are time, equipment, materials, employees, and so on.

Sprint (Sprint): An iteration (work cycle) in Scrum, lasting from a week to a month, during which a working version of a product or its element of value to the customer is created.

"Classic" or "traditional" project management: The most widely used project management method is based on the so-called "waterfall" or cascade cycle, in which the task is transferred sequentially in stages that resemble a flow.

Classic project management

The most obvious way to make your project more manageable is to break down the execution process into successive steps. It is on such linear structure traditional project management is based. In this sense, it resembles computer game- you cannot go to the next level without completing the previous one. The workflow diagram is shown in Figure 3.

This approach is focused on projects in which there are strict restrictions on the sequence of tasks. For example, building a house - you cannot build walls without a foundation.

Usually, there are 5 stages of classical project management, but additional stages can be added if the project requires it.

5 stages of traditional management:

Stage 1. Initiation. The project manager and team define the requirements for the project. At this stage, meetings and brainstorming sessions are often held, at which it is determined what the product of the project should be.

Stage 2. Planning. At this stage, the team decides how it will achieve the goal set in the previous stage. At this stage, the team clarifies and details the goals and results of the project, as well as the scope of work on it. Based on this information, the team forms calendar plan and budget, assesses risks and identifies stakeholders.

Stage 3. Development. This stage is not implemented for all projects - as a rule, it is part of the planning phase. In the development phase characteristic of technological projects, the configuration of the future project and / or product and the technical ways of achieving it are determined. For example, in IT projects, a programming language is chosen at this stage. ( In domestic practice, this phase is usually not highlighted, and the term "development" is not used - approx. per.)

Stage 4. Implementation and testing. In this phase, the actual main work on the project takes place - writing code, erecting a building, and the like. Following the developed plans, the content of the project, determined earlier, begins to be created, control is carried out according to the selected metrics. In the second part of this phase, the product is tested, it is checked for compliance with the requirements of the Customer and interested parties. In terms of testing, product deficiencies are identified and corrected.

Stage 5. Monitoring and completion of the project. Depending on the project, this phase can consist of a simple transfer of the project results to the Customer or a long process of interaction with clients to improve the project and increase their satisfaction, and support the project results. The latter applies to projects in the field of customer service and software.

What is described above is the base on which to build different methods project management. Different projects need different implementation phases - for some, three phases are enough, others much more. Sometimes the so-called "iterative waterfall" is used, in which each stage is a sub-project, during which tasks are implemented in fixed iterations. But the essence remains the same - the project is divided into stages, which are executed in a strictly defined sequence.

Due to the fact that classical project management is strictly tied to the execution time of tasks, as a rule, predetermined at the planning stage, scheduling and network planning tools are excellent for implementing projects within this approach. The most common scheduling tool is the previously mentioned Gantt chart. There are many tools to build it, from simple spreadsheets like Excel and Smartsheet to professional software packages like Microsoft Project and Primavera.

Strengths of classical project management

Today it is often said that the classic waterfall approach is outdated, but it does not even think to give up its positions. The big advantage of this approach is that it requires the Customer and the company's management to determine what they want to get, already at the first stage of the project. Early inclusion brings a certain degree of stability to the project, and planning helps to streamline the implementation of the project. In addition, this approach involves monitoring indicators and testing, which is absolutely necessary for real projects of various sizes.

Potentially, the classical approach allows you to avoid stress due to the availability of spare time at each stage, in place in case of any complications and the realization of risks. Plus, with the planning phase done right, the project manager always knows what resources he has. Even if this estimate is not always accurate.

Weaknesses classical project management

The main weakness of classical project management is intolerance to change. Famed for building systems such as Lean and Kanban, Toyota executives are often criticized for taking the classic approach to developing software for their company, and precisely for their lack of flexibility.

The mainstay of the classical approach now is construction and engineering projects, in which the content of the project remains practically unchanged throughout the entire project. But if resources and time are not the key constraints in your project, and the content of the project is subject to change, you may need to look at other project management systems.

Agile

As mentioned earlier, not all projects can be structured in such a way as to be implemented according to the classical design approach. Returning to our example with the chef: the preparation of one dish ideally falls on the "waterfall" approach, but it will be almost impossible to prepare and serve a four-course dinner on time if you have to wait every time for the end of one dish to start cooking another.

And that's where Agile comes into play - a family of flexible, iterative-incremental methods for managing projects and products. According to this approach, the project is not divided into sequential phases, but into small subprojects, which are then "assembled" into finished product... The scheme of work is shown on Figure 5.

Thus, initiation and high-level planning are carried out for the entire project, and the subsequent stages: development, testing, and others are carried out for each mini-project separately. This allows you to transfer the results of these mini-projects, the so-called increments, faster, and starting a new subproject (iteration), you can make changes to it without high costs and impact on the rest of the project.

Despite the fact that Agile has become fashionable relatively recently, the idea of ​​iterative development is not new. (about the history of the appearanceAgile can be read - approx. Transl.). The family of agile methodologies received its current name in 2001 with the publication of the Agile Manifesto, which enshrined the core values ​​and principles of agile software development, which are based on - teamwork and adaptation, even "love" of change.

Agile itself is not a project management method. Rather, it is a set of ideas and principles for how projects should be implemented. Already on the basis of these principles and best practices separate flexible methods were developed, or, as they are sometimes called, frameworks (frameworks): Scrum, Kanban, Crystal, and many others. These methods may be quite different from each other, but they follow the same principles.

StrengthsAgile

Agile's greatest strength is its flexibility and adaptability. It can adapt to virtually any organization's environment and processes. This is what determines its current popularity and how many systems for various fields have been created on its basis.

One of the principles of Agile: "Responding to change is more important than following the plan." It is this quick and relatively painless reaction to change that is the reason why many large companies strive to make their processes more flexible. In addition, Agile is great for open-ended projects such as launching a service or a blog.

Agile's domain is the development of new, innovative products. There is a high degree of uncertainty in projects for the development of such products, and information about the product is disclosed as the project progresses. In such conditions, it becomes impossible to implement the "waterfall" project - there is no information for planning.

WeaknessesAgile

Unlike PRINCE2 and PMBOK, Agile is neither a methodology nor a standard. Agile is a set of principles and values. The weak point is that each team will have to independently compose their own management system, guided by the principles of Agile. This is a difficult and time-consuming process that will require changes throughout the organization, from procedures to core values. This is a thorny path and not all organizations can do it.

This path will require the leader to change not only knowledge and perseverance, but also serious administrative resources and costs. Fortunately, there are out-of-the-box practice kits that facilitate the Agile transformation of an organization. These sets include the Scrum framework, the Kanban method and many others - Crystal, LeSS, SAFe, Nexus.

Scrum

The agile framework, created in 1986, is considered the most structured of the Agile family. Created in 1986, it combines elements of the classic process and the ideas of an agile project management approach. The result is a very balanced combination of flexibility and structure.

Following the precepts of Agile, Scrum breaks down the project into parts that can immediately be used by the Customer to obtain value, called product backlog. And in spite of the fact that “product groundwork” is a fairly correct translation and is used in professional literature, in Russian practice, most often just “backlog” is used. Then these parts are prioritized by the Product Owner - the Customer's representative in the team. The most important "pieces" are selected first for execution in the Sprint - these are the Scrum iterations lasting from 2 to 4 weeks. At the end of the Sprint, the Customer is presented with a working increment of the product - the very important "pieces" that can already be used. For example, a site with a part of the functionality or a program that is already working, albeit partially. After that, the project team proceeds to the next Sprint. The duration of the Sprint is fixed, but the team chooses it independently at the beginning of the project, based on the project and its own productivity.

To make sure that the project meets the requirements of the Customer, which tend to change over time, before the start of each Sprint, the project content that has not yet been completed is reassessed and changes are made to it. Everyone is involved in this process - the project team, the Scrum Master (Scrum Master, the project team leader) and the Product Owner. And the responsibility for this process lies with everyone.

As already mentioned, the Product Owner is the representative of the Customer in the project, or personifies all the clients of the future project if there is no Customer. To do this, he must thoroughly know their needs and way of thinking, as well as understand the product and its manufacturing technology. The Scrum Master is designed to help project participants better understand and accept the values, principles and norms of Scrum practice. He is the leader and mediator between outside world and the team. His task is to make sure that no one interferes with the team independently and comfortably working on the assigned tasks. The team is responsible for ensuring that at the end of the sprint, all the necessary tasks are completed and the deliveries are completed.

The basic structure of Scrum processes revolves around 5 main meetings: organizing the backlog, planning the Sprint, daily fly-bys, summing up the Sprint and the Sprint retrospective.

Scrum may seem difficult to implement to many - new process, new roles, a lot of delegation and a completely new organizational structure. But this is a flexible and at the same time structured approach to the implementation of projects, which, in contrast to the vague and general principles Agile prevents work from going wrong.

StrengthsScrum

Scrum was designed for projects that require quick wins combined with a tolerance for change. In addition, this framework is suitable for situations where not all team members have sufficient experience in the area in which the project is being implemented - constant communication between team members allows a lack of experience or qualifications of some employees due to information and help from colleagues.

Online TV channel Netflix is ​​a great example of fast delivery of results. The site of the resource is updated every two weeks thanks to Scrum, which not only allows you to work at high speed, but also accumulates user experience and makes it possible to identify the most important things for clients.

During each iteration, the developers add and test new features of the site and remove those that were not used by clients. According to the Netflix team, the main benefit of Scrum is that it allows you to "get it wrong quickly." Rather than taking a long and expensive time to prepare a large release, the biweekly Scrum shipments are small. They are easy to track and, if something goes wrong, they can be quickly corrected.

WeaknessesScrum

Scrum is very demanding on the project team. It should be small (5-9 people) and cross-functional - that is, team members should have more than one competence required to implement the project. For example, a software developer must have knowledge of testing and business intelligence. This is done so that part of the team does not “stand by” at different stages of the project, as well as so that employees can help and replace each other.

In addition, team members must be “team players”, actively take responsibility and be able to organize themselves. It is very difficult to find such a mature team!

Scrum is not suitable for all teams and organizations also because the proposed process may not be suitable for the development of a specific product - for example, an industrial machine or building a building.

Lean

Agile tells us to break down into small, manageable work packages, but it says nothing about how to manage the development of that package. Scrum offers us its processes and procedures. Lean, in turn, adds a workflow to the principles of Agile so that each iteration is performed equally well.

In Lean, just like in Scrum, work is broken down into small delivery packages that are implemented separately and independently. But in Lean, there is a workflow for the development of each delivery package with stages similar to those created for the Apollo project. As in classical project management, these can be the stages of planning, development, production, testing and delivery - or any other stages necessary for the high-quality implementation of projects.

Lean phases and their flexibility allow you to be sure that every part of the project is being implemented as required. Lean does not contain clear boundaries for stages, as in Scrum Sprints limitations are spelled out. In addition, unlike classical project management, Lean allows you to simultaneously perform several tasks at different stages, which increases flexibility and increases the speed of project execution.

Like Agile, Lean is more of a concept, a way of thinking, rather than something set in stone. Using Lean ideas, you can independently create a system that meets your project management requirements.

StrengthsLean

If you love Agile ideas, but the project requires very consistent quality and precise execution, Lean provides a set of tools to meet these requirements. Lean combines flexibility and structure, like Scrum, but in a slightly different way.

WeaknessesLean

Not every part of the project requires the same detailed and meticulous study and attention. But Lean assumes exactly this approach to each task and stage. This is the main disadvantage of using Lean for large and heterogeneous projects.

Also, unlike Scrum, Lean does not provide a clear workflow for the implementation of the "pieces" of the project, which contributes to the stretching of the project deadline. This problem can be solved with effective leadership and clear communication - the main thing to keep this in mind.

Kanban

Lean looks a little abstract on its own, but when combined with Kanban, it becomes much easier to use it to build your own project management system. Created by Toyota engineer Taiichi Ono in 1953, Kanban is very similar to an industrial production scheme. At the entrance to this process, a piece of metal enters, and at the exit a finished part is obtained. Also in Kanban, the product increment is passed forward from stage to stage, and at the end a ready-to-ship item is obtained.

In addition, the creator of Kanban was inspired by supermarkets, namely their principle - "keep only what the customer needs on the shelves." Therefore, in Kanban, it is allowed to leave an unfinished task at one of the stages if its priority has changed and there are other urgent tasks. An unedited blog post, hanging without a posting date, or a piece of feature code that might not be included in the product are all fine for Kanban work.

Kanban is much less strict than Scrum - it does not limit sprint times, there are no roles other than the product owner. Kanban even allows a team member to conduct multiple tasks at the same time, which Scrum does not. Also, meetings on the status of the project are not regulated in any way - you can do it as you like, or you can not do it at all.

To work with Kanban, you need to define workflow stages. In Kanban, they are represented as columns, and tasks are represented by special cards. The card moves through the stages, like a part in a factory going from machine to machine, with a higher percentage of completion at each stage. As a result, we get a product element ready for delivery to the customer. A board with columns and cards can be either real or electronic - even here, Kanban does not impose any restrictions on users.

Your own Kanban system can be as flexible as you wish - in many ways, Kanban is a visualization of an Agile idea. But Kanban has 4 pillars that support the entire system:

1. Cards: For each task, an individual card is created, in which all the necessary information about the task is entered. Thus, all the necessary information about the task is always at hand.
2. Limit on the number of tasks at a stage: The number of cards at one stage is strictly regulated. This makes it immediately clear when a "congestion" occurs in the workflow, which is quickly resolved.
3. Continuous flow: Tasks from the backlog enter the stream in order of priority. Thus, the work never stops.
4. Continuous improvement ("kaizen" (kaizen)): The concept of continuous improvement emerged in Japan at the end of the 20th century. Its essence is in constant analysis production process and finding ways to improve productivity.

StrengthsKanban

Like Scrum, Kanban works well for a reasonably tight-knit team with good communication. But unlike Scrum, Kanban doesn't have clear deadlines, which is great for motivated and experienced teams.

When properly configured and managed, Kanban can be of great benefit to the project team. Accurate calculation of the workload on the team, the correct placement of restrictions and a focus on constant improvement - all this allows Kanban to seriously save resources and fit into deadlines and budget. And all this is combined with flexibility.

WeaknessesKanban

You can often hear that in Kanban, unlike Scrum, you can work with almost any team. But it is not so. Kanban is best for teams whose members' skills overlap with each other. In this way, they can help each other overcome difficulties in solving problems. Without it, Kanban will not be as effective as it could be. Also, as already mentioned, Kanban is better suited when there are no tight deadlines. For tight deadlines, the classic approach or Scrum is better.

6 Sigma (Six Sigma)

Motorola, along with Toyota, has also contributed to the development of global project management. Bill Smith, an engineer at this company, created the 6 Sigma concept in 1986. This is a more structured version of Lean than Kanban, which adds more planning to save resources, improve quality, and also reduce scrap and problems.

The ultimate goal of the project is customer satisfaction with the quality of the product, which can be achieved through a continuous process of improvement of all aspects of the project, based on a thorough analysis of indicators. 6 Sigma focuses on troubleshooting problems that arise.

For this, a 5-step process has been proposed, known as DMEDI:

• Definition (Define): The first stage is very similar to the early stages of other project management systems. It determines the content of the project, collects information about the prerequisites of the project, sets goals.
• Measurement (Measure): 6 Sigma is focused on collecting and analyzing quantitative project data. At this stage, it is determined what indicators will determine the success of the project and what data needs to be collected and analyzed.
• Study (Explore): During the research phase, the project manager decides how the team can achieve the set goals and fulfill all the requirements on time and within budget. At this stage, it is very important for the project manager to think outside the box when solving the problems that have arisen.
• Development (Develop): At this stage, the plans and decisions made in the previous stages are being implemented. It is important to understand that at this stage, a detailed plan is needed, which describes all the actions necessary to achieve the set goals. Also at this stage the progress of the project is measured.
• The control (Control): A key milestone in the 6 Sigma methodology. Its main task is the long-term improvement of project implementation processes. This stage requires careful documentation of the lessons learned, analysis of the collected data and the application of the knowledge gained both in projects and throughout the company as a whole.

6 Sigma is very similar to Kanban, only with established milestones - planning, setting goals, and testing quality. Most likely, there will be significantly more team meetings with 6 Sigma than with Kanban, but the process of project implementation is more structured and it is more difficult for the team to go astray. And like Kanban, 6 Sigma can be relatively easily tailored to the needs of a particular company or team. A strict requirement is only a careful measurement and control of project indicators at the stages of implementation - without this, continuous long-term improvement of the project implementation processes is impossible.

Strengths of 6 Sigma

6 Sigma provides a clear framework for project implementation and continuous process improvement. By defining goals, then carefully analyzing and revising them, you get quantitative data for a deeper understanding of the project and better decision making. While collecting, analyzing data and extracting lessons can take some time, it will improve and optimize project implementation processes and thus save resources in the future.

6 Sigma is suitable for difficult projects with many new and complex operations. This approach allows you to implement project elements, learn from mistakes and improve quality in the future.

Weaknesses of 6 Sigma

The problem with 6 Sigma is that although the main declared goal is to reduce costs and increase efficiency, but customer satisfaction is often taken to the fore. Given some differences in goals at different stages of a project, teams often have confusion about priorities, and this is not easy to avoid.

In addition, the main theme of 6 Sigma is: "Everything can always be made better." This can demotivate employees who do not feel satisfied with the work they have done. In addition, if the project is a one-off and the company does not plan to implement similar projects in the future, all the costs for analysis and learning the lessons may be in vain.

PRINCE2

NASA is not the only government agency that has contributed to the development of project management. The British government has long appreciated the effectiveness of project management, and in 1989 the British PRINCE2 methodology was created. The name comes from the acronym " PR ojects IN C ontrolled E nvironments version 2 ", Which translates as" Projects in a controlled environment version 2 ". Unlike agile methods, PRINCE2 does not take an iterative approach to the project. If you compare PRINCE2 with other products, then it can be compared to a hybrid of the classic approach to project management and a focus on 6 Sigma quality.

The PRINCE2 methodology, unlike, for example, the PMBOK body of knowledge, does not contain:

• Specialized aspects of project management, such as industry-specific;
• Specific project management practices and tools such as Gantt chart, WBS, etc.

PRINCE2 focuses on the management aspects of the project, expressed in 7 principles, 7 processes and 7 project themes.

• 7 principles define general rules project management according to PRINCE2, define the basis of the methodology;
• 7 processes define the steps for moving through the project cycle;
• 7 topics - aspects on which control is carried out to achieve the success of the project.

At the beginning of the project, PRINCE2 invites us to define 3 main aspects of the project:

• Business aspect (Will this project bring benefits?)
• Consumer aspect (What product is needed, what will we do?)
• Resource aspect (Do we have enough to reach the goal?)

PRINCE2 has a more clearly defined project team structure than most project management approaches. This is due to the fact that PRINCE2 is focused on large-scale government projects and large organizations.

According to PRINCE2, each team member has a distinct role in each of the 7 processes:

• Project start (Starting upa project): During this process, a project manager is appointed and the overall requirements for product characteristics are determined. The project manager, whose primary responsibility is attention to detail, reports to the Project Steering Committee, which is responsible for overall project management. It is the Steering Committee who makes sure that the project does not go off course, and it is also fully responsible for the success of the project.
• Initiation of the projecta project): During this process, the project manager prepares the Project Initiation Documentation, which contains the project plan by stage. The stages can last for different amounts of time, but, as in the classical approach, they follow strictly one after the other.
• Project management (Directing a project): This process provides an opportunity for the Steering Committee to have overall responsibility for the success of the project, without going into details that are within the purview of the project manager.
• Stage control (Controlling a stage): During the implementation of the project, even in ideal conditions, certain changes will be made. The Stage Control process implements one of the principles of PRINCE2 - the principle of control by exceptions. The responsibility of the project manager is to monitor during the implementation of the stage deviations from the planned parameters of the project in terms of time, content, budget, etc. ways out of the situation.
• Product Creation Management (Managing Product Delivery): The Product Creation Management process is the interaction between the project manager and the team manager to create one of the project's products. The responsibilities of the project manager in this process include delegating product creation authority to the team manager and acceptance of the product created.
• Stage Boundary Management (Managing a stage boundary): During this process, the project manager provides the Steering Committee with all the information it needs to evaluate the progress of the passed stage and decide on the transition to the next stage.
• Closing the projecta project): One of the differences between PRINCE2 is that the process of completing a project is not separated into a separate stage or stage, as in the classical approach, but is carried out as part of the final stage of creating a product. The purpose of the process is to confirm that the product of the project has been accepted or that the project can no longer provide anything useful.

PRINCE2 can be adapted for projects of any size and any subject area. The methodology offers specific recommendations for changing the project life cycle, role model and set of required documents in accordance with the needs of the project.

Strengths of PRINCE2

• Adaptability to the specifics of the organization;
• Having a clear description of roles and responsibilities;
• Emphasis on the products of the project;
• Certain levels of management;
• Focus on economic viability;
• Subsequence design work;
• Emphasis on capturing experience and continuous improvement.

Weaknesses of PRINCE2

• Lack of industry practices;
• Lack of specific tools for working on the project.

The best project management system ... for you!

Project management is a science, but science is not the most accurate. In this area, there are no unshakable foundations and universal solutions. If you can find a method that suits your project perfectly, consider yourself lucky, as most less fortunate leaders have to put in the effort to create and customize their own project management systems. These systems can be composed of elements of existing systems, or even created completely from scratch, as in the case of the Apollo mission. The main thing is to use something that will give you at least some structure and will not forget about what is important for your project.

How to get an international certificate in Agile?

For those who want to gain a systematic understanding of Agile, to understand the advantages and disadvantages of an agile approach to projects and products, to find areas of the best use of Agile and to obtain an international ICAgile Certified Professional - our training

Agile development methodology(English Agile software development, agile methods) - a series of approaches to software development focused on usinginteractive development , dynamic formation of requirements and ensuring their implementation as a result of constant interaction within self-organizing working groups consisting of specialists in various fields. There are several techniques related to the class of agile development methodologies, in particular extreme programming, DSDM, Scrum, FDD.

Most agile methodologies aim to minimize risk by converting developmentto a series of short loops called iterations which usually last two to three weeks. Each iteration itself looks like a miniature software project and includes all the tasks necessary to generate a mini-increment in functionality: planning, requirements analysis, design, programming, testing and documentation. While a single iteration is usually not sufficient to release a new version of a product, it is assumed that an agile software project is ready for release at the end of each iteration. At the end of each iteration, the team re-evaluates development priorities.

Agile techniques

Agile methods are such agile methodologies as Lean Development, Scrum, etc. They were developed in the early 2000s as an alternative to ineffective traditional IT methods.

Almost all agile teams are concentrated in one office (bullpen). The office includes the product owner - the customer, who defines the requirements for the product. The customer can be a business analyst, project manager, or client. In addition, the office may include interface designers, testers, technical writers. That is, Agile methods are aimed primarily at face-to-face communication.

The main metric of agile methods is the work product.By favoring face-to-face communication, agile methods reduce the amount of written documentation over other methods

Key ideas:

— people and interactionmore important than processes and tools;

— working productmore important than comprehensive documentation;

— cooperation with the customermore important than agreeing on the terms of the contract;

— willingness to changemore important than following the original plan.

Agile principles:

1.Customer satisfaction through early and uninterrupted supply of valuable software;

2. welcome changes in requirements even at the end of development (this can increase the competitiveness of the resulting product);

3. Frequent delivery of working software (every month or week or even more often);

4. close, daily communication of the customer with the developers throughout the project;

5. the project is carried out by motivated individuals who are provided with the necessary working conditions, support and trust;

7. running software is the best measure of progress;

8. sponsors, developers and users should be able to maintain a constant pace indefinitely;

9.Constant attention to improving technical excellence and user-friendly design;

10. simplicity - the art of not doing unnecessary work;

11. the best technical requirements, design and architecture are obtained from a self-organized team;

12. constant adaptation to changing circumstances.

The main advantages of Agile:

• Web product quality

Involving the customer in the process of each iteration makes it possible to adjust the process, which invariably improves quality.

• High development speed

The iteration lasts no more than 3 weeks; by the end of this period, there is necessarily a result.

• Minimizing risks

A large project allows the customer to pay for several iterations and in the course of work to understand that he will get exactly what he wants on time and at an affordable price. Waterfall models (using specifications and technical specifications) do not give such opportunities.

The customer always has the opportunity to monitor the progress of development, adjust the functionality of the project, test or launch it, he can even stop it at any time.

Postgraduate student of Netology Maxim Pimenov talks about Agile - an agile methodology for software development.

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

In order for the process of creating a program to go right, programmers use methodologies. A methodology is a collection 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 the sprint. During it, the team works on a model close to a waterfall. Each new function is designed and programmed, and then tested and documented. When the sprint is complete, the team has a workable, useful, and improved version of the product.

Before the next sprint, the team is planning the next sprint. At this stage, the customer can add tasks that did not exist before. Agile encourages what is unthinkable for a waterfall: "Requirements change is welcome, even in the later stages of development." At the end of the project, the product can be very different from what was planned at the start.

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

The team works as it wants

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

A team is a single whole that is not divided into specific people. The responsibility lies with the whole team: if they are punished or rewarded, then all at once. The main thing in the workflow is communication. The team sits in one 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 a retrospective. The essence of Agile is not only constant improvement of the product, but also constant improvement of teamwork.

Actually, not everyone loves Agile.

Agile has opponents who don't share the same excitement. The main problem of the methodology is chaos at a distance. After each sprint, priorities change and new tasks appear, so the team has no vision of 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 for sprint tasks. The next time the customer sees that a new James Bond film has blown up the Internet. It adds online cinema functionality to the Sprint. As a result, the architecture of the project sprawls, and the useful effect of the product becomes blurred.

Another problem is bad code. Agile preaches the maximum number of beneficial product changes per unit of time. Since the goal is useful changes, programmers do not have the task of making the code as reliable and understandable as possible.

Agile makes you think 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 an over-disciplined and organized team.

If you forget about philosophy, nothing will come of it.

There is another problem that the authors of Agile are not to blame: the methodology has become too popular and even pop. People say they work in Agile without even understanding its essence. They break up into small teams, cut the project into small tasks, plan sprints, release them regularly, but the number of poor projects does not diminish.

Remember at the beginning of this 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 interactions 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 following the original plan.

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

Agile is a mindset, not a set of advice. Accept Agile, and only then get into practice.

Consisting of 12 principles. Of course, certain provisions of the Agile approach appeared before that, but only this document systematized and set them down to a sufficient extent for use. Each year, new companies, IT specialists and project managers sign up to the manifesto. New methods and modifications of the agile development system appear.

What is Agile Methodology?

Agile is an iterative development model in which software is created incrementally from the very beginning of a project, as opposed to waterfall models, where code is delivered at the end of the work cycle.

The core of Agile is breaking projects down into small work pieces called user stories. According to the priority, the tasks are solved within short two-week cycles (iterations).

The 12 principles that make up Agile Methodology can be divided into 4 main ideas:

• Priority of people and communication over tools and processes;
• Priority of the working product over the complete documentation;
• Priority of cooperation with customers over the approval of the contract;
• Prioritizing willingness to change over adherence to the original plan.

Methods present in Agile:

The term "Scrum" owes its name to rugby, in which this word means a method of team play in the form of drawing three lines by each of the opponents and trying to capture the ball. For a successful interception, not only good physical fitness is needed, but also the coherence of each participant in the bout and a clear understanding of the goal.

The method is successfully used by such companies as Microsoft, Yahoo, Siemens Healthcare, and the project manager at Amazon even described it based on the experience gained.

Since Scrum is a development framework, in each subsequent example it may differ significantly from the previous one.

Jeff Sutherland, author outlined 8 steps for using the technique:

1. Please select product owner- he knows about the purpose of the project and the expected result.
2. Collect command- up to 10 people with the skills necessary to create a workable product.
3. Find scrum masters- he monitors the progress of the project, helps the project team to cope with difficulties.
4. Make up product backlog Prioritize each product requirement on the Agile board. The product owner plays an important role in this, collecting wishes for the product for evaluation by the backlog team.
5. Plan sprints(iterations) - lengths of time to complete a specific set of tasks.
6. Organize daily fifteen-minute "mit-ups"- ask 3 questions to each of the team: what did you do yesterday, what will happen today, what prevents you from completing the task.
7. Do product working parts reviews- with the involvement of stakeholders in reviewing and discussing.
8. Spend retrospective- discussion of the problem and search for a solution after each sprint. Implement the resulting change plan in the next sprint.

Agile Retrospective

Scrum has 4 key elements:

• Product Backlog- list of project requirements
• Sprint Backlog- a list of requirements that need to be met in the next sprint
• Sprint Goal- sprint goal
• Sprint Burndown Chart- a diagram that is updated as tasks are completed. It is easy to understand the dynamics and level of advancement of the team in the project.

(XP)

The developer of the method, Kent Beck, created an extreme programming method, the goal of which is to cope with the ever-changing requirements for software product and improve the quality of development.

It is applicable exclusively in the field of software development, and is built around 4 processes:

1. coding- according to the uniform design standards in the team;
2. testing- tests are written by the programmers themselves before writing the code to be tested;
3. planning- both the final build and individual iterations. The latter takes place on average once every two weeks.
4. hearing- both the developer and the client, during which ambiguities disappear, requirements and values ​​are determined.

Methodologies

A family of methodologies, little known in the domestic open spaces of project management, developed by Alistair Cockburn, one of the authors of the Agile Software Development Manifesto. Cockburn proposes to carry out the classification by color according to the criterion of the number of people in the team: from 2 (Crystal Clear) to 100 (Crystal Red). For larger projects, the colors Maroon, Blue and Violet are highlighted.

Crystal projects must meet 3 main indicators:

1. fast delivery of working code- development of the idea of ​​an iterative model of Agile development.
2. perfection through reflection — a new version The software is improved based on data from the previous one.
3. "Osmotic" interaction- Alistair's innovation, a metaphor for communication and information exchange between software developers in one room.

Dynamic Software Development Method (DSDM)

Not one person or even a team worked on the development of DSDM, but a consortium of 17 English companies. DSDM, like extreme programming, is used primarily for software development.

A special role is assigned to the participation of the end consumer (user) in the development process. In addition to this principle, the basic ones include:

• frequent releases of working versions of the product
• autonomy of developers in terms of decision making
• testing throughout the entire working cycle.

DSDM is divided into versions that are updated as technology develops, new requirements for software development appear. The last one for today is DSDM Atern, released in 2007, although the previous one (2003) is still in service.

At the beginning, the team examines the reality of application development and the scope of the application. Further, the work is divided into three interrelated cycles:

1. functional model cycle- creation of analytical documentation and prototypes.
2. design and construction cycle- bringing the system into working condition.
3. implementation cycle- system deployment.

Feature Driven Development (FDD)

A methodology that even predates the Agile Software Development Manifesto.

Although FDD also uses an iterative development model, it differs from Agile in the following:

• more emphasis on pre-modeling
• increased (compared to Agile) importance of building reports and charts
• aimed at corporate development.

Feature Driven Development consists of the following cyclical stages:

1. Creating a general model- project vision based on preliminary data.
2. Designing a list of properties- an analogue of the product backlog in the Scrum method.
3. Planning by properties- estimation of the complexity of properties by each member of the team.
4. For each property- technical design and implementation - the final stage, at the end of which the property goes into the product and the cycle repeats.

Software Development

Lean Software Development is more likely not a methodology, but a set of lean manufacturing principles, which is aimed at increasing the efficiency of the development process and minimizing costs.

The set includes the following 7 principles:

1. getting rid of losses- anything that does not add value to the product for the end user.
2. continuous learning- continuous development of the team increases the ability to effectively complete tasks.
3. making a decision as late as possible- the priority is not spontaneous decisions, but thoughtful ones, developed on the basis of the knowledge gained.
4. fast delivery- essentially the basis of the iterative model.
5. team strengthening- one of the principles of the "Manifesto ..." states that people and interaction are more important than processes and tools. The project team is the foundation for the successful completion of tasks.
6. integrity and quality- you need to initially make a high-quality product so as not to waste time and resources on further testing and getting rid of bugs.
7. vision of the whole picture- splitting the project into separate parts is impossible without understanding the current development status, goals, concept and strategy of the software being developed.

A variety of agile development methodologies

Agile Modeling (AM)

Agile Modeling is a set of values, principles and practices for software modeling.

AM is used as part of a full-fledged software development methodology - for example, extreme programming or Rapid Application Development.

Agile Modeling principles are as follows:

• effective interaction between project stakeholders
• striving to develop the simplest of possible solutions that suits all requirements
• constant feedback
• courage to make and take responsibility for decisions
• understanding that you do not know absolutely everything.

Agile Unified Process (AUP)

AUP is a simplified version of another software development methodology - Rational Unified Process (RUP). Since 2012, it has been replaced by Disciplined Agile Delivery (DAD), but AUP is still found in some places.

The author of the methodology, Scott Ambler, highlighted the following key positions of the Agile Unified Process:

• Your team knows what they are doing;
• Simplicity comes first.
• Compliance with the principles of agile development methodology.
• Focus on activities that are valuable for the project.
• Independence in the choice of tools.
• Individual customization of AUP for the needs of a specific project.

Agile Data Method (ADM)

ADM is a set of iterative agile software development methodologies that emphasize the formation of requirements and project decisions through the collaboration of individual teams. Like the AUP, it is not a self-sufficient technique.

The essence of the Agile Data Method is defined by six points:

1. Data- the basis for creating any application.
2. Problems with the project- they can be found only with a clear understanding of the purpose and concept of the project.
3. Working groups- in addition to the direct development team, there are enterprise groups that support other working groups.
4. Uniqueness- there is no ideal methodology, for each project you need to combine tools from different methodologies.
5. Teamwork- teamwork is much more effective than alone.
6. "Sweet spot"- search for the optimal solution to the problem ("sweet spot"), avoiding extremes.

Essential Unified Process (EssUP)

Developed by Swedish scientist Ivar Jakobson, designed to improve the Rational Unified Process.

EssUP operates with the concept of practice, which includes:

• use case - a description of the system's behavior.
• iterative development - creating working pieces of code in short cycles of several weeks.
• team practices - aimed at uniting the team and increasing its effectiveness.
• procedural practices such as “Think big, start small” or “Engage stakeholders in business processes.”

All practices are found in one form or another in the RUP, CMMI and Agile development methodologies.

Getting Real (GR)

An effective methodology for startups and novice teams that suggests making the most of the features of small projects and companies: mobility, flexibility, search for new solutions, the absence of a rigid confusing hierarchy, etc. Jason Freed and David Hansson, founders of 37signals (now Basecamp), defined Getting Real as a system for solving real problems: as simple, understandable and functional as possible.

GR is a prefabricated hodgepodge of a dozen Agile development tools that are used to minimize:

• opportunities
• options and settings
• company structure
• meetings
• promises.

The unusual concept has not been widely adopted, although some elements use different techniques.

OpenUP (OUP)

A tool-independent software development methodology without a rigid structure that contains the following practices:

• measuring the speed of the team;
• holding daily meetings and retrospectives on completion of iterations;
• the concept of microstepping and early testing using checklists;
• Agile Modeling Technique (AMDD).

The practices are implemented on the basis of four principles:

Agile metrics

Given the variety of tools, practices, methods and methodologies in Agile, you need to choose a tool that will help determine the effectiveness of each of them. Metrics are such a tool.

For most projects, 4 areas of metrics are enough:

1. Performance- this includes Velocity and WIP. The first is not suitable for all projects, since the number of completed tasks per iteration is measured, and they are unequal. The Work-in-Progress metric determines the limit of tasks for different stages: and the higher it is, the worse;
2. Forecasting- capacity metric: determining the number of ideal hours available in the next sprint. Accordingly, you can understand how much time you have to work, how efficiently the tasks are completed, and how to sprint;
3. Quality- for example, the index of stability of requirements, which is calculated by the formula = ( Total amount original business requirements + Number of requirements that have changed by this time + Number of added requirements + Number of removed requirements) / (total number of original requirements). The metric determines the amount of time spent reworking tasks;
4. Values- in each case it is calculated individually, depending on the format of the project. For example, startup AirBnb chose the number of high-quality photos uploaded as a metric that determines the ultimate value of a product to users. With their increase, the number of consumers grew proportionally.

The same rules apply to metrics as to other Agile tools.

There is no single metric that is right or needed for your project.

They need to be constantly reviewed, obsolete, and new ones added as needed. It should be understandable and accessible to the entire team, not become an end in itself. Metric for metric's sake is a bad decision.

Mythbusters: Agile

The popularity of the Agile family has played a cruel joke on it, and even specialized portals have myths about one or another aspect of Agile. We'll figure out!

Myth # 1: Agile works for all projects.

The most persistent delusion. No Agile method will in itself add value to a product or motivate a team.

Myth # 2: Agile versus documentation.

Agile development is not against documentation, it is against documentation as an end in itself. But when choosing documentation as a means of communication, Agile really gives priority to live communication.

Myth # 3: Agile and planning are incompatible.

Daily scheduling with 10-minute stand-ups, iterative scheduling every two weeks, sprint meetings, etc., is a rebuttal to this myth.

Myth # 4: Agile requires a lot of re-work.

In agile software development, rework comes in two forms: reworking requirements (users understand what they really need) and software (development teams find better ways to write and design an application). But you have to deal with this in other methods as well! Moreover, to reduce the negative impact of rework, an iterative model is needed, which is a feature of Agile.

Pros and cons of using Agile

Pros:

1. involvement of stakeholders- the team has more opportunities to understand the wishes of the client. And early and frequent software delivery strengthens stakeholder confidence in the project team and further engages in the project.
2. early and predictable delivery- the development model through iterations (short intervals from 1 to 6 weeks) gives flexibility, accelerates the release of the product.
3. focusing on business value- Collaboration with the client provides the team with an understanding of how to make the product as valuable as possible for the consumer.
4. continuous quality improvement- testing during each iteration, dividing the final build into separate pieces of working code allow us to improve and deal with software bugs before the final product is released.

Minuses:

• increased requirements for the team and clients- without close interaction between the project team and users, it is impossible to achieve a high-quality product with high value... And the abundance of tools and techniques in Agile requires an experienced team for implementation.
• not suitable for outsourcing and projects where participants interact with each other only online.
• the risk of never releasing the final version of the software- this minus, oddly enough, comes out of iterative development and continuous product improvement - the pluses of Agile.
• does not work without a clear vision of the business goals of the project- since the Agile team is focused on stakeholders, development is impossible without the development of goals and a product concept.

Applications

To manage projects with Not all services or programs for project management are suitable for Agile, because each has its own specifics.

If your business belongs tomarketing and advertising, design, seo or digital agencies then the saas service can be applied to the work of the entire team as a whole. We are recommended .

Here are a couple of life hacks to set up Agile in

1. customize labels and statuses, which are necessary for the work of your company.
   Statuses can be as follows: in progress, checking, done, needs work, critical, feature, pay.
   Tags often look like: layout, testing, production, concept, code.
2. create a backlog project and project spring.
3. create tasks and preliminary checklists, sketches, etc. in the backlog.
4. on mit-ups define spring tasks and transfer them from the backlog into the sprint.
5. use customer guest access to tasks in order to always have consistent and up-to-date comments on the project.
6. celebrate responsible for tasks so that each colleague knows his area of ​​responsibility and feels involved in the result of the sprint.

Verdict

With agile software development, small project teams maximize efficiency. Agile is implemented through other agile methods: Scrum, XP, Lean, etc.

It is impossible to implement it on a swoop, by an inexperienced team, in a short period of time. but the implementation of Agile will improve the interaction between IT and the business, accelerate time-to-market, and increase the value of the product for the end user.