Scrum Does Not Work For Me. Any Other Option?
When Scrum does not work for you, try using kanban as another approach of Agile Methodology in your software development.
Introduction
In the organization I currently work, we are not only having big projects to be done. We also have tons of Business As Usual (BAU) requests to deal with, enhancements, error fixing, ‘super important’ changes, etc.
In my opinion, Scrum will not work in above activities.
The changes required are too small for Scrum. Not to mention the aggressive deadline for the changes.
Having the organization that are not used to scrum methodology is also an issue.
Why Scrum Does Not Work?
Introducing Scrum is quite a change for a team that are not used to Agile software development.
They have to start working in sprints, build cross-functional teams, appoint a dedicated Product Owner and a dedicated Scrum Master, as well as all other regular sprint events.
The behavior change is not only in IT department, business users will need to adapt too with the Scrum way of work.
In my previous post, you will see some of the organization issues while adapting with scrum.
There’s a simpler Agile approach, though. It is called Kanban.
Let us discuss that approach more detail.
Introducing Kanban
Kanban is a Japanese word for “Visual Sign” or a “Signboard”.
In software development it’s translated into “Visual Card” that are arranged on a board.
In Kanban, we manage the work by the board into some swimlanes / columns.
Generally the swimlanes contains of “To Do”, “Doing” and “Done”.
Some teams modify the swimlanes with more column, like adding Testing between Doing or Done. It’s perfectly fine. Kanban offers flexibility in managing that.
The key of kanban is limiting the maximum number of task a team member can do in a row.
Let’s say one developer can do 2 tasks and you have two developers in the team, then the number of task can be pull in the Doing swimlane is maximum 4. Other tasks must wait. If a task is super important, then you need to take one task back to thr To Do swimlane.
Cross Functional Is Not Mandatory
In Kanban, cross functional is not mandatory. If your team can work cross functional, it’s even better.
Testers can still do only testing, developers can still focus in only developing codes (and unit test, of course).
The thing that the team must pay attention is the number of maximum card they can take into Doing swimlane. A tester cannot take 3 cards while his capability is only 2 card.
Who Decide On The Maximum Capability?
In this case, Kanban has a similarity with Scrum. The team expected to be a self-organize team.
The team will decide how much is their maximum capability and arrange the board by themselves.
They will need to communicate actively between each other to decide this and to arrange the number of cards on the board.
If they found that the maximum capability is too much, they can decide together to reduce it. As well as if they see that they can add more capacity, they can increase the maximum capability over time.
As Project Manager, your role here is to make sure that the team is not overloaded. You also need to remove the team’s impediments so they can focus on their work.
Project Manager will also need to work together with the team to decide about cards priority. Sometime you need to pull out a card from the Doing swimlane and put into hold in order to pull in a new “super important” card.
Communicating with business users is also important.
Although Kanban is not a big change as Scrum, business users must know that the team are now working with different methodology.
How Can Kanban Help Me?
In my case, the current process delivery for BAU, changes and enhancements already works smoothly.
The issue we have is actually related with overloaded task, limited resources and bold stakeholders that need everything as a high priority.
The Kanban methodology is much simpler than Scrum. You can implement it on the current development process, even to Scrum itself.
Try using Kanban if you have similar situation with me. Arrange a Kanban board, set up a maximum capability and start doing the task one step at a time.
Conclusion
Deciding whether when to use Scrum and when to use Kanban is pretty obvious.
If your organization needs a fundamental change for project delivery and more efficient process, Scrum is one of the approach you need to take.
If you already have a working process but you need to organize the task more efficient, implement Kanban in the current process should be a wise choice.
For simple enhancements, incident handling, BAU tasks, I would suggest you to use Kanban.
It’s your choice. Both Scrum and Kanban are powerful. They are proven to boost your project management.
Analyze what your organization needs and try implement what you think is the best.
If Scrum does not work for you, try using Kanban 🙂
Hi Christine,
Great article. I completely agree that Kanban could be a solution in some cases.
However, I would consider Kanban as a step towards Scrum!
Thanks Mikhail 🙂
Yes you can say that, a step towards scrum.
Even later on, creating a hybrid version of them will also speed up the process.
Unfortunately in some cases, especially those I mentioned above, scrum will be a challenge to be implemented.
Curious to see if you will still have the same opinion in let’s say 18 to 24 months from now.
🙂
Yes… We’ll see about that.
But for now I would say let’s introduce both to get the organization ready for Agile
wow.. nice artikel
apa beda nya scrum sama apps bucket list?
Paulus, which bucket list apps you refer to?
Scrum is a framework that usually used for software development under Agile Methodology.