Agile development methodology (from English - Agile software development)- a manifesto that defines the way of thinking and contains the core values ​​and principles on which several approaches (frameworks, from the English. framework- frame, structure) to software development (although recently time is running trend and attempts to apply an agile development methodology to other areas of activity, not only in terms of information technology), implying interactive development, periodic (dynamic) provision (updating) of requirements from the Customer and their implementation through self-organizing working groups formed from experts of various profiles (developers, testers, implementers, etc.). Such a translation of Agile as "agile development methodology" is not entirely correct. usually Agile is not called a methodology, but approaches based on this manifesto are methodologies, but from the point of view of Agile they are called frameworks. On this moment there are many frameworks (methodologies) whose approaches are based on agile development methodology, such as Scrum, Extreme programming, FDD, DSDM, etc.

Definition in terms of BPM CBoK [from English. - Guide to the Business Process Management Common Body Of Knowledge]. Agile- One of the iterative and incremental software development methodologies, as opposed to the traditional linear waterfall methodology. The agile development methodology defines a system of design, development, and testing practices throughout the software lifecycle. Agile development methods (such as SCRUM) are based on rapid response to change through the use of adaptive planning, collaborative requirements generation, streamlining self-organizing cross-functional development teams, and incremental software development with clear time frames. This approach is used in many modern commercial software development projects.

Agile development methodology is based on a liberal-democratic approach to managing and organizing the work of teams whose members are focused on the development of specific software.

Due to the fact that software development using an agile methodology defines a series of short cycles (iterations), with a duration of 2-3 weeks, minimization of risks is achieved. at the end of each iteration, the Customer accepts the results and issues new or corrective requirements, i.e. controls the development and can immediately influence it. Each iteration includes planning, requirements analysis, design, development, testing, and documentation. Usually one iteration is not enough to release a full-fledged software product, but at the same time, at the end of each stage of development, a "tangible" product or piece of functionality should appear, which can be viewed, tested and issued additional or corrective measures. Based on the work done, after each stage, the team sums up and collects new requirements, on the basis of which it makes adjustments to the software development plan.

One of the main ideas of Agile is the interaction within the team and with the customer face to face, which allows you to quickly make decisions and minimize the risks of software development, so the team is placed in one place, from a geographical point of view. Moreover, the team includes a representative of the customer (English product owner - an authorized representative of the customer or the customer himself, representing the requirements for the product; this role is performed by a project manager from the customer or a business analyst).

Release History of the Agile Manifesto

The "Agile Software Development Manifesto" was released and adopted in February 2001 (UTA USA, The Lodge at Snowbird ski resort) by a group of experts. This manifesto defines 4 core values ​​and 12 principles for methodologies based on it, and also provides an alternative vision of the approach to software development in contrast to large and well-known methods and methodologies, but is not a methodology in itself. Usually, Agile is compared primarily with the "waterfall" method, because. at the time of the release of the manifesto, it was the "waterfall method" that was the main one in planning software development. Representatives of the following methodologies took part in the development and release of the Agile Manifesto:

• Adaptive software development (ASD)
• Crystal Clear
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Feature driven development (FDD)
• Pragmatic Programming
• Scrum

Actually, these agile development methodology existed before the release of the manifesto. The release of the manifesto itself gave a new impetus to the development of agile methodologies, laid the foundation, one might say the constitution of an agile approach to software development.

Agile Software Development Manifesto:

The main metric of agile methods is the work product. By prioritizing face-to-face communication, agile methods reduce the amount of written documentation compared to other methods.
This has led to criticism of these methods as undisciplined.

We are constantly discovering better ways to develop software by developing directly and helping others. Thanks to the work done, we were able to realize that:

• 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 negotiating the terms of the contract
• Readiness for change is more important than following the original plan

That is, without denying the importance of what is on the right, we still appreciate what is on the left more.

Manifesto authors:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland Dave Thomas

Fundamental principles of the Agile Manifesto:

We follow these principles:

1. Our highest priority is customer satisfaction through regular and early delivery of valuable software.
2. Changing requirements is welcome, even late in development. Agile processes allow you to use change to provide the customer with a competitive advantage.
3. A working product should be released as often as possible, with a frequency of a couple of weeks to a couple of months.
4. Throughout the project, developers and business representatives must work together on a daily basis.
5. Motivated professionals should work on the project. To get the job done, create the conditions, provide support, and trust them completely.
6. Face-to-face communication is the most practical and effective way to share information both with the team itself and within the team.
7. A working product is the main indicator of progress.
8. Investors, developers and users should be able to maintain a constant rhythm indefinitely. Agile helps to establish such a sustainable development process.
9. A constant focus on engineering excellence and design quality enhances project flexibility.
10. Simplicity - the art of minimizing unnecessary work - is essential.
11. The best requirements, architectural and technical solutions come from self-organizing teams.
12. The team should systematically review possible ways improve efficiency and adjust your work style accordingly.

Criticism of Agile

Agile does not describe requirements management processes well, we can say that such a concept simply does not exist. agile development methodology does not imply long-term planning (planning is carried out for the short term), as a result, the step of forming a product development plan or, in other words, a product roadmap, is skipped. Because short-term planning (for the next iteration of development), and at the end of each iteration the Customer accepts the product and sets new requirements, the product itself can change radically, and the new requirements set often contradict the structure and architecture of the product already delivered to customers. By and large, if the Customer does not fully understand what he wants to see in the end (final product), and understanding comes during development (this happens in 90% of cases), the development process turns into a formalized and legalized bureaucracy, i.e. . the product is improved indefinitely until the money runs out or the customer switches to another product. In fairness, it should be noted that the Customer knows what he is doing and decides whether to pay for product development or not, by and large, the development team simply fulfills the requirements of the customer. However, in reality, in work this leads to chaos, missed deadlines and rush jobs, which gives rise to new requirements that change the product for the worse. Moreover, the quality of the developed product decreases, because Agile defines an approach to development in which fires must be put out quickly, in the simplest and fastest way. The code is written without complying with the requirements of the platform on which the product is being developed, a lot of workarounds and defects appear, and such a design is not very stable and not safe, customer resentment from frequent software failures is growing. Business at the exit receives losses, the quality of planning falls.

Some Agile experts associate more with the approach of improving an already finished product than developing a new one. Agile development methodology has many supporters, just like opponents. The latter at one time even released the Anti Agile Manifesto. Further, for informational purposes, we present the content of the two most popular manifestos that contradict the main Agile manifesto:

Anti-Agile manifesto (it should be noted that this anti-agile manifesto actually contradicts not Agile itself, but rather one of the frameworks based on Agile principles - Scrum, since the terms from this framework are used in the manifesto):

We've had a lot of consultants through us, and we've spent countless hours in agile meetings and meetings. Based on this experience, we realized that Agile is just brainwashing, because:

• epics are just projects
• user stories (user stories) - it's easy use cases
• sprints are just work
• stand ups (stand-ups) are just meetings
• iterations are just versions
• backlogs are just a to-do list
• team speed (velocity) is just the results
• and these tasks (tasks) are real, just tasks

Thus, while the terms on the left side are proposed to be considered innovative, changing the approach to development, they are simply vague concepts of the terms on the right.

Varieties of agile development methodologies

Based on the values ​​and principles defined in the Agile Manifesto, the following agile development methodologies have been formed:

• Agile Modeling (AM)- this approach basically determines the procedures for modeling (including checking the model with code) and documentation in the framework of software development. To a lesser extent, procedures for designing and constructing diagrams in UML are described. the areas of development, testing, project management, deployment and maintenance are also not affected.
• Agile Unified Process (AUP)- a unified version of the RUP methodology (IBM Rational Unified Process), which was formed by Scott Ambler. AUP defines a model for building software within business applications.
• Agile Data Method (ADM)- a set of iterative agile software development methodologies that emphasize the formation of requirements and solutions through the cooperation of various cross-functional teams.
• Dynamic Systems Development Method (DSDM)- an iterative and incremental approach based on the concept of rapid application development - Rapid Application Development (RAD), which focuses on the maximum involvement of the end user in the development of a software product.
• Essential Unified Process (EssUP)- an approach developed by Ivar Jacobson (Ivar Jacobson), contains the methods of iterative software development, with an emphasis on product architecture and team practices (essentially borrowed from RUP, CMMI and Agile Development). The idea is that you use only those practices and methods that are applicable in a particular situation. Based on the selected methods and practices, the target process is determined. Unlike RUP, where all practices and methods are interconnected, in this case there is flexibility and the ability to isolate exactly the necessary elements (methods and practices) from the entire available volume.
• Extreme programming (XP)- the idea of ​​extreme programming is to use the best practices in the field of software development, raising them to a new (extreme) level. For example, unlike the usual practice, when one programmer sequentially checks the written code after his colleague, in extreme programming this check is carried out in parallel, which increases the speed of product release, but also the risks.
• Feature driven development (FDD)- the main limitation that is imposed within the framework of this approach is "each function must be implemented in no more than two weeks." Those. if it is realistic to develop a function in one sitting, then this is good, otherwise this function should be divided into several and implemented gradually.
• Getting Real (GR)- within the framework of this approach, the functional specification procedures used for web applications are excluded. Development starts from the opposite, the interface and design are initially developed, and then the functionality itself.
• OpenUP (OUP)- this approach defines an iterative-incremental method of software development. Developed on the basis of RUP. Within the framework of this method, the development life cycle is defined (launch phase, refinement phase, development phase and handover to the customer). Due to a certain phasing and milestones, the effectiveness of control and monitoring of the progress of the project is increased, as a result, timely decision-making on the project.
• lean software development- this approach is based on the concept of lean manufacturing enterprise management (lean production, lean manufacturing).
• Scrum- one of the most common approaches to agile software development, defines the rules for managing the development process using existing development practices. The emphasis is on the involvement of the Customer in the process (the ability to change or clarify the requirements for the created product after each stage), which allows timely identification of deviations and making the necessary changes.

"Of all the difficulties that NASA faced in putting a man on 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 building the Pyramids at Giza to sending a man to the moon, the most daring human undertakings required the coordinated work of thousands of people. And this implies a complex project management system.

And although only a few of us will face tasks of this magnitude, most of the readers of this blog will experience project management in one way or another. By 2020 PMIs are estimated to be there - 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 needed to achieve a goal – on time and within budget, of course. Whether it's developing new software, running a marketing campaign, or landing a man on Mars, project management makes it possible 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 suit every leader and be convenient for all team members. However, during the existence 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, the article presents the standards, concepts, methods and frameworks that are used in project management. The purpose of this article is to give 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?”- let's 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 - landing a man on the moon. However, the main contributors to this event were the 400,000 NASA employees and the 20,000 companies and universities that worked together on the Apollo mission.

In 1961, John F. Kennedy set the task of landing a man on a satellite of the Earth 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 the NASA book Managing the Moon Program states, the main problem was not “ what to do?", and in that, " how to do so much in such a short time? According to Dr. Max Faget, head of engineering at the 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. So the first step was to “break the project down into manageable steps.”

Then it was important to speed up the execution of each individual 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 it easier to control the project, he decided to break the project into 5 areas: Program Control, Systems Engineering, Testing, Reliability and Quality, and Flight Operations. The control scheme for the Apollo program is shown in Figure 1.

This 5-stage system - called the "GEM Stages" after Dr. Muller's initials - was designed "to focus on testing the product, and developing it with the knowledge that it will be tested," according to Muller himself. Program Control determined what needed to be done, managed the budget and requirements, and managed the relationship of program elements. System Engineering was responsible for the development of new devices and assemblies, Testing was responsible for ensuring that these new elements worked, Reliability and Quality checked the developed elements for compliance with requirements and standards, and Flight Operations was responsible for ensuring that these nodes will work during the flight.

Many were initially skeptical of Muller's method, but he eventually managed to convince the program members of the need to follow this algorithm. This system has shown its effectiveness - the project was completed successfully, and, one might even say, triumphantly, ahead of the stated deadlines. This was only possible by breaking down a large-scale project into manageable, repeatable steps, allowing many individual companies and professionals to work at the same pace. 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. Muller. The Egyptian pyramids and the Great Wall of China are products of project management from prehistoric times. Unfortunately, there is no documentary evidence of how the implementation and management of these projects took place, 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 individual tasks. Like a recipe, you buy the ingredients, mix them properly, cook and serve them. The simplest project management tool is a checklist of actions that must be taken to achieve the goal. Simple and effective.

However, if you are a chef and you are preparing more than one dish, but several, for example, a salad (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 them. items and when they should be ready. And here one of the first comes to the rescue modern instruments project management: The Gantt chart presented on Figure 2.

Invented independently by K O In the role of Korol Adamecki and Henry L. Gantt at the beginning of the 20th century, the Gantt chart shows the project schedule based on due dates and due dates for tasks. Tasks, their durations and relationships are entered into it, and then the critical path is calculated - the longest chain of interconnected tasks that determine the duration of the project. The relationships between the start and end of different tasks are very important - you can't serve soup to your guests until you've cooked it, right?

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

Different projects need different levels of 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 in which it is possible to structure each article, sketch each of them, get feedback, make edits, finish the article, proofread and publish. Instead of managing time and resources, you manage the process.

Agile project management methods 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 the workflow and time and resources - 6 Sigma and Scrum.

Popular project management systems

Throughout the history of project management, many various methods project management for almost any need. Even if you are not going to send a man to the moon and do not have a similar amount of resources, you will still find the right tool for you. The main thing is to understand what is most important for 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 in various fields. There are many methods based on the ideas of Agile, the most popular of which are Scrum and Kanban.

Critical Path: A continuous sequence of activities and events from start to finish that takes the longest time to complete.

Event chain of processes (EPC diagram): a diagram showing the sequence of project work implementation based on the availability and workload of resources

Time reserve: The amount of time by which the start of work can be delayed without affecting the overall duration of the project. Thus, the slack for activities on the critical path will be zero.

milestone (checkpoint,milestone): A key event that marks, for example, the end of a stage. In the Gantt chart, it is denoted by a task with zero duration.

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

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

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

"Classic" or "traditional" project management: The most widely used project management method, based on the so-called "Waterfall" (Waterfall) or cascading cycle, in which the task is transferred sequentially through the stages, resembling a flow.

Classical project management

The most obvious way to make your project more manageable is to break it down into successive steps. It is on this linear structure that traditional project management is based. In this sense, it resembles a 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 the 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 refines and details the goals and results of the project, as well as the scope of work for it. Based on this information, the team creates a schedule 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 to achieve it are determined. For example, in IT projects, a programming language is chosen at this stage. ( In domestic practice, this phase is usually not distinguished, and the term "development" is not used - approx. trans.)

Stage 4. Implementation and testing. At this phase, the main work on the project actually takes place - writing code, erecting a building, and the like. Following the developed plans, the content of the project, defined 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 may consist of a simple transfer of project results to the Client, or a lengthy process of interacting with clients to improve the project and increase their satisfaction, and support the results of the project. The latter refers to projects in the field of customer service and software.

What is described above is the basis on which various project management methods are built. Different projects need different implementation phases – some need three phases, others many more. Sometimes the so-called "iterative waterfall" is used, in which each stage is a kind of subproject, during which tasks are implemented in fixed iterations. But the essence remains the same - the project is divided into stages that 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, calendar-network planning tools are excellent for implementing projects within the framework of 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.

The strengths of the classic project management

Today, it is often said that the classic waterfall approach is outdated, but he does not even think about losing ground. The big advantage of this approach is that it requires the Customer and company management to determine what they want to receive already at the first stage of the project. Early inclusion brings a certain stability to the work of the project, and planning allows you 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 avoids stress due to the presence of spare time at each stage, laid down in case of any complications and the implementation of risks. In addition, with a properly conducted planning stage, the project manager always knows what resources he has. Even if this estimate is not always accurate.

Weak sides classical project management

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

The mainstay of the classical approach now is construction and engineering projects, in which the content of the project remains virtually unchanged throughout the entire project. But if resources and time are not key constraints in your project, and the scope 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 project approach. Going back to our chef example, cooking one dish is perfect for a waterfall approach, but preparing and serving a four-course dinner on time would be next to impossible if you had to wait each time for one dish to finish cooking before starting another.

And this is 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 broken down into successive phases, but into small subprojects, which are then “assembled” into finished product. The scheme of work is shown on Figure 5.

Thus, initiation and top-level planning are carried out for the entire project, and 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 when starting a new sub-project (iteration), you can make changes to it without high costs and impact on the rest of the project.

Despite the fact that Agile came into vogue relatively recently, the idea of ​​iterative development is not new. (about the history of the appearanceAgile can be read - approx. per.). The family of agile methodologies got its current name in 2001 with the publication of the Agile Manifesto (Agile Manifesto), which consolidated the core values ​​and principles of agile software development, which are based on teamwork and adaptation, even “love” for change.

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

StrengthsAgile

The most important advantage of Agile is its flexibility and adaptability. It can adapt to almost any conditions and processes of the organization. This is what determines its current popularity and how many systems for various areas have been created based on it.

One of the principles of Agile is: “Responding to change is more important than following a plan.” It is the 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 like starting a service or a blog.

The realm of Agile is the development of new, innovative products. In projects to develop such products, there is a high degree of uncertainty, and information about the product is disclosed during the course of the project. Under such conditions, it becomes impossible to implement the project on the "waterfall" - there is no information for planning.

Weak sidesAgile

Unlike PRINCE2 and PMBOK, Agile is neither a methodology nor a standard. Agile is a set of principles and values. The weak side is that each team will have to independently compose its own management system, guided by the principles of Agile. This is a complex and lengthy 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 from the leader of change not only knowledge and perseverance, but also serious administrative resources, as well as costs. Fortunately, there are ready-made sets of practices that make it easy for an organization to transform Agile. 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 classical process and the ideas of an agile approach to project management. The result is a very balanced combination of flexibility and structure.

Following the precepts of Agile, Scrum breaks the project into parts that can be immediately used by the Customer to obtain value, called product backlogs. And despite the fact that “product backlog” is a fairly accurate translation and is used in professional literature, in Russian practice, simply “backlog” is most often used. Then these parts are prioritized by the Product Owner - the Customer's representative in the team. The most important "pieces" are the first to be selected for execution in the Sprint - the so-called iterations in Scrum, lasting from 2 to 4 weeks. At the end of the Sprint, the Customer is presented with a working product increment - the most important "pieces" that can already be used. For example, a site with 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 performance.

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 scope that has not yet been completed is re-evaluated and changes are made to it. Everyone is involved in this process - the project team, the Scrum Master (Scrum Master, project team leader) and the Product Owner. And everyone is responsible for this process.

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 the Customer is not present. 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 the outside world and the team. His task is to ensure that no one interferes with the team on their own and comfortably work on the tasks. The team is responsible for ensuring that at the end of the sprint all the necessary tasks are completed and deliveries are completed.

The basic structure of Scrum processes revolves around 5 main meetings: Backlog Sequencing, Sprint Planning, Daily Meetings, Sprint Debriefing, and Sprint Retrospective.

To many, Scrum may seem difficult to implement - a 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, unlike blurry and general principles Agile, will not allow work to go the wrong way.

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 the lack of experience or qualifications of some employees due to information and help from colleagues.

The Netflix online TV channel is a great example of delivering results quickly. The resource site is updated every two weeks thanks to Scrum, which not only allows you to work with high speed, but also accumulates user experience and makes it possible to identify the most important thing for customers.

During each iteration, developers add and test new features of the site and remove those that were not used by customers. According to the Netflix team, the main advantage of Scrum is that it allows you to "fail quickly". Instead of a long and costly major release, scrum deliveries are small in size. They are easy to track and, if something goes wrong, quickly fix it.

Weak sidesScrum

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 competency necessary for the implementation of 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 "idle" 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. Finding such a mature team is very difficult!

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

Lean

Agile tells us what to break into small, manageable packages of work, but it doesn't say anything about how to manage the development of this package. Scrum offers us its processes and procedures. Lean, in turn, adds a workflow scheme to the principles of Agile so that each of the iterations is performed with the same quality.

In Lean, just like in Scrum, work is broken down into small delivery packages that are implemented separately and independently. But in Lean, for the development of each delivery package, there is a workflow with steps 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 qualitative implementation of projects.

Lean stages and their flexibility allow you to be sure that each part of the project is implemented as required. Lean does not have clear stage boundaries, as Scrum does with Sprint limits. In addition, unlike classical project management, Lean allows you to perform several tasks in parallel 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 than something set in stone. Using the ideas of Lean, you can independently create a system that meets your requirements in project management.

StrengthsLean

If you like Agile ideas, but the project requires very smooth 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.

Weak sidesLean

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 Lean applications for large and heterogeneous projects.

Also, unlike Scrum, Lean does not offer a clear workflow for the implementation of “pieces” of the project, which contributes to the stretching of the project timeline. This problem can be solved with effective leadership and clear communications ̶ the main thing to remember is this.

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 industrial production. At the entrance to this process, a piece of metal enters, and the finished part is obtained at the exit. Also in Kanban, the product increment is passed forward from stage to stage, and at the end, a ready-to-delivery item is obtained.

In addition, the creator of Kanban was inspired by supermarkets, namely their principle - "keep on the shelves only what the customer needs." Therefore, Kanban allows you 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 publication date, or a piece of code for a feature that may not be included in the product are all normal for Kanban work.

Kanban is much less strict than Scrum - it does not limit the time of sprints, there are no roles, except for the product owner. Kanban even allows a team member to multi-task, which Scrum does not allow. Also, the 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 steps. In Kanban, they are displayed as columns, and tasks represent special cards. The card moves through the stages, like a part in a factory moving from machine to machine, and at each stage the percentage of completion is higher. As a result, we get a product element ready for delivery to the customer. A board with columns and cards can be both real and electronic - even here Kanban does not impose any restrictions on users.

Your own Kanban system can be as flexible as you want, because in many ways Kanban is a visualization of the Agile idea. But Kanban has 4 pillars on which the whole system rests:

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 per stage: The number of cards at one stage is strictly regulated. Thanks to this, it becomes immediately clear when a “congestion” occurs in the workflow, which is promptly eliminated.
3. Continuous flow: Tasks from the backlog fall into the flow in order of priority. So 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 the constant analysis of the production process and the search for ways to improve productivity.

StrengthsKanban

Like Scrum, Kanban is well suited for fairly tight-knit teams with good communication. But unlike Scrum, Kanban doesn't have hard deadlines, which is good for highly motivated and experienced teams.

At correct setting and management, Kanban can be of great benefit to the project team. Accurate calculation of the load on the team, the correct placement of restrictions and a focus on continuous improvement - all this allows Kanban to seriously save resources and fit into deadlines and budget. And all this combined with flexibility.

Weak sidesKanban

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

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 concept of 6 Sigma in 1986. It is a more structured version of Lean than Kanban that adds more planning to save resources, improve quality, and reduce scrap and problems.

Final goal project - customer satisfaction with the quality of the product, which can be achieved through a continuous process of improving all aspects of the project, based on a thorough analysis of indicators. In the 6 sigma concept, special attention is paid to eliminating emerging problems.

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

• 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.
• Dimension (measure): 6 Sigma is focused on the collection and analysis of quantitative data about the project. At this stage, it is determined which indicators will determine the success of the project and what data needs to be collected and analyzed.
• Study (Explore): During the research stage, the project manager decides how the team can achieve its goals and meet all requirements on time and within budget. At this stage, non-standard thinking of the project manager in solving the problems that have arisen is very important.
• Development (Develop): At this stage, the plans and decisions made at 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 goals. The progress of the project is also measured at this stage.
• Control (Control): A key milestone in the 6 Sigma methodology. Its main goal is the long-term improvement of project implementation processes. This stage requires careful documentation of the lessons learned, analysis of the collected data and application of the acquired knowledge both in projects and throughout the company as a whole.

6 Sigma is very similar to Kanban, only with the established stages of the implementation of tasks - planning, goal setting and quality testing. Most likely, there will be significantly more team meetings with 6 Sigma than with Kanban, but the project implementation process is more structured and it is more difficult for the team to go astray. And like Kanban, 6 Sigma is relatively easy to adapt to the needs of a particular company or team. A strict requirement is only a thorough 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

Six Sigma provides a clear blueprint 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 making better decisions. While data collection, analysis and learning may take some time, it will improve and streamline 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, customer satisfaction often comes to the fore. Given some of the differences in goals at different stages of a project, teams often get confused about priorities, and avoiding this is not easy.

In addition, the main leitmotif of 6 Sigma is: "Everything can always be made even better." This can demotivate employees who do not feel satisfied with the work 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 of analysis and learning may be in vain.

PRINCE2

NASA is not the only government organization 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 methodology PRINCE2 was created. The name comes from the acronym " PR objects IN C controlled 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. When compared to other products, PRINCE2 can be compared to a hybrid of the classical approach to project management and a focus on quality from 6 sigma.

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

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

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

• 7 principles define the general rules for managing projects according to PRINCE2, define the basis of the methodology;
• 7 processes define the steps to progress project cycle;
• The 7 topics are the aspects that are monitored to achieve the success of the project.

At the beginning of a project, PRINCE2 asks 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 achieve 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 General requirements to the characteristics of the product. The Project Manager, whose primary responsibility is attention to detail, reports to the Project Steering Committee, which is responsible for the overall direction of the project. It is the Steering Committee that keeps the project on track and is fully responsible for the success of the project.
• Project Initiationa project): During this process, the project manager prepares a "Project Initiation Document" that contains the project's phased plan. Stages can last a different amount of time, but, as in the classical approach, they follow strictly one after another.
• Project Management (Directing a project): This process allows the Steering Committee to take overall responsibility for the success of the project without getting bogged down in 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 management by exceptions. It is the responsibility of the project manager to monitor during the implementation of the stage deviations from the planned project parameters in terms of time, scope, budget, etc. If these deviations exceed the authority given to the project manager by the Steering Committee (in PRINCE2 terminology - tolerances), the project manager is obliged to inform the Steering Committee and propose way 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 products. The responsibilities of the project manager in this process include delegating the authority to create the product to the team manager and accepting the created product.
• Stage boundary management (Managing a stage boundary): During this process, the project manager provides the Steering Committee with all the necessary information to evaluate the results of the passed stage and decide on the transition to the next stage.
• Completion of the project (Closinga project): One of the differences in PRINCE2 is that the project completion process 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 product creation. The purpose of the process is to confirm that the project product has been accepted, or that the project can no longer deliver anything useful.

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

Strengths of PRINCE2

• Adaptability to the characteristics of the organization;
• The presence of a clear description of roles and distribution of responsibilities;
• Emphasis on project products;
• Certain levels of management;
• Focus on economic feasibility;
• Sequence of project work;
• Emphasis on capturing experience and continuous improvement.

Weaknesses of PRINCE2

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

The best project management system ... for you!

Project management is a science, but the science is not the most exact. There are no unshakable foundations and universal solutions in this area. If you manage to find a method that suits your project perfectly, consider yourself very lucky, because most of the less fortunate managers have to put in the effort to create and customize their own project management systems. These systems can be made up of elements existing systems or even created completely from scratch, as in the case of the Apollo mission. The main thing is to use something that gives you some structure and allows you to remember what is important for your project.

How to get an international certificate in Agile?

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

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

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

When we use Scrum with professional teams, we most often choose a 2-3 week cycle with retrospective meetings 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 which we build our work with products, with processes within the organization.

(Managing Partner of ScrumTrek Alexey Pimenov on Rusbase)

A word to the experts

Vladimir Ovelyan

Owner and CEO Dostaevsky

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

Scrum allows you to develop in employees necessary qualities– proactivity, independence, organization, sociability and foresight. The main meaning of the method is the performance of 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 employee 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 managers and specialists involved in the project spent the whole day in the meeting, discussing the achievements, challenges and upcoming tasks in the new sprint.

Now we are actively implementing the kanban method in the company. The purpose of implementing kanban is to increase the flexibility of production, to better adapt to changing market requirements. In practice, the method helped us achieve a match between stocks and products actually used in production.

Vitaly Sotnikov

Creative Director of the Bureau of Visual Communications "Chernika"

Ilya Shikhaleev

Lead Developer and Scrum Master iSpring

Scrum brought rhythm and understanding to our team - we make it or we don't make it on time. We see the speed of the team's work, there is no feeling of constant fakap. Previously, there were situations when scrum disappeared somewhere before hard releases and everyone just started to screw up - now we have lost it, there is a constant feeling that we are on time. If there are risks, we discuss them with the PD at an early stage, 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, according to the sensations, we began to do more. We understand that when you have a feeling that you do not have time, you feel that you need to work more - 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 hung 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 completed, they are moved to subsequent paragraphs. And a happy ending - the final point "done". This helps build the big picture and gives you the opportunity to see what each participant is working on.

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

All participants also evaluate 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 certain time (Daily Scrum), where each team member briefly talks about what he is going to do today, what he did yesterday (and whether he encountered 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 the strategy.

An example of philosophy Agile is the principle of operation of the famous Toyota plant, where any subordinate could stop the conveyor and make adjustments. ()

Many consider this method of project implementation to be the only true one. The basis for such a statement is the involvement of each participant in general process. At any time, a member of the project team has the right to make a proposal or make changes to the project.

Often, when creating a product, people responsible for certain stages of the project conflict with each other. When problems are found, developers blame other team members.

The innovative Agile methodology involves all participants in the work, while maintaining their usual responsibilities. The approach aims everyone at achieving a result in the form of a product that satisfies the customer.

Such a methodology can change the business culture of the entire company, rallying the team, which will subsequently become effective in the market.

TO characteristic features Agile includes differentiation of possible risks, self-organization, predictability, prompt responses to transformations and stable interaction (feedback).

To date, there are two fairly widely used ways to establish a working relationship with a client - fixed price contracts and time and materials. A fixed price agreement shifts responsibility for possible risks to the counterparty, the second provides for payment by the client for services performed, which may adversely affect the final result.

Predictability overrides long-term planning, firm deadlines, and a set final price. The Agile methodology calls for defining black box tasks with a given amount of input information and an allotted time to demonstrate the achieved result. At the beginning of the process, participants evaluate the task and take responsibility for the result.

Feedback has the main problem, which is the inability of the customer to correctly formulate the task. Even a well-documented plan can become outdated after a few months of development. The restructuring of the initial concept will probably involve lengthy revisions and reworking of the results.

The methodology states that even after the initial stage of work according to the plan, the product will not have the declared functionality, which will allow the client to comment and make adjustments starting from the starting line of the project. After going through two stages of development, you can run a test version of the product to get feedback. An additional feature here is the almost instantaneous reaction to functional changes.

Self-organization contributes to the elimination of an excessive management structure, the absence of the need to control team members, each of whom takes on a certain responsibility. This will be a guarantee of performance and a high quality product. However, many people make mistakes.

History of Agile

in 1970, Dr. Winston Royce introduced the technique of "management of the development of large software systems". Since then, the concept of Agile has been around. The full history of the development of project management is described in

Something about the Scrum method

Benefits of Agile Development Methods

• Improving the quality of results
• Adapting to change
• Very fast and efficient
• More controllable project schedule

Core Principles of Agile

1. User engagement is critical;
2. To make decisions, teams must be highly effective;
3. Staged and cyclical as a basis;
4. Concentrates on frequent presentation of the intermediate results of projects;
5. The 80/20 work rule applies;
6. Using a collaborative approach to implement the plan;
7. Completion of a single stage, to move on to the next one.

We also brought out the 12 main principles of the Agile methodology in a separate infographic. You can see

Characteristics of the technique:

• Iterative
• Modular
• Increasing
• Adaptive
• Combining Mistakes in implementing agile project management methods are described in the article

Why Use Agile?

• Growth cash flow
• Risk control
• Reduced time and overhead
• Increasing accountabilityFor how to use Agile for development, read the article

Which project management methodology is right for you?

Often the secret to a project's success lies in the right project management methodology.

The choice of an effective management system for quality implementation is critical for any project.

But when you have the choice between waterfall and agile planning, how do you know which one is best for your project and team.

To help you decide, we've compiled a list of pros and cons for each method.

Waterfall Project Management Methodology

Waterfall methodology requires detailed planning at the beginning of the project

All stages are known and logical dependencies are built between them, and you proceed to the next step only after the completion of the previous one

Benefits of Waterfall Project Management

• Best suited for projects that deal with physical objects, from construction projects to equipment installation projects
• Requirements are described at the beginning of the project
• Best for projects with clearly defined tasks and milestones that need to be completed in a specific sequence (e.g. build the first floor of a building to the second floor)
• No involvement of the customer in the development process is required
• Project schedules can be used in the future, for identical or similar projects
• The full scope of requirements is known in advance
• The results defined in the TOR reduce the likelihood of imperfections

Disadvantages of classical project management methodology

• Requires significant effort for quality project planning and scheduling prior to commencement of work
• The client sees the results of the work only at the end of the project and may be dissatisfied
• Project scope changes can be lengthy and require formal change management
• The client may have problems with the vision of the project at the very beginning
• Late TOR changes cause budget overruns
• Late changes to the TOR extend the project timeline
• The method is less effective for projects in the service sector, software, design and other projects in which there are no physical objects.

Agile - project management methodology

Agile is a fast and flexible approach to project management based on the principles of collaboration, adaptability and continuous improvement.

Unlike the orderly stages of waterfall planning, Agile principles tend to be implemented in fast, iterative product release cycles.

Benefits of Agile Project Management Methodology

• The best methodology for projects that deal with service-oriented and non-physical deliverables, such as coding, copywriting, or design
• The project is transparent and understandable for the client at all stages
• Great for a quick start
• Provides fast course correction based on feedback with stakeholders
• Priorities focus on the benefit to the client's business
• The project gives the team freedom of action in order to work creatively and efficiently.
• Involving the client in the project gives development focus
• Includes interaction and collaboration with all members of the project team

Disadvantages of Agile Project Management Methodology

• The team is involved in the project all the time
• Not suitable for projects with well-defined requirements and scopes
• Uncertainty in the scope and timing of work can make Customers and management nervous (at the beginning)
• The client may not have time to get involved in the project
• Requires constant tracking of work and documentation of team task management
• The customer can review the scope of work
• Fast startup may result in incomplete execution of tasks

The project management method you choose will vary depending on the project, team, and goals. Once you've chosen your management style, make sure you're using project management software that allows you and your team to set up the project the way you want.

Good luck with your projects!

Combining Agile and Flow Methodology

The success of the project implementation largely depends on the chosen methodology and the level of training of the project manager. A methodical approach to software development reduces the amount of clutter in the process and therefore ultimately leads to shorter development times and better quality.

Projects often use a combination of an agile and waterfall product development life cycle model, an agile methodology for developing small milestones, and a streaming methodology for implementing the entire project.

Service delivery process

1. Problem definition
Company developer should understand and define the problem that the client is trying to solve as accurately as possible. To a large extent, correctly defining the problem is half the solution.

2. Definition of a solution
It is necessary to consider several options solutions and offer to the client. Settle on the offer that best solves the business problem and delivers the most value.

3. Market check
You need to check the proposed solution with marketing tools such as identifying the competitive environment, industry trends and target customers. This is done in order to reasonably confirm and strengthen the proposed solution to the client.

This is an optional step, you can involve third-party companies by marketing research, use the initial expert data of the customer (if available) or monitor open data sufficient to confirm the concept. With a constant flow of projects, you can start your own analytics department and offer it as a separate service.

4. Solution development
The development team starts working on a solution.

Agile development methodology (agile framework)

Managing complex software development projects involves efficient use of resources, task prioritization, accurate timing, and risk management. Agile methodology is used to reduce risk and increase customer value.

With the use of Agile methodology, various aspects of the team's activities are integrated, this ensures that the whole concept is based on well-defined goals, and approaches and methods of work are constantly being improved. The methodology divides the entire development process into small stages and iterations with constant integration of all developed components. The features include a cycle of sequential design and periodic reviews, clarification of requirements and development of the final product. The agile methodology also ensures continuous improvement based on customer feedback to avoid any surprises later in the life cycle.

The uniqueness of the combined methodology:

Using Agile methodology at every step leads to cost and resource savings for both the client and the contractor.

Using the waterfall model for major project leads to control over the overall results.

Providing quick feedback between the client and the development team.

fast and frequent prototyping.

Customer driven approach – focus on minimizing total cost of ownership (TCO) and maximizing return on investment (ROI).

Send your good work in the knowledge base is simple. Use the form below

Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.

Posted on http://www.allbest.ru/

Posted on http://www.allbest.ru/

• Introduction
• 1. Analysis of approaches to project management based on classical and flexible methodology
• 1.1 Introduction to agile project management methodologies
• 1.2 Criticisms and issues of agile project management
• 1.3 History of the development of views on agile methodologies
• 1.4 Agile methodologies versus traditional project management approach
• 1.5 Key Success Factors for Agile IT Projects
• 1.6 Situational approach in project management in the field of information technology
• 1.7 General description of IT projects
• 1.8 Features of project management in different countries
• 1.9 Ethnocultural features of project activities in Russia
• 1.10 Transition to agile from a traditional project management approach
• Chapter Conclusions
• 2. Empirical study of KFU for IT projects
• 2.1 Research methodology
• 2.2 Research hypotheses
• 2.3 Description of the interview process
• 2.4 Analysis of results
• 2.4.1 Demographics of respondents
• 2.4.2 Reliability test of model variables
• 2.4.3 Analysis of correlations of independent variables with project success
• 2.4.4 Building a multiple linear regression model
• 2.5 Interpretation of results
• Chapter Conclusions
• 3. Practical recommendations
• 3.1 Tips for moving to an agile methodology
• 3.2 Recommendations for conducting a qualitative retrospective
• 3.3 Self-regulating team as a way to speed up the decision-making process
• 3.4 Situational approach in project management practice
• Recommendations for future research
• Chapter Conclusions
• Conclusion
• List of used literature
• List of illustrations
• Annex 1. Questionnaire
• Appendix 2. Diagrams of regression residuals
• Annex 3. Survey results
• Annex 4. Interpretation for survey results

Introduction

Today we live in a world in which information has become the main product and resource of society. The activity of almost all companies is somehow connected with its processing, storage, production and use. Thus, information technologies have firmly entered our lives, have become an integral part of it. The information society is characterized by an enormous speed of development and change. This was not observed a few decades ago: an engineer could get an education, and this knowledge was enough for him for a lifetime. Now there is a need not just for periodic advanced training, but for lifelong learning. In short, the pace of environmental change has increased greatly, so there is a need to cope with environmental change. So in the field of software development (SW), over time, the concept of agile development appeared. It made it possible to adequately cope with changes in the environment and create a product that the customer needed.

Now this concept has significantly outgrown the scope of software development and has become, in fact, some alternative to the traditional approach to project management in all areas. But it is especially popular in the field of information technology (IT), due to the dynamism of this area. However, despite the growing popularity and the current rate of change in the business environment, many companies still adhere to the traditional approach. Agile (flexible) approach is usually unfamiliar for them, so the transition to a new methodology can be difficult. In such a situation, it is useful to have a set of key points that you should pay special attention to. In the literature, they are called key success factors (KSF). In the foreign literature there is a significant number of works on this topic, but in Russia this area is just beginning to develop, so there are practically no works on this topic. While socio-cultural factors corresponding to different countries greatly affect the management process. And you should take this into account when working with projects.

The purpose of this work is to fill a gap in research: to consider the key success factors for IT projects using agile methodologies in Russia and provide recommendations for their practical use.

To do this, you will need to complete the following tasks:

1. Identify probable CFUs using literature analysis.

2. Conduct in-depth interviews with managers to clarify and supplement KFU.

3. Design and conduct an online survey of IT project managers working with agile methodologies

4. Analyze the results.

The object of the work is the key success factors of projects.

The subject is the key success factors for an IT project using agile methodologies.

In order to form recommendations for agile project managers, it is necessary to identify the factors that have the greatest impact on project success. It is important to do this precisely by relying on Russian managers, since management differs in different countries due to socio-cultural factors. Therefore, it is necessary to collect primary information: there is no secondary information.

The collection method is a survey of project managers in IT regarding their project carried out using agile methodologies. The survey was formed in 3 stages:

1. Formation of the primary list of KFU based on the available literature

2. Refinement of KFU during an unstructured interview with 3 project managers

3. Compilation of the questionnaire and pilot testing

The data obtained was analyzed for the presence of a relationship between the success of the project and various variables. Correlation coefficients and regression analysis carried out using SPSS were used as methods of analysis.

The results of the study will be useful both for managers who are already working with agile methodologies, and for those who are just going to apply them in one of their future projects or implement them in their organization. In the first case, the recommendations developed in the work will allow diagnosing problems, if any, and reconsidering what aspects of the activity require the most attention. For beginners, it will be useful to use the recommendations as a starting point and for correctly placing emphasis in a future project.

Structurally, the work is divided into 3 large chapters. The first - theoretical, is an analysis of the existing literature on this topic, mainly from foreign sources. The greatest attention was paid to articles from the International Journal of Project Management and specialized journals related to software development. The second chapter is a detailed description of the research methodology, analysis and interpretation of the obtained sample data. The third chapter is a set of recommendations for practitioners based on the findings of the study.

The scientific novelty of the work is due to the practical total absence published research on agile project management methodologies in Russia in general. While it is absolutely necessary to take into account socio-cultural factors when managing agile projects. managerial informational linear regression

1. Analysis of approaches to project management based on classical and flexible methodology

1.1 Introduction to agile project management methodologies

IT project management methodologies can be broadly divided into two approaches:

· Traditional

Flexible (iterative)

Traditional - based on fairly rigorous project planning before launch and minimal intervention after. With this approach, each subsequent phase begins after the previous one: implementation after planning, and so on. At the same time, there is no return to earlier phases, which is why this method is sometimes called the waterfall method. The traditional approach correlates with the classic project management standard from PMI - PMBoK. In particular, it describes the process of defining project management well:

The application of knowledge and skills, tools and techniques to project work to meet project requirements.

Agile methodologies, in turn, are less tied to planning and involve a completely different life cycle - iterations. This approach allows you to work more efficiently in a rapidly changing business environment. The main difference is a look at the changes at different stages of the project. With the traditional approach, changes at a later stage are undesirable and costly. Agile methodologies - encourage change at all stages. This makes them more competitive in the current realities.

Today, agile methodologies are a good alternative to the traditional approach and are widely used in various high-tech areas, especially in IT. The reason is the fact that the traditional approach is experiencing significant difficulties when the requirements for the project can change at almost any stage, as it is necessary to respond to a rapidly changing environment. An even more complicated case - the end result of the product is not entirely clear, that is, it is necessary to develop without knowing fully what will happen. Agile methodologies in such situations look more preferable.

The practice of using methodologies also confirms these conclusions: the share of Agile projects in the total array is steadily growing (from 2% in 2002 to 9% in 2010), while traditional approaches are losing popularity, which is especially noticeable in the field of application development.

Project management exists at various levels of the hierarchy. In view (Maylor, Brady, Cooke-Davies, & Hodgson, 2006) it looks like this:

Figure 1. Project environment

Initially, this scheme was aimed at software development projects, but it exists in approximately the same form in other projects in IT. It is clear that (Maylor, Brady, Cooke-Davies, & Hodgson, 2006) single out specific Agile methodologies like SCRUM and XP as team level methodologies. However, some researchers tend to look at SCRUM as a more general methodology that applies to the project manager level as well (Barlow et al., 2011). A number of researchers are also considering Scrum in areas other than IT. This methodology also shows good results in other areas, such as construction (Owen, Koaskela, & Henrich, 2006).

1.2 Criticisms and issues of agile project management

However, the agile approach to project management also has certain disadvantages, noted by many researchers. In particular (Coplien & Harrison, 2004) note that many managers today are "like lemmings" following the latest trends, instead of caring about using the optimal approach. In addition (Coplien & Harrison, 2004) are concerned that Agile is moving away from the principles laid down in the Manifesto. Increasingly, the desire is directed at the very fact of applying the agile approach without understanding the principles underlying it.

As one of the main risks of an agile project (Boehm & Turner, 2003) identified possible mistakes during development, as it becomes more difficult to control from the outside due to the lack of documentation.

There is a point of view that due to the fact that an agile project requires a more technically prepared and fairly independent team, the success of the project is largely due to this fact, and not to the application of any methodology (Cohen, Lindvall, & Costa, 2004) . In this case, most studies regarding the effectiveness of the approach become biased.

1.3 History of the development of views on agile methodologies

Agile methodologies - a whole set of different methods: SCRUM, Xtreme programming, Lean and others, but they are united by their correspondence 4 basic principles described in the Agile Manifesto in 2001:

· People and interaction are more important than processes and tools

A working product is more important than comprehensive documentation

Cooperation with the customer is more important than negotiating the terms of the contract

Willingness to change is more important than following the original plan

However, Agile did not appear in the minds of a few people in 2001, in fact, the history of its development has several dozen, and Manifesto was only a consolidation of the foundations.

The imperfection of the existing approach was recognized long before 2001, and attempts were made to apply new approaches. Already in the 1970-1980s, iterative and incremental methodologies were used, which had serious advantages in the speed of project implementation and their efficiency. For example, EVO, RAD, DSDM - all these methodologies are very close to the ideas of flexible project management, they appeared and were used long before the manifesto. Many even had some success: in 1988, the company introduced its Rapid Iterative Production Prototyping (RIPP) methodology, thanks to which they were able to significantly reduce software development time. The company guaranteed customers a finished product within 90 days or a money back guarantee.

The most interesting part of the article looks like a table comparing the principles from the Agile Manifesto with the methodologies of previous approaches. Relatively new only 2 points out of 12, and all the rest have already been noted or even applied in the methodologies mentioned above. In other words, most agile principles are the result of several decades of developing alternative approaches to project delivery.

An excellent review of empirical papers on the topic of Agile methodologies has been presented (Dybe & Dingshur, 2008). 1996 papers were found, 36 of which were found to be empirical and were selected for analysis. In the course of a detailed review and systematization, the authors concluded that there is a lack of high-quality empirical research on this topic.

1.4 Agile methodologies versus traditional project management approach

Despite a fairly long period of successful application in various projects, many managers are still skeptical of agile methodology and prefer traditional methods. This position is partially justified: all projects are unique and require a different approach. This aspect is well described in the article (Fernandez & Fernandez, 2008). The answer to the question lies in the application situation. The authors identify 4 types of project initial conditions:

1. The goal and the way to achieve it are defined

2. Definite goal, no path to reach

3. A certain path, without a specific goal

4. Uncertain goal and path

In different situations, the traditional approach may be more effective, while in others it may be more flexible. In a standard project with a clear and easily achievable goal, the traditional approach may be more efficient and easier, since future changes are unlikely. In a situation where something is unknown, there is uncertainty. The traditional approach is not very effective in such a situation: risks increase, since the cost of change is very high. In a situation of uncertainty of the goal, or the path, or all together, agile methodologies perform better, as they support changes at all stages and do not require full understanding. end result at the beginning. The team, together with the customer, can achieve the desired result during the creation process, which significantly reduces the risk of receiving an outdated product. The authors of the article also note that, in addition to solving problems, flexible methodologies provide certain requirements for the organization, managers, and teams. Agile involves solving many problems in autonomous teams, which means that the leader and organizational structure must allow this, not to mention a certain maturity of the team itself.

1.5 Key Success Factors for Agile IT Projects

When a manager who has previously followed a traditional methodology in his work decides to apply an agile approach to the next project, the key question that arises is what factors he and the team should pay attention to. There are many aspects that certainly cannot be omitted, but for the effective application of the new methodology, it is important to know which ones should be given maximum emphasis. At the same time, in the Agile Manifesto, on the contrary, important principles are described too abstractly and are not applicable directly to the work. For future application, more specific recommendations are needed, so there is already a significant body of work that describes the key success factors for projects.

There are many points of view on the concept of project success, but the most well-known and recognized in project management are 3 indicators: cost, time, quality. This approach is often called the design triangle and is depicted as follows:

Figure 2. Design triangle

Such a graphical interpretation demonstrates the relationship of these components and their mutual influence: attempts to reduce the time for project implementation lead to a drop in quality or an increase in cost, etc.

Daniel (1961) was the first to propose the concept of a key success factor in his Harvard Business Review article "Management Information Crisis". In more detail, the term was revealed (Rockart, 1979):

Key success factors are "several key areas in which a positive result is needed in order for the organization to succeed." Thus, these are the most important areas for management, attention to which is critical for the successful implementation of the project. These are the same 20% that bring 80% of the result according to the Pareto principle.

It should be noted that the KFU model is a relatively good model, but, like any other model, it has some drawbacks and simplifications:

Single factor. The model takes into account each factor separately, while the relationship between factors is equally important (Nandhakumar, 1996)

Static. The model assumes that an implementation or project does not change over time, while in practice at various stages one or another factor may be most important for success (Larsen & Myers, 1999).

Key success factors (KSF) for project management are quite well covered by various authors. (Fortune & White, 2006) In their article, they analyzed 63 publications and identified the most popular KFU. It turned out that the researchers were not unanimous in their opinions: leadership support, clear and realistic goals, a detailed plan - the factors that received the most mentions occurred all three together in only 17% of the works.

In the field of IT projects, there is also a certain layer of work on this issue, however, in this case, there is no consensus among researchers. (Misra, Kumar, & Kumar, 2009) In their work, they conducted a large-scale study of key success factors in projects using agile methodologies. The authors focused their attention on software development, but there are no significant obstacles to extending the findings to the IT sphere as a whole.

In addition to an unprecedentedly large sample of 241 respondents, the strength of the study is the structure of 14 key success factors for Agile projects, which was built on the basis of an analysis of existing work and tested using a survey.

(Misra, Kumar, & Kumar, 2009) The following factors were identified as the most significant:

1. Customer orientation

2. Decision time

3. Distribution of the team (geographical)

4. Team size

5. Corporate culture

6. Planning and control

7. Competence

8. Personal characteristics

9. Communication and negotiation

10. Socio-cultural characteristics

11. Knowledge and learning

In other articles on this topic, as a rule, approximately the same factors are highlighted. Differences are mainly in wording and hierarchy: some factors are given more importance.

The main contradictions among researchers arise in relation to 3 factors:

The distribution of the team

Team size

Knowledge and training

Different points of view are expressed - (Dybe & Dingsшyr, 2008) note that it is important not only to place the whole team together, but also the buyer, as this allows for detailed discussion of all working moments. In turn (Misra, Kumar, & Kumar, 2009), despite the inclusion of this factor in the theoretical model, they did not find practical confirmation of the significance for the success of the project. The same result was obtained (Livermore, 2008) in his study. Thus, it is worth noting that the location of the project team in one place is an aspect requiring further study.

(Misra, Kumar, & Kumar, 2009) Nor did they find a significant correlation between project success and team size, although the prevailing view in the literature is that Agile methodologies were developed and applied to small teams.

(Livermore, 2008) noted that Scrum, as one of the flexible methodologies, is applicable to both large projects (and, accordingly, teams) and large ones, unlike Extreme Programming and others.

There are also conflicting points of view on the knowledge and learning of the team: on the one hand, an experienced team shows better results (Wysocki, 2012), which is quite expected and confirmed by research. On the other hand, teaching exactly the methodology does not look so unambiguous. (Livermore, 2008) found a significant correlation between project success and learning, while (Misra, Kumar, & Kumar, 2009) found no support for this position in their empirical study. It is worth noting that the samples in both cases were statistically significant and had a large number of respondents from different regions (more than 100 and more than 200, respectively)

1.6 Situational approach in project management in the field of information technology

Every year the variety of projects increases - by business area, scale and other factors. In response, managers are developing new methods for managing these projects. Reliable control is possible only when control system has a variety of actions not lower than the variety of probable actions of the controlled system. This is the "Law of Necessary Variety" stated in more understandable terms, formulated by the mathematician William Ashby in his book "Introduction to Cybernetics". It was originally formulated for technical systems and sounded as follows: “The diversity of outcomes [situations], if it is minimal, can only be further reduced by a corresponding increase in the diversity available to the regulator” (Ashby, 2015) in Chapter 11. But the same law also works for other systems, such as an organization or a project, later it was even called the "First Law of Management." Thus, for effective management it is necessary to increase the variety of possible actions - to use different methodologies and their combinations.

Many researchers and practitioners still believe that projects are similar to each other and can be managed in the same way (Shenhar, 2001). However, the situational approach is gaining more and more popularity, according to which it is necessary to select a methodology for each project individually, depending on a number of factors: environmental conditions, characteristics of the organization and the project itself. With a growing number of alternatives when choosing a methodology, project managers face the difficult task of choosing the right option.

(Howell et al., 2010) in their work, based on the analysis of the literature, proposed a model that allows you to correlate the features of the project and the most effective methodology.

Figure 3. Chart Uncertainty - Consequences

The horizontal axis represents the degree of uncertainty, and the vertical axis represents the significance of the consequences. These 2 dimensions include all the factors identified by the authors in the analysis of the literature:

The degree of uncertainty includes the uncertainty, complexity and urgency of the project

· The significance of the consequences - the criticality of the consequences and the responsibility of the team.

On the chart, each methodology has a "comfort zone" within which it is most successfully applied. For example, for Agile, these are projects of any level of uncertainty that do not carry serious consequences, i.e. the failure or success of which will not jeopardize the existence of the company. In case of overlapping zones, it is recommended to apply a methodology that is simpler and cheaper to apply.

In practice, managers do not use the same methodology in its purest form - more often it is a combination of two approaches. A certain tool can bring a certain benefit to the project, if applied in the right conditions.

This hybrid approach was explored (Baird & Riggins, 2012) in the articles “Planning and sprinting: Use of a hybrid project management methodology within a CIS capstone course". As project teams, the researchers were groups of students who carried out a specific project. This fact, of course, imposes some restrictions on the application of the results: it is difficult to transfer them directly to the business sphere.

The hybrid approach of the authors was as follows: the project is carried out in short iterations with a sprint backlog and a presentation of the received work to teachers after each sprint. The difference from Scrum in this case was in the first sprint: instead of trying to create a product right away, from scratch, during the first iteration, students produced a plan - a presentation of further work. As conceived by the researchers, this approach was supposed to help students in the early stages, without losing the benefits of scrum and the possibility of unhindered even late changes.

The results of the study showed that both teachers (conditionally representing clients) and team members were satisfied with the implementation process and the final product. The researchers have shown how to overcome some of the problems of agile project management, for example, one of the most important - the difficulty with long-term planning. In Scrum, planning is done mainly for the current sprint, and not for the long term. This problem was partially solved by changing the goal of the first sprint to the production plan. Although the researchers noted a slight decrease in motivation due to this process, the benefits of planning outweigh this factor.

1.7 General description of IT projects

First of all, it is worth defining what the concept of IT includes. IT - information technology is commonly referred to as everything related to the processing, storage and use of information, but recently, due to the development of computer technology and the Internet, IT is primarily associated with them. In this work, an IT project will be understood as projects in the field of software development, information security, and corporate systems.

IT is one of the fastest growing areas today. Companies cannot do without various systems(security systems, CRM, ERP systems) and servers that support business, and without sites and pages in social networks. To date, a significant number of projects in the IT field are completed with an excess of budget, deadlines, or turn into a complete failure. According to the CHAOS Summary 2010 report (“CHAOS Summary 2010,”[Electronic resource] 2010), only 37% of projects are completed successfully. Another 42% are experiencing time, budget, or quality issues, and the remaining 21% are considered completely failed. Although there is a certain positive trend, there are no major improvements yet. 37% is quite a small part of the total number of projects. This report mainly focuses on software development projects, but a similar situation is observed with other projects.

One of the distinguishing characteristics, in addition to rapid development and change, is the degree of criticality of the consequences. For IT projects, it differs much more than in other areas: the project of access to systems state statistics and the development of a flight control system have very different consequences of an implementation error. In construction, for example, projects that are interesting from the point of view of management are, as a rule, critical and have serious consequences that can ruin the company.

1.8 Features of project management in different countries

To date, quite a lot of influence is given to socio-cultural factors that affect the management of an organization or project. The concept of national economic culture as a set of norms and values ​​in the field of economic activity is one of the key ones within the scientific discipline "Organizational Behavior".

The most popular typology of organizational values ​​was presented by G. Hofstede: in his terminology, 5 indices are presented, which depend on national culture.

individualism - collectivism

power distance

avoidance of uncertainty

femininity - masculinity

・Long-term orientation

Initially, 4 dimensions were singled out, the last - Orientation to the long term, was added in subsequent works. The data for the analysis of cultural values ​​were obtained by the authors largely by chance, when he worked as a psychologist in a large transnational corporation - IBM, and was doing research there. During the period from 1967 to 1971, more than 116,000 employees from many countries were analyzed.

Let's take a closer look at each cultural dimension and its impact on project management.

Individualism - collectivism. In countries with a prevailing culture of individualism, society gives the individual much more freedom, connects him less with others: he only cares about himself and, possibly, the closest family members. In more collectivist countries, people are closer to each other and feel included in the group. They share group interests and opinions, and the group protects them to some extent, gives support in trouble. There is a strong relationship between per capita GDP and the degree of individualism: individualist countries tend to be richer. Project management is an idea that originated in individualist countries. In more collectivist countries, flexible structures and the temporary nature of projects put people in a position where they are not attached to any particular group and experience alienation. This is an unusual situation for them. In order to avoid this situation (Hofstede, 1983) suggests paying more attention to the relationships of people in a project. It is better to use existing teams or form them from people of the same group. It is also worth considering when planning the timing of the time to establish relationships in the team.

Power distance. The next dimension is related to the concept of inequality. People are unequal by nature due to physical and intellectual differences. Some countries allow this inequality to increase (high level of power distance), some, on the contrary, try to reduce it (low level).

Avoidance of uncertainty. In some countries, people are being told that uncertainty should not be feared, it should be accepted. They take risks more easily and are more comfortable with behavior and opinions other than their own. These countries have a low level of uncertainty avoidance. In contrast, countries with high level, trying to "cope" with the future. And since the future is unpredictable, the inhabitants of these countries are trying to create institutions to ensure security and reduce risk. It can be technologies, laws, religions (including science, in a sense).

On two dimensions - Power Distance and Uncertainty Acceptance - the countries were located in a plane.

Figure 4. Distribution of countries by clusters, depending on cultural characteristics

The horizontal axis is the power distance index, the vertical axis is the uncertainty acceptance index. Countries are divided into several clusters. The upper right corner corresponds to the "family" model - high power distance, low uncertainty acceptance index. The lower right corner is a “pyramid” model with a high index of power distance and acceptance of uncertainty. Bottom left - "well-oiled car", low power distance index and high acceptance of uncertainty. Upper left corner - "village market", low indices of power distance and acceptance of uncertainty. Project management assumes a "village market" model, when the hierarchy is not so important (there may be two of them - project and functional), it is important not to be afraid of uncertainty and be able to resolve conflicts through negotiations (Hofstede, 1983). For other types of crops, it is necessary to adapt the management to achieve a better result.

Masculinity and femininity. Countries with a high level of separation of roles by gender (for example, a teacher is a woman's job, a driver is a man's) are called masculine, and those with a low level are called feminine. From Hofstede's point of view, this dimension is not significantly related to project management.

In these terms Russian culture corresponds to:

individualism

High power distance

High degree of uncertainty avoidance

femininity

・Short-term orientation

Differences in national culture impose certain restrictions on the application of theories and methodologies written for organizations with a fundamentally different culture. This factor has been noted by scientists and research is being actively conducted in this direction.

In the PMBoK Project Management Body of Knowledge: PMI, culture is noted as one of the important factors in the organization's environment. “In light of globalization, understanding the influence of cultures is critical.” Culture becomes a critical factor in determining the success of a project.” PMBOK. Some researchers also point out that one of the assumptions of PMBOK is that there is a constant part and a variable part in project management, which are directly influenced by factors of national culture. This is especially true for projects in which a multicultural team is involved, or geographically distributed in different places. IN Russian conditions- the world's largest and multinational country, this is a fairly common situation, so this topic is especially relevant for Russian project managers.

1.9 Ethnocultural features of project activities in Russia

The development of this topic in the field of project management in Russia is still at an early stage, but new ones are beginning to appear. scientific works, for example, (Kozhevnikova, 2013) in her work "Ethno-cultural factors of project activity in Russia: problems and tools" presented a study of the influence of ethno-cultural factors. During the survey of project managers from various companies (from large construction companies to small IT and consulting companies), the main problem areas of project management were identified: management of deadlines, quality, personnel and content.

Today, a huge amount of data is collected about people from different countries, including enough data on ethno-cultural characteristics. In particular, The World Values ​​Survey (www.worldvaluessurvey.org) is a global network of social scientists studying changes in value attitudes, as well as their impact on social, political and other spheres of life. Based on the data from this portal, as well as the managers' own study (Kozhevnikova, 2013), a table of value orientations of Russians compared to Americans was compiled.

Table 1 Comparison of Russians with residents of the United States.

	Evaluation of manifestation in Russians (compared to Americans)
Result orientation	Less result-oriented, although aware of the need to achieve it
Work among the values ​​of life	The instrumental value of work (work as an achievement of extraneous goals, not self-realization), as a result, the secondary nature of work in relation to personal life
Attitude towards remuneration	More sensitive to material values ​​and rewards
Formalism and requirements	Accept a less formal approach while being used to pressure at work
Initiative and achievements	Less ready to take the initiative and not focused on achievements
Trust and tolerance	Have a lower level of trust and tolerance

The compilation of such tables helps to visually show the differences in the values ​​of Americans (on which management and project management theories are largely based) and Russians. The difference becomes obvious, which is not super serious, but can have an impact on the management process.

The points "Formalism and requirements", "Initiative and achievements", "Trust and tolerance" are of direct interest to practitioners of flexible project management methodologies in IT and other areas. The fact that Russians “recognize a less formal approach” is a positive thing, since Agile practices are based on less formal and more personal (not to be taken absolutely) communication, preferring informal plans and face-to-face communication between team members. On the contrary, a relatively low level of trust and tolerance, as well as a low desire to take the initiative and a weak achievement orientation are negative factors. The basis of almost every agile project management methodology is a well-coordinated team with a proper degree of independence. It is clear that a low degree of trust and a desire to take the initiative have a negative impact on the ability of the team.

These facts show the need to take into account ethno-cultural factors in project management. You should not perceive them as traits inherent in every person from Russia, and endangering the use of Agile methodologies. The manager just needs to be aware of their presence and try to overcome weaknesses and derive additional benefit from strengths.

1.10 Transition to agile from a traditional project management approach

The introduction of a new methodology is a complex process, which is often accompanied by various problems, such as unpreparedness of staff, resistance of employees, and others. As noted above, the identified CSFs represent the traits of an organization in which agile methodologies are fully embedded in the culture and workflow. Otherwise, success is extremely difficult. Therefore, one of the main tasks of the project manager is to implement the methodology in the team and organization.

In the theory of project management, a significant place is occupied by the assessment of the maturity of the company, as well as the construction of a corporate project management system. The main idea is that the organization is moving towards the full implementation of project management gradually, since the implementation of many tools is impossible if the organization is not yet ready for it. A similar approach should be applied to agile methodologies. It is not possible to instantly realign people and teams to be agile. Organizations and teams need time to gradually understand not only the specific procedures and processes that flow in a project using an agile approach, but also the fundamental principles. An organization may start using a certain methodology, but this does not mean that it is implemented: integrated into the system of values ​​and beliefs, the working practices of the staff.

The complexity of transitioning to a new methodology varies from organization to organization and depends on many factors. The manager should pay special attention to teaching the team new methods, conveying the value of the new methodology to the team, resource support for implementation, testing the new approach (Fernandes, Ward, & Arájo, 2015).

An important aspect in the implementation is also the ability of the staff. (Cockburn, 2002) noted that people's differences make them more or less fit for a certain type of work. (Boehm & Turner, 2003) developed the classification into 5 types of employees:

3 - capable of rethinking the method, breaking its rules for successful application in a completely new, unpredictable situation

2 - Capable of adapting the method to the current situation

1 A - After training, they are able to use various methods that involve independent choice. With experience, they can move to category 2.

1 B - After training, they are able to perform standard procedures

1 - May have technical ability, but are unable or unwilling to perform joint work, do not share common methods.

Successful implementation of agile methodologies requires a sufficient number of type 2 and 3 employees. If the organization has a significant proportion of inflexible 1B employees, adopting an agile approach is risky. It is worth considering a planned or hybrid approach, which involves more thorough and formalized planning. It should also be noted that this approach is even more consistent with the Russian organizational culture(Kozhevnikova, 2013).

Chapter Conclusions.

Agile methodologies are one of the main alternatives to the traditional project management approach. They are especially effective in conditions of constantly changing environmental conditions, and hence the requirements for the product. This situation is especially typical for the IT sector. The KFU model is in a good way show the factors that the manager should pay the most attention to. In foreign literature on this topic there is no unanimity: researchers identify different factors as key to the success of the project. In Russia, there are practically no such studies. While there are objective differences between countries in socio-cultural factors. They do not allow, with a high degree of probability, to project the conclusions of foreign studies onto Russian companies.

2. Empirical study of key success factors for IT projects

2.1 Research methodology

Agile project management methodologies based on creating business value for the customer in the process of gradual iterative product development have become firmly established in IT projects. They have proven their effectiveness in the face of uncertainty that accompanies the business of our time. However, the issue of applying agile in practice is still controversial among theorists and practitioners. There are enough articles in the English-language literature regarding the key success factors of an agile project, but it is difficult to say that they unanimously single out any indicators (Fortune & White, 2006). Moreover, these works examine respondents from different countries, while each country has its own characteristics in project management (Hofstede, 1983). There are very few similar works about Russian projects. Closing this gap is the main goal of the study.

The study can be divided into 4 stages:

· Preparatory stage

・Information gathering stage

The stage of analysis of the received information

On preparatory stage a primary analysis of the problematic situation was carried out: a review of Russian and foreign literature on this topic was carried out and unstructured interviews were conducted with 3 IT project managers who had experience with Agile. The result of this stage was the formulation of research hypotheses and the compilation of a questionnaire for remote collection of information.

The collection of information at the second stage of the study was carried out using a remote survey of IT professionals via the Internet. To do this, the questionnaire created at the previous stage was posted on thematic forums and groups on social networks using the Google Docs service.

The analysis of the received information was carried out using SPSS. Particular attention was paid to the analysis of correlations and the construction of regression models.

2.2 Research hypotheses

Based on the results of previous studies, the following hypotheses were put forward:

Table 2. Research hypotheses

Variable	Connection
Customer Satisfaction	Linked to success
Interaction with customers	Linked to success
Decision time	Linked to success
Team location	Unrelated to success
Team size	Linked to success
Corporate culture	Linked to success
Planning	Linked to success
Control	Linked to success
	Unrelated to success
Personal characteristics	Linked to success
Communication	Unrelated to success
Contact with management	Linked to success
Using special software	Unrelated to success
Leadership's vision	Unrelated to success
Understanding the Role	Linked to success

2.3 Description of the interview process

The survey is the main method of collecting information in the study. The methodology used in the article (Misra, Kumar, & Kumar, 2009) served as the basis for the questionnaire. The original questionnaire was translated into Russian and subsequently modified. After analyzing the preliminary interviews with managers, several questions were added:

The project team and company management regularly exchange information on the progress of the project

We use special software for ease of management and communication within the team

The team and management had a clear vision of what the project should achieve

Each team member is well aware of their role and functions within the project

These topics were not covered in the original survey, but were mentioned as critical to the success of the project by the managers interviewed.

Some of the questions were excluded from the methodology after discussion during interviews with managers and during the pilot study of the study by HSE students. In particular, the variable "Sociocultural factors" does not make sense in the context of this study, since the study is conducted within the framework of one country - Russia, therefore the factors are predetermined. In the study (Misra, Kumar, & Kumar, 2009), this variable is responsible for the differences between the countries in which the respondents operate, which in this case is incorrect.

After the final check, the survey was posted on the Google Docs service, and then published on thematic forums and groups on social networks:

http://www.cyberforum.ru/

http://programmersforum.ru/

http://www.pmprofy.ru/

http://www.microsoftproject.ru/

http://www.pmi.ru/forum/

https://www.facebook.com/

https://www.linkedin.com/

A total of 17 responses were received. Sufficient diversity was achieved both in the experience of the respondents and in the size of the organization.

Proposing research hypotheses

2.4 Analysis of results

The survey approach was entirely quantitative, except for demographic questions. Various statistical methods were applied to analyze these closed questions. The main purpose of the study of the relationship between variables: 15 independent (some included more than 1 question) and 1 dependent - the success of the project. The Pearson correlation coefficients for each independent variable were calculated, and a regression model was built.

2.4.1 Demographics of respondents

The study also collected additional information about the respondents. The majority of respondents represent companies in industries related to computers (software, hardware, etc.) (76%), the remaining industries represent 1 respondent each (6%) - telecommunications, consulting, sales and finance.

There is a much greater diversity in terms of the size of the organizations represented:

Table 3. Descriptive statistics - the number of employees in the organization

It can be said that both very small organizations of 10-20 people, as well as medium and large companies are represented.

Most respondents represent teams of 5-10 people (41.2%) or 11-20 people (41.2%), other team sizes are represented by a small number of respondents (5.9% each). It is worth noting a fairly even sample: approximately 50% of respondents represent small teams (up to 10 people) and 50% of teams of more than 10 people.

The most important point in the demographic part of the survey is the experience with Agile methodologies:

Table 4. Descriptive statistics - experience with agile methodologies

The sample is quite even: there are respondents with different experience with agile methodologies. Some predominance of respondents with less than 3 years of experience is probably due to the fact that the agile approach in Russia is just beginning to gain popularity.

2.4.2 Reliability testmodel variables

Validity analysis was carried out for variables composed of several indicators. Cronbach's alpha coefficient was chosen as the method of determination. This indicator assesses the internal consistency of variables and is measured in values ​​from 0 to 1, where 0 - completely inconsistent, 1 - completely consistent. Thus, the higher the value, the better for the study. There are different views on the cutoff threshold, but the most popular threshold is 0.7. The table shows the results for composite variables:

Table 5. Variable validity analysis

As can be seen, for all variables, the values ​​of the coefficient are higher than the threshold ones, so we can conclude that these composite variables are reliable.

2.4.3 Correlation analysisindependent variables with project success

The main concept of the study is to analyze the relationship between 15 independent variables (representing critical success factors) and 1 dependent variable - project success. One of the main tools is the Pearson correlation coefficient. For this study, the significance level is 95%. The results of the analysis performed are presented in the table.

Table 6. Correlation of variables

Variable	Pearson correlation coefficient	Significance
Customer Satisfaction
Interaction with customers
Decision time
Team location
Team size
Corporate culture
Planning
Control
Team technical competence
Personal characteristics
Communication
Contact with management
Using special software
Leadership's vision
Understanding the Role

According to the results of the analysis, only 3 independent variables found a statistically significant relationship with the success of the project: Focus on customer satisfaction, Time to make decisions, Control. These results are consistent with the findings of the study (Misra, Kumar, & Kumar, 2009). The strongest relationship with project success.

Other indicators did not find a statistically significant relationship, which can be partly due to the limited sample size.

2.4.4 Building a Multiple Linear Regression Model

...

Similar Documents

The essence and functions of the corporate project management system (CPMS), its elements and requirements for it. Basic methodologies and project management processes. Description of the main roles in the context of CPMS, stages of its development and implementation.

control work, added 06/13/2013


The essence of the concept of "project". Relationship of project management methodology with other management disciplines. The difference between a manager and an owner. Sources of Leadership Success. Project management levers. Life cycle and phases of an investment project.

presentation, added 11/21/2011


Using project management methodology as a mechanism for implementing innovative investments. Synergy of project, program-target and portfolio management. Model of an information-analytical system for managing a medical institution.

term paper, added 07/07/2015


Analysis of existing information technologies in the field of project management. Development of a methodology for introducing the Microsoft Project project management software package into the work of an educational institution and evaluating the effectiveness of its use.

term paper, added 01/14/2014


Characteristics of the stages of development of project management in Russia. The concept, role and relevance of project management. The main forms of planning and control of the current activities of the company. Features of project management in partner firms "1C: Franchisees".

term paper, added 10/23/2015


The concept of project management as an important part of the functioning of any enterprise. Implementation of information systems. Project management standards. Project integration and content management. Features of time and cost management.

practical work, added 04/07/2015


Project management in market conditions, features of their management in Russia. Managing the efficiency, profitability and duration of the project. Activities of people in projects. Factors and rules for achieving success in project management.

term paper, added 03/25/2008


The concept, composition and types of projects. Stages of project management in the enterprise. Organizational and economic characteristics of Kazzinctech LLP. Analysis economic indicators enterprise work. The main problems in project management and ways to solve them.

thesis, added 05/22/2012


The project and its characteristics. Project management as one of the most complex and time-consuming tasks of management activities. Types of organizational structures for project management. Analysis of the organizational structure of project management in IT Service LLC.

thesis, added 02/18/2013


The concept and structure of the corporate project management system. Basic methods for diagnosing the level of maturity of project management. Initiation and planning, financing of projects. Management of programs, risks, communications and portfolio of the enterprise.