If you're at a point of noticing that your team is not delivering the results that you've been aiming for and are about to turn things on their head by going Agile, do take a moment to decide which of the popular workflow management methods is more suitable for you.
To find out whether Kanban or Scrum is better suited for your specific team and process, first take a look at what you are doing now and how a new method could potentially build on that.
If your product changes a lot and needs to have its basics reorganized quite frequently, the most natural choice would be to go for Scrum with its Sprints. And when what you're working on is more of a continued service, directed at one and pretty much constant goal, then it may be easier for your team to adopt Kanban and put all the focus on finishing the already started tasks.
Kanban is optimized for just in time delivery, it facilitates items working steadily through the process stages at a set pace. That pace can easily be regulated with the Work In Progress Limits. Thanks to WIP limits, people have a much easier time focusing on the task at hand and the team, as a whole, stands a better chance of finishing the tasks they have already begun.
Normally, Kanban assumes keeping an open backlog of tasks from which items can be picked up by the employees. This offers a chance to better optimize each person's day, letting them pick similar jobs for one day so that the waste of having to mentally readjust from one type of task to another is minimal or none.
Kanban also makes for a quicker delivery time, simply because of the fact that as soon as a single task has successfully moved through all the stages, it can be delivered to the stakeholder and set aside as done. This is not easily achieved in traditional workflow management, where items are marked off as done in batches set for regular, often less frequent intervals. Notably, while deliveries may occur more often, they are smaller, which could be seen as either a benefit or a disadvantage.
What can be more tricky with Kanban is getting correct estimations on delivery time, since new items are always added to the backlog and some gain priority higher than already existing tasks.
This is an issue that can, however, be resolved by splitting the backlog into things to do next and sudden, expedited tasks. So, leaving the team to pick one task by another, but making room for urgent service work too.
Scrum, on the other hand, puts focus on setting a goal for a given period of time, 2 - 4 weeks, and working daily towards achieving it. The main advantage of this approach is having a delivery due date, upon which everyone has agreed. There is also a greater sense of collaboration, started at the initial Sprint meeting - the team is aware of what everyone else will be doing and they are all working towards a common goal, together.
It's a relatively comfortable position for the team to be in, as they can put 100% of their attention on working towards one goal, something many people forced to multi-task on a daily basis would definitely envy.
However, arguably, the most difficult aspect of running Scrum-based Sprints lies in the very timing of the planned goal achievement. Even if your team works on similar projects all the time, there will often be times when something they thought should take a month will take 6 weeks due to nobody's fault at all.
We just cannot always foresee exactly what a job will entail until we go in and start working on it. This goes for knowledge-based work in particular.
That is why doing Scrum sometimes becomes a reason for tensions and misunderstandings between the team and managers.
But with either of these methods, you will gain one thing - a visual insight into what part of the process the team is currently in. This, along with potentially better task processing is an advantage over the more established, traditional methods.
If you're not sure which will work better for your team, try Kanban - it's less demanding to start with and can incorporate Sprints too, should you want to try these out.