Chat with us, powered by LiveChat
This website uses cookies to ensure you get the best experience


Marketing Manager
Anastasia Shevchuk


Scrum is a framework that helps teams work together. It is a project development approach in which teams work in sprints lasting from 1 to 4 weeks. Scrum encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve. When planning the sprint for the next week, developers plan, discuss and analyze tasks, and at the end — demonstrate the finished part of the product. Customers give feedback, add new tasks, and the team starts working on the next feature or completes the remaining ones.

But not everyone is comfortable working on Scrum. There are some exceptional situations, where a Scrum approach will be not the best choice!


Let's imagine a situation: the company has never worked with the scrum development approach, but after a thorough analysis of competitors, it found out that their development processes are much faster. Sales are growing, new customers are appearing on the horizon. And so, the product manager thought, why not also try to implement scrum methodology? Suddenly, he decides to inform the team that now all the tasks will be planned in advance, divided into sprints lasting 1-4 weeks.


Imagine: the design team can't plan tasks for a week ahead, as it simultaneously works with four development teams involved in the implementation of new features. They say that it is impossible to plan the tasks in advance, as most of them are managed as they assign.


The Kanban framework will help in this situation. On the Kanban board, the team will see how many tasks need to be done ("To-do"), how many are completed ("Done"), and how many are in progress ("Doing").

Kanban will give more flexibility in managing the task flow. Developers will add their tasks to the "To-do" column. And the designers will perform one task after another. Unlike Scrum, they can accept as many requests as they want from other teams.

But here it is important not to forget about WIP (Work in Progress). This is a limit on the number of tasks that one employee can do at a time. Designers can take one task at a time. They will start the next one when they finish doing the current one. This approach will help them keep their focus, and help developers make effective use of their limited resources.


When someone from the team does not have time to do everything planned by the end of the sprint, there is a natural desire to postpone the demo to come to it fully armed. But in this case, you still need to stick to the schedule. In any case, it is worth discussing the results of the work: what we made, what and why we didn't make it, what we did to make it. This way we do not avoid problems, but meet them face to face and then find advanced solutions. This approach increases motivation, and after unsuccessful planned demos, work responsibility.


Imagine: The developer does not meet the sprint deadline but he has to finish integration with the payment service before the end of the week, however, an error pops up all the time. The reason is unknown. Moreover, the site's payment model needs to be done as soon as possible, as the release is scheduled for next week.
The answer to this problem is very simple: practice communication. Ask, discuss with employees what difficulties they face during the work process. Each member of the Scrum team does their piece of work during the sprint. But it happens that the developer may face a difficult task, and need the help of a more experienced specialist and more time to solve it. This is how pair programming appeared. In brief, it is an agile software development technique in which two programmers work together at one workstation. One is the driver, who writes code while the other is the observer or navigator, reviewing each line of code as it is typed in. The two programmers switch roles frequently.

Such kind of programming helps to come up with new ideas for improvements and solutions to the current problems.



Enterprise resource planning systems are the backbone of most companies. Without them, nothing gets sold, manufactured or shipped, and no one gets paid. ERP systems have lots of modules and features that take time to customize according to the organization's requirements. Furthermore, Enterprise resource planning projects are rarely completed in a few weeks; a few years is more likely.

When implementing a new ERP system, it is important to think thoroughly about all development phases and apply them while planning sprints.


Imagine the situation: the company received a large and profitable order for the implementation of enterprise resource planning. To implement such a high-scale project requires the work of all departments. But how to synchronize everyone and start sprint planning, if one department can start tomorrow, and others only in a week?
In this case, a good helper will be The Scaled Agile Framework (SAFe) that encompasses a set of principles, processes, and best practices that helps larger organizations to develop and deliver high-quality products and services faster. The Scaled Agile Framework is particularly well-suited to complex projects that involve multiple large teams at the project, program, and portfolio levels.

It takes four sprints, or about two months, to develop each increment. There is also the fifth sprint. It's called a HIP sprint (Hardening, Innovation, Planning):

Ensure that all program increment objectives are achieved, and technical debt is reduced.

Provide time for teams to generate new ideas, or introduce some innovations.

Conduct sprint retrospective and complete the planning of the next Program Increment.
Such kind of programming helps to come up with new ideas for improvements and solutions to the current problems.




Scrum teams should be adaptable, self-organized and cross-functional. Of course, if you just start working with Scrum methodology, for the first time it'll be difficult to prioritize tasks and understand which to take first.


Imagine 3 departments working on the same project. Let it be the creation of a complex analytics module.

So, development team #1 is responsible for databases.

Development team #2 makes a connector that transfers data from the databases to the module.

Development team #3 builds graphs and charts based on the received data.

Each team has its own tasks, but they work on the same product. Once a month, the company releases the analytics module with all updates. At this point, each team must complete the current tasks on time. If one of the teams does not have time for the release, then the rest complete their tasks and then help others.

At first glance, this approach looks effective. But this is just an illusion, since it takes longer to complete the tasks than if the lagging team tried to solve everything itself.


The scrum approach encourages teams to be independent and self-directed. But not all developers have ever had such an experience. Programmers like to solve exciting tasks, rather than spend time organizing a team. But this does not mean that you will never be able to create self-organized teams. It's just going to take time.
The best way for the first time is to appoint a release manager who will quickly distribute tasks among the rest of the programmers.


When the vital values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. Transparent communication among all team members is a key to a project's success.


Imagine: the development team is not allowed to put forward creative ideas for successful project development.


When starting working on scrum, identify general values to your team: commitment, focus, openness, respect, courage.

Let's look at each separately:

Scrum teams must be able to work together as a unit to achieve a common goal. That means trusting one another to follow through on their tasks and deliver to the best of their abilities. This will only happen when each team member is fully committed to the team and the project.

Promote commitment by facilitating proper sprint planning and protecting teams from sprint changes and unnecessary pressure from product owners.

For team members to stay focused, Scrum masters can limit the number of tasks or priorities placed on each person during sprints. Additionally, encouraging full team participation at the daily scrum meeting can help individuals stay focused on their specified tasks.

Honest and openness are keys to project development success. The purpose of the daily scrum meeting is to identify and solve burning problems. That can't happen if team members don't share issues or roadblocks they're experiencing. Additionally, team members must be open to working with their colleagues and view them as valuable contributors to the project success.

Such a value as respect means trusting your fellow team members to fulfill their tasks, listening to and considering their ideas, and recognizing their accomplishments.

Scrum teams must have the courage to be honest, open, and transparent both with themselves and with customers about the project's progress and any obstacles they're experiencing. Team members also need the courage to ask for help when it's needed, to try new tactics or methods they're not used to, and to respectfully disagree and have an open dialogue.


To sum up, Scrum can bring a bunch of benefits if implemented wisely. Learn what tasks this framework helps you solve. Analyze your team's tasks and compare them with what Scrum offers.

If you have already successfully worked with the scrum development approach, it is not a fact that it will help you now. Don't ignore other frameworks and ways of organizing. Even if they are not as popular as Scrum, it doesn't mean that they are worse. Practice each one and find the most suitable for your business.