Scrum, undoubtedly, is one of the potentially viable approaches to managing software development projects. Scrum is just a development methodology which delineates the processes and practices that help in managing software development activities.
However, before adopting any methodology one should ask these questions -
- Is the use of Scrum being forced upon you to fit into the project?
- Has the research been done to predict its success rate?
- Have you analyzed the risks associated with this adoption?
- What types of projects fall into the purview of Scrum framework?
I worked in the IT industry for 9+ years on a wide variety of projects where the success rate of Scrum was very high. Hence, I got the impression that it works for all types of projects. Here is my experience with one of the projects that threw away all my misconceptions about Scrum and changed my opinion.
My team worked on a huge, multi-dimensional project, that included distributed teams.
Multiple versions of the product were already out in the market and customer satisfaction was running high. Then we decided to switch to Scrum for this particular project. As the software product was already out in the market, customer issues and complaints piled up that were assigned a priority level in order to be resolved.
The team working on the newer version was also required to support the older versions as a part of the contract with the customer. Therefore, the same team is working on new versions of the product including enhancements and new features while also addressing the customer issues and bug fixes for the older version of the software.
Now, since the product owner had already groomed the backlog for the software release, whenever any new issue from the earlier versions was raised by the customer, we took them on priority. This leads to these issues being constantly added in the midst of the sprint to the backlog and the whole team started working on the issue, leaving their current work behind.
As a result of these mid-Sprint changes-
- All of a sudden, team had to shift their focus.
- No planning was done for this issue while grooming.
- Unplanned work being added to the backlog
- Delay in creating and delivering current project deliverables.
Then comes the conundrum -
Are we really using Scrum the right way? Is our project really getting any benefit by using Scrum?
The answer is probably NOT. But the management still wouldn’t agree and will continue to force the use of Scrum for this project.
Now, let us discuss the below scenarios.
1) Sometimes there were too many issues from the earlier versions but the other times too few issues (but of high priority) were there
In these cases, we need to immediately switch our focus to a high-priority issue and provide a possible solution to the customer as early as possible. The current sprint needs to be cancelled and pending tasks need to be transferred to the next sprint.2) Sometimes no issues at all.
Continue the sprint.3) Sometimes issues need to be addressed but the current project is also in a critical stage.
An example is the build failure of the current project and where testers weren’t able to continue the testing. This becomes a critical condition for any project which needs to be addressed and planned for.
Because of this critical situation, management switched its stance and agreed to abandon Scrum for this project as it stalled both the projects and instead used the waterfall model.Few suggestions to avoid this scenario -
- Make two separate teams - one for handling the issues of earlier versions and one for the current project sprints
- Slowly and steadily we should stop giving the support to the earlier versions (End of life) and this should be clearly communicated to the customer in advance so that they can also prepare themselves. It should be coded in the contract at the time of signing. However, this is not always possible due to complex nature of projects that run big manufacturing and production plants which may adversely affect their productivity/throughput.
The above two solutions can be addressed in the following ways:
- Plan and allocate budget to provide support to the earlier versions of the product instead of hiring the new team. In case of no issues, the team can continue to work on the current project.
- For such projects, Scrum and Kanban both methodologies should be used.
In my opinion, before adopting any methodology we should always deep dive into it and understand its success rate in different scenarios of the project. We should not impose any methodology on any project by giving justification that it is already used by other projects.
Also, start off with small (maybe internal) projects having few sprints and few team members just to predict the success rate of the methodologies and frameworks.
“It’s better to fail first than at the end”.
So, for the projects where there is high unpredictability (don’t know when new tasks will come), chances are there that Scrum may not work; so it is better to use Kanban in those situations.
Inappropriate application of Scrum can lead to its doom – Scrum is not a prescriptive method, but a suggestive approach to software development. So, the way it is implemented makes all the difference.