Blog

Agile, Scrum, Kanban, Waterfall: Project managment methologies in it

Introduction

Project Management is the process of managing projects, which includes planning, organizing and executing them in order to achieve specific goals within specific time and budget constraints. The focus is always on the project and its successful implementation.

Project Management in IT refers to managing resources to create a new service, environment, website or any other digital product.

Project Manager is a specialist who manages a team, coordinates their work, monitors the execution of processes, and makes adjustments to the development process as needed. The Project Manager acts as a mediator between the client and the team and their main task is to ensure that the efforts of the unified team lead to the successful completion of the set goals by the deadline.

The task of a Project Manager is to ensure that the specialists working on the project do not struggle with chaos but work smoothly, clearly understanding what and in what sequence they need to do at each stage. Developers, designers, analysts, each working in their own direction, often do not fully understand each other. In this case, the Project Manager acts as a link to unite all project participants into a single team and direct their joint efforts towards the successful completion of the project.

One of the key skills of a Project Manager is the ability to plan the time required to complete tasks. At the initial stage, when the team is just starting to implement planning, it is difficult for the Project Manager to calculate and set an exact time for task completion, as it is crucial to consider multiple factors. In particular, it is necessary to take into account that in addition to the development process itself, developers spend a lot of time in meetings and discussions, which are necessary for successful project development. Furthermore, the Project Manager needs to calculate and set aside time for dealing with potential unexpected situations. With time and experience, considering these factors becomes easier and planning becomes more accurate.

In order to effectively solve all these tasks, the Project Manager must first find the optimal project management system.

Methodologies for IT project management

When working on a project, Project Manager eventually has questions about how to make development more predictable, how to ensure quality, and how to standardize the development process.

There is no universal, perfect management methodology that can be successfully applied to any type of IT project. There is also no universal management system that would suit every manager and be convenient for every team member working on the project. However, during the existence of project management, many methodologies, standards, and effective methodologies have been developed that can be used when working with a specific IT project.

In the IT field, the most widely used project management methodologies are:

  • Predictive methodology
  • Iterative methodology
  • Iterative-incremental methodology
  • Agile methodology

Predictive methodology

Predictive (traditional/classic) methodology implies a step-by-step linear algorithm that is similar to a conveyor belt. It consists of a series of clear stages - outlining some requirements, preparing architecture, primary coding, testing, and subsequent support.

The essence of the methodology is reduced to four consecutive phases:

  • Project design development
  • Software development
  • Software testing
  • Project delivery

The process begins with detailed and comprehensive planning and documentation. All tasks are defined as precisely as possible, the team participates in assessing the complexity of tasks and the time required for their implementation. Then the customer evaluates the documentation and plans, and approves them. After that, the team begins to create the final product. Testing of the product begins only after the project development is completed or almost completed. In this case, the entire product is tested. And only after this tested and fully ready-to-use product is handed over to the customer.

The most popular example of such a methodology is the cascade model, also known as “Waterfall”. Following this model, the developer moves from one stage of work to another strictly sequentially.

This model is suitable for simple projects that can be analyzed quickly and in full. In practice, preparing quality requirements for even a small project can be a difficult task. Most often, the shortcomings and errors of the requirements are revealed only during the implementation of the project, so products developed based on this model without a justified choice are likely to have defects that are only known at the end due to the strict sequence of actions and the inability to correct requirements during implementation. The cost of making changes to the project is high, as it requires waiting for its full completion.

For example, a customer wants to get a painting with an image of a woman. At the beginning, he must formulate clear requirements that the performer cannot deviate from during the creation of the painting. The client cannot make any changes to his requirements after they are agreed with the performer. Then, based on the customer's requirements, the final design is developed and the process of creating the painting begins. And only after the completion of the painting process, it is checked for full compliance with the client's initial requirements and design, and the fully finished painting is handed over to the customer.

Iterative methodology

Iterative methodology is a modern approach to software development in which the functionality of the software is incrementally expanded with each new release as part of the project.

Unlike the predictive approach, the iterative methodology does not require the presence of all requirements and clear documentation before the start of the project. The customer can only roughly understand what the final product should be and this may be enough for the performer to start. The performer begins developing the final product in parts. Each iteration includes analysis of intermediate results, new requirements are proposed and previous stages of work are corrected. However, each part of the product obtained during the iteration is not ready for use. Only at the end of the development process do we have a finished product.

If the customer's needs change in the middle of an iteration and he needs to get the finished product (painting), then he will not be able to do this. He will receive only parts of it (“stubs” of the painting) that cannot be used.

Iterative-incremental methodology

When using an iterative-incremental methodology, the customer should have a general idea about the result that he would want to achieve. As in the iterative methodology, development of the result begins in parts. But in this case, each iteration results in a version of the finished product.

For example, a customer would like to receive a painting of a woman in a pastoral landscape. The performers start creating different versions of the client's requested painting with varying degrees of completeness. At each stage, they clarify with the customer whether the painting meets their requirements and make the necessary adjustments. This means that first the performers draw a sketch, then clarify how the client wants the woman in the painting to look, and then together with the customer choose the color scheme of the painting.

With this methodology, the customer has a product of varying degrees of readiness at each stage, and can take and use earlier versions of the painting if desired.

Agile methodology

Agile is a value-based methodology that helps developers make new products faster and with greater business impact.

Agile methodology focuses on two things: maximizing the value of the product for the customer and the speed at which that value is delivered to the customer. Values are what determine priorities in work, regardless of the specific process or work item. Agile values are outlined in the Agile-manifesto.

Each of the four Agile values is formulated as "X is more important than Y":

People and their interactions are more important than processes and tools: In order for people to work effectively, processes and tools should not restrict them. To speed up the development process, people should also actively interact with each other.

Working product is more important than comprehensive documentation: Product developers should focus on making the product ready for use as soon as possible.

Collaboration with the customer is more important than contract negotiation: To achieve a product that is truly valuable to the customer, it is worth avoiding going into too much detail when signing the contract. In order for the business value of the product to grow quickly, the customer and the developer should communicate closely at every stage of the work.

Responding to change is more important than following a plan: To avoid postponing risks of projects until the last stages of development (when it will be too late to reduce the scope of work, shift deadlines or increase the team), Agile offers not only iterative work but also readiness for change at all stages.

Thus, Agile is not a development methodology, but a system of values that helps developers create new products faster and with the greatest effect for the business.

These values are so general and even abstract that Agile is often called a philosophy. In addition to values, there are also 12 principles in the Agile manifesto that clarify and complement the values.

The term Agile Mindset means understanding of Agile values.

Changing the mindset from traditional to agile is the most difficult thing to do when applying any Agile methodology. When people lack an Agile mindset, even the presence of all other elements does not allow teams to be fast and self-sufficient, products to be timely and successful, and customers and managers to be satisfied.

Disadvantages of Agile

Along with the advantages of the Agile methodology, there are also some disadvantages. They consist of the fact that, firstly, constant feedback can lead to the project deadline being constantly postponed, creating the threat of endless work. If the client sees only the results but does not have an understanding of the efforts required to achieve them, he will constantly demand improvements.

The second disadvantage is the need to adapt the project documentation to changing project conditions. Without proper notification of changes or additional features, documents with functional requirements or architecture may become outdated at the current time.

Third significant drawback can be called the need for frequent meetings. They certainly contribute to increasing efficiency, but constant distraction of team members can negatively affect the process, as people's attention systematically moves away from the tasks being solved.

This can also include things like the need for constant customer presence, the inability to establish long-term plans, and the need for motivated and highly qualified specialists.

Waterfall vs Agile

The classical cascading work process assumes that all the development stages necessary for the finished product are carried out from start to finish and only after passing through all stages the final product is ready for use.

Agile methodology proposes dividing the work process into stages, each of which includes all the necessary actions to create a specific version of the finished product.

The value of the product being developed increases over time from iteration to iteration, on each version, as there is already a certain version of the product ready from start to finish on each stage.

Furthermore, the use of such methodology allows for faster creation of the entire product as a whole. The video below demonstrates this visually:

The bottom queue was assembled faster because work was done in small iterations, while the top queue was assembled twice as long as work was done in large batches of accumulated work. This is precisely the basis for the effect of faster development using an iterative-incremental methodology.

If we act in a waterfall way, then we get the final result at the very end, and the risk of failure (the probability of a negative outcome) increases over time - the closer the deadline, the higher the risk, as it is only possible to understand what the final result will be after full completion of development. That is, we only test the fully finished product after its development is completed, which means that the probability of detecting an error is much higher than if we tested the product in parts, as they become ready.

If we work iteratively-incrementally, with each iteration we clarify the target point, i.e. we check whether we are doing the right things by showing them to the client and coordinating during development. Using this methodology, the risks over time decrease - the closer to the deadline, the lower the risk of failure.

The attitude of these methodologies to fixed values also differs. The waterfall methodology fixes the necessary functionality first, and then estimates the time and budget needed for its full implementation. On the other hand, Agile methodology fixes the budget and time for creating the product and then maximizes the functionality that brings value to the client within that time frame.

Key Features of Waterfall and Agile

Requirements Planning and Obligations Delivery Goal
Waterfall Fixed at the planning stage Pre-planning priority

Obligations are taken at the beginning of the entire project		 One time at the end of the project Cost and risk management
Agile Change dynamically with the project environment, market conditions and customer needs Operational planning priority

Obligations are taken per iteration		 Frequent small releases Fast and frequent delivery of valuables to the customer

Ralph D. Stacy model (The Stacey complexity model)

Ralph D. Stacey's complexity model can help select which methodology is more suitable for a project. This model has two dimensions - technologies (from known to completely new and unknown) and requirements (from understandable to vague).

The first domain, Chaotic, is where vague requirements and new technologies exist. Success in this domain is practically impossible, with a probability close to zero.

The opposite domain, Simple, has known technologies and clear requirements. No special methodology is needed in this case, as we know exactly what needs to be done and how to do it.

The Complicated domain is where Waterfall is best suited, as the difficulties of technologies and requirements can be overcome with the help of experts and their expertise, as well as pre-analysis and planning.

The Complex domain is where Agile performs best, when difficulties exist on both axes or when vague requirements exist on one axis (with known technologies or clear requirements but unknown technologies).

By self-assessing on these axes, it is possible to predict which methodology is optimal for the project.

It's often asked what happens if Agile is used for tasks from the Complicated domain instead of Waterfall. It is possible, but the project development will be slightly less effective.

To determine whether a classic methodology is more suitable for a project than an Agile approach, you can use a checklist.

Indicators for using a classic methodology include:

  • The high cost of changes
  • Clear understanding of the project goals and user needs
  • Slow-changing project environment
  • Using the well-known technology
  • Project duration less than 4 months

If at least 4 of these points apply to the project, there is no need to use Agile.

Scrum

Scrum is a framework that contains the minimum necessary elements to put the values and principles of Agile into practice.

The word "framework" means that from these mandatory elements, a specific process can be built by supplementing Scrum with specific methods of work.. In other words, Agile is a philosophy, Scrum is its implementation.

Scrum is a way of organizing the work process. It is designed for quick development and delivery of complex, fundamentally new products that do not exist on the market. The work is carried out in iterations, which in Scrum are called sprints.

Sprint is a short regular work cycle, usually lasting 1-4 weeks. At the beginning of each sprint, the team sets a goal and plans the work to be done during the sprint.

During the sprint, the team synchronizes their efforts and identifies obstacles that may prevent the sprint goal from being achieved at daily mandatory meetings. Additionally, during the sprint, the product owner and the development team may revisit the sprint's scope if necessary.

At the end of the sprint, the team demonstrates the results of the work to stakeholders and receives feedback from them.

Returning to the painting example, the Scrum application in this case would look like this:

Scrum artifacts provide key information that the Scrum team and stakeholders need to understand the product being developed.

In Scrum, there are three artifacts:

  • Product Backlog: This is the main list of tasks that the team needs to complete. It is maintained by the product owner or manager. It is a constantly changing list of functional capabilities, requirements, improvements, and fixes, from which tasks for the sprint backlog are created.
  • Sprint Backlog: This is a list of work items, user stories, or bug fixes selected by the development team for implementation in the current sprint cycle.
  • Increment (or Sprint Goal): This is the usable final product resulting from the sprint.

Only what is usable and can bring value to the customer is considered as a result. This cannot be an intermediate result such as design or untested code for a software product.

The product is developed by the Scrum Team. It is composed of the product developers, the Product Owner and the Scrum-Master.

The main characteristics of a Scrum Team:

  • small
  • without sub-teams
  • cross-functional (having all the necessary skills to get the job done and not depend on those who are not part of the team)
  • self-managing
  • responsible for their business results

The Product Owner is responsible for creating a product that is truly valuable to customers. Based on an understanding of customer needs, the product owner creates a vision for the future product, creates a product backlog, and sets priorities for its elements.

Achieving self-management in a Scrum team is very difficult, which is why a Scrum Master is needed to ensure the team's effectiveness and to ensure the correct development process from the perspective of Scrum. The Scrum Master helps the team become self-managing and teaches developers to take responsibility for the product.

The main sequential activities, ceremonies, or meetings that Scrum teams regularly conduct are:

1. Backlog grooming - an activity carried out by the Product Owner to align the product with customer needs and preferences.

2. Product Backlog Refinement - an activity carried out by the Product Owner with the participation of all team members. It involves adding details, estimating, and ordering items in the product backlog. It is done to spend less time on sprint planning and start with already refined and well-understood tasks.

3. Sprint Planning - during this meeting, the development team, led by the Scrum Master, plans the work to be done during the current sprint. The sprint goal is chosen and specific user stories from the product backlog that align with the goal are added to the sprint.

4. Daily Scrum - a very short (about 15 minutes) daily meeting held at the same time for convenience, so that each team member is informed of the progress, stays on track with the goal, and receives a plan for the next day. During the stand-up, it's necessary to report on anything that prevents you from achieving the sprint goal.

5. Sprint Review - a meeting at the end of a sprint where the team gathers to demonstrate and review the increment (or study it) in an informal setting and present completed tasks from the backlog to stakeholders.

6. Sprint Retrospective - conducted for the team to capture and discuss all the successes and failures of the sprint, project, team members, and their relationships or tools. The goal of the retrospective is to create conditions for the team to focus on what worked well and what needs to be improved next time, and not to get stuck on failures.

Kanban

Kanban method is a way to organize work in a more optimized and efficient manner, with the final product better meeting consumer expectations. The foundation of the Kanban method is visualization and limiting the amount of “Work In Progress” (WIP).

The Kanban methodology includes real-time discussion of productivity and full transparency of workflows. Work tasks are visually represented on a Kanban board, allowing team members to see the status of each task at any time.

Kanban Values:

The Kanban team is a single mechanism. If someone is not coping, then the common cause suffers. The work is planned on a board, so everyone can see their contribution and value to the project. There are no strict rules, but there are principles that you can rely on.

The basic principles, which are also called the change management principles:

  • Respect and use what is currently available: existing roles, responsibilities and job instructions.
  • Continuously optimize and improve the development process, but do not allow too drastic changes...
  • Encourage in the team the desire for leadership.

Kanban is a "balance methodology". Its goal is to balance different specialists within a team and avoid situations where designers are working around the clock while developers are complaining about a lack of new tasks.

The whole team is one - In Kanban, there are no roles for product owners or scrum masters. Business processes are not divided into universal sprints, but rather into stages of specific task completion: "Planned," "Developed," "Tested," "Completed," etc.

In Kanban, it is not customary to make estimates. This is optional and the team decides for itself. There is no concept of "teamwork speed," only the average time per task is considered. This time is calculated using a special report - Cycle Time.

Cycle Time for a task is equal to the time it takes to complete the task minus the time it takes to start working on the task. For example, if you have columns such as "to do," "reopened," "developing," "testing," "stage testing," and "deployed," the Cycle Time for a task would be "deployed" minus "developing," meaning the amount of time that passed from when the task was started to when it was deployed.

The main indicator of efficiency in Kanban is the average time it takes a task to pass through the board. If a task is completed quickly, the team is working productively and efficiently. If a task takes longer, it's necessary to think about what stage and why there were delays and whose work needs to be optimized.

Visualization helps to see the whole picture and make adjustments to individual parts, understanding how changes will affect the entire project. Getting results on time is possible by monitoring the team's workload, and that is where the Kanban board can help.

The Kanban board is an Agile project management tool that helps to clearly present tasks, limit the amount of unfinished work and achieve maximum efficiency (or speed). It can help teams organize their daily work.

Five main components of Kanban boards are:

1. Visible signals - the first thing that catches the eye on Kanban board are cards (stickers, sheets, etc.). Kanban teams put records of all projects and tasks on cards; usually one card corresponds to one project or task.

2. Columns symbolize specific actions that together make up the "workflow". Cards move through the work process until completion.

3. Work in progress (WIP) limits - this is the maximum number of cards that can be in one column at the same time. When the number of cards in the column reaches the maximum, the team should focus on these cards. WIP limits help understand early on if the team has taken on too many tasks.

4. Commitment point - Kanban teams often have a backlog. Clients and team members contribute ideas to the backlog for projects that the team may address when ready.

5. Product Delivery Point marks the completion of the Kanban team's work process. Many teams take the delivery point of the product to be the moment when the product or service is handed over to the customer. The goal of the team is to move the cards from the point of commitment to the delivery point of the product as quickly as possible.

All processes are reflected on the board, the team analyzes and eliminates weak points. In Kanban, this is called flow management.

Scrum vs Kanban

Scrum is such a popular Agile methodology that many people mistakenly use the words Scrum and Agile as synonyms. However, Kanban is also a very popular and widely used model and currently holds a strong second place in popularity after Scrum. Some companies even prefer a hybrid model that combines elements of Scrum and Kanban, referred to as Scrumban or Kanplan, which is essentially Kanban with a backlog.

Kanban differs from Scrum in many ways, in particular:

  • it has a wider area of application (not only creating a new product, but also, for example, supporting an existing one);
  • unlike Scrum, it is implemented gradually and smoothly (without an instantaneous change of current processes) and more simply (without changes in organizational structure, for example);
  • the workflow is continuous, while in Scrum it is divided into repeatable sprints of a fixed duration;
  • there are no mandatory meetings, while Scrum has daily mandatory stand-ups;
  • there is no division of roles in the team, unlike Scrum;
  • the team is not required to be cross-functional;
  • there is no need to estimate tasks, this is optional and the team decides on its own whether to estimate the task or not, unlike Scrum, where tasks need to be estimated in Story points or hours;
  • in Scrum, the goal is to finish the sprint, in Kanban - the task.

Conclusion

Developing and implementing Project Management in a company should be done gradually, testing each stage in practice. There is no universal methodology that would suit any project. Also, it is not possible to switch to new standards overnight. Usually, it is difficult for a team to adapt to changes, so it takes time and gradualness is very important.

For example, there is a project that is being developed using the standard waterfall method, where a lot of time is spent on documentation approval and errors arise at the last moment. As a result, the team realizes that it's time to change. Scrum is currently popular and everyone talks about its benefits. But it's scary: you have to drastically move away from the familiar development process, and what if it doesn't help. In this situation, it is better to start with Kanban. Then you don't have to think about radical changes and implement all practices at once, because the Kanban methodology is based on sequential and smooth changes. After some time, if the team notices obvious improvements in the work process and wants to move on, it will be able to decide to implement Scrum.

Due to implementation errors, reaching the peak of efficiency with Scrum can sometimes take years. Sometimes, if the manager does not see results, they may become disillusioned with Scrum and return to their previous management model.

When implementing Scrum, for the team to reach the desired level of maturity and functionality, a prolonged period of time is required. However, with consistency in team composition and the absence of insurmountable external obstacles, a Scrum team can eventually become a sort of "special forces" unit that can independently solve problems and tackle difficult tasks much faster than a similar team before transitioning to Scrum.



Published Feb 10, 2023