Chapters
Scrum is not the one & only way to develop software and sometimes it’s not ever a good fit for your project. Our Senior Agile Project Manager, Paulina Piechaczek explains how to evaluate the method that is best aligned with what you have on the table.
Scrum is often the go-to agile framework for working on software products, and according to the Zippia portal, 61% of projects are carried out in Scrum. Its popularity means that decision-makers often choose it as a default method and fail to consider others. This might be caused by less knowledge of Kanban, XP (Extreme Programming), or other frameworks, lack of internal experience in different models, or simply lack of awareness of the differences between them.
In this article, we want to prove that Scrum is not the only way to go. If you are the decision maker, the comparison we prepared will help you distinguish between types of methods. And if you are part of a team trying to convince your PO to use a specific work model, we will give you some great arguments for your pitch.
Why doesn't my Scrum project work?
Only a short analysis is needed to determine why Scrum doesn't work for you. Firstly, the Product Owner or Product Manager, preferably along with the whole team, needs to answer Yes or No to the following questions:
1. Are the requirements precisely defined for the project team?
2. Do we understand the needs of the end-users, and what solutions are they expecting?
3. Is the team able to collect frequent feedback from the PO and stakeholders?
4. Is the scope of the project fixed?
5. Is the timeline fixed, or on any hard deadline?
Getting all the answers is essential because the decision about the framework will be based on them. If the PO is uncertain about the answers, it is crucial to get them from the decision-makers as soon as possible. Let’s dive a bit deeper to make you understand why the answers to these questions are essential.
Clear requirements for the project team
Precise requirements provide a detailed description of what needs to be accomplished. It doesn’t mean you need to explicitly outline how the feature needs to be built, but the "why” behind it needs to be there. It is essential that the product team knows how to approach the task. If you already have a Jira project, check if tasks are created as user stories, if acceptance criteria are listed in each of them, and if design files are added.
Solutions expected by end-users
Is your project end-user driven? Have you collected the needs and expectations and clearly understand which user needs will be covered with this project? All this information is governed by the Product Owner, who decides on the priorities and can adjust the scope of work, for example, to achieve an MVP (Minimum Viable Product).
Frequency of feedback from decision-makers
The frequency of feedback determines how agile the team can be. Answer Yes if the PO can decide on the fly on priorities and general direction of the project. If the decision to remove a minor feature or add a new one requires 1-2 or more weeks of processing, your answer should be No.
Fixed scope
You might be looking at fixed scope if you have a backlog with detailed explanations about how things should work. If your roadmap is fixed and pretty much unmovable, you are also working with a non-agile approach. To answer No to this question, you need to be able to decide on the scope practically daily and work in short cycles to release your project incrementally.
Hard deadline or fixed timeline
Some projects simply have to have a hard deadline, whether from a specific event, third-party dependencies, or a specific time of year. Being bound by such a "due date" rules out experiments, changes to scope, making mistakes, or in other words, an iterative approach. It's tough to use the agile approach if the timeline is fixed and there is no room for delays caused by iterations.
Making the right choice
Now that you have answered those five simple questions, you can look at this simple matrix with a few chosen frameworks to evaluate your project management needs.
As you see, the more flexibility the project has, the more agile approach we need. Those are the projects EL Passion excels at, and we firmly believe that the agile approach is the quickest way to prove to stakeholders that the project will become a business success.
If, on the other hand, the scope is fixed, all tasks are defined, and feedback is not frequent enough to change the outcome of tasks, you don't need agile at all. The best solution would be a waterfall model, a hybrid, or even your own framework.
Choose whatever you think is best, but please remember - it is essential to be committed to one solution or the other. Do not try to run a fixed scope and budget project in agile, nor try to meet a tight deadline by iterating and experimenting with solutions during sprints.
Don't be afraid to change your mind if needed
Imagine that you or your Product Owner decided to use Scrum in the project and the team has a lot of experience working with this methodology. But after the project starts, a new deadline is set, the scope becomes fixed, and there's little room to be flexible. The team begins struggling with every planning and goal setting since it's challenging to be agile when working under such pressure. Alternatively, planning sprints and tasks in advance can be tricky if the product becomes unknown and the scope needs to be constantly clarified.
If those circumstances occur, the team will become frustrated and unsatisfied with Scrum framework rules, maybe even blaming it for causing the issues. In that situation, the Product Owner, with the team's help, should answer the above questions and consider which framework would be the best choice. Next, find an expert in the chosen framework or at least someone with the most experience, and make sure to spend a couple of hours discussing how the day-to-day process of creating the product will change. Everyone in the team needs to be onboarded into the new framework as it ensures that the project will be up and running again quickly.
As your product develops and requirements change, observing how the methodology affects the team's effectiveness and performance is worth monitoring. Perhaps, at some point in the future, when the product is more mature, tasks are more predictable, and the roadmap becomes more precise, there will come a time when Scrum or other agile-oriented methodology can be implemented.
The Product Owner's responsibility is to choose the best way to work on a project. However, there is no fixed rule saying that the framework chosen can't be adjusted to the project's reality. Sometimes it's inevitable, and it's better to spend a couple of days adjusting to a new framework than fail the project because of rigidly keeping to the rules of the methodology chosen at the beginning.
Check out also:
- 10 Most Important Benefits of Implementing Agile — Agile revolutionized modern project management and software development. What are some of the Agile benefits?
- 6 Must-have Skills for Agile Project Managers — What qualities make a good Agile Project Manager? Let’s find out.
You may also like
We’re available for new projects.
