We used Kanban only but since some situations Kanban wasn't enough, we decided to take Scrumban. Why? -> kanbantool.com/kanban-library/scrumban/scrum-or-k… We didn't want to resign from Kanban but still we needed some new attitude to solve problems.

We have a small, specialised and nimble team of developers working on an internal project. After some experimentation we are currently using a hybrid of Scrum and Kanban. It works for us because we already have a set of processes and there is no need for a complete shake-up. The planning, retrospective meetings and daily standups do happen, but we have put a restriction on the number of WIPs in each column. Thus whenever there is a chance of bottleneck, the developers join in to move the cards to the next stage.

We tend to use a mixture of both Scrum and Kanban. You can do several scrums for individual projects and requirements, and then have a governing layer of Kanban on top of that (to control and re-direct resources between the various requirements where feasible).

I am still waiting for a tool that can smoothly integrate the two.

We are an IT services company (we develop products for others) and we use Scrum.

Primary tool is Jira, but in some cases we use tools mandated by our clients (StoriesOnBoard etc). All the backlog is captured within the tool and the team is able to estimate what can be developed in a single iteration. At the end of the sprint, we demo to the client. This gives us couple of advantages:

• Client always gets a product that (s)he can play within every 15 days. They can judge the progress of the product development quickly and change course, if needed.
• For us internally, we can estimate our velocity and calibrate our productivity.
• Every developer understands what needs to be developed; so it brings down 'I thought you said this or that' kind of discussions.

Of course it still depends on the people you put in the process. There are still quite a few projects where we struggle. But mostly, we find Scrum useful.

No, we use a derivative of Kanban;

Scrum is not flexible enough for a small team working on mostly startup-related projects with constantly changing scopes - usually by the time we were halfway through the sprint, half the sprint had already changed, some features became obsolete meaning some devs were doing nothing, new urgent fixes and features creeped in all the time and the overhead of doing sprint-planning was just too much - burndown charts never matched what was actually happening.

With Kanban work is assigned as soon as devs become available, if they need to stop something mid-way to work on something much more urgent, we can do that, we don't have to waste time assigning points to things - if it's a small task, do it now, if it'll take longer than a day, give it a priority, place it in the queue and whoever gets to it first, they get to do it.