Mixing Scrum and Kanban (Scrumban)

At my previous job, my team was part of a pilot to switch over to an Agile methodology for development. It was generally successful so we continued doing it after the pilot had ended. We started with Scrum, and did Kanban when needed, and ended up merging the two into a sort of "Scrumban" process. This was just based on our experience with the two processes as a team, and not based of any official sort of Scrumban process. 


Scrum
We first started off doing Scrum for development; as I suspect is common our estimates weren't too accurate initially, but we still got everything done on time (even if not done as part of a sprint), and estimates got better over time to the point where story point estimation could be used in advance for planning. We started off with a white board and post it notes, but then moved over to using the JIRA Agile plugin (the story details were in JIRA, so it was still part of the process). 

This worked fine for general development. We did 2 week sprints, and had a little bit of time left at the end afterwards (the development time was not a neat 6 weeks, and we didn't start a sprint on a Monday so there was always a mid-week end). We still had bug fixes that needed doing, but we split the team into two "streams"; a large stream doing story development, and a second stream (of one or two people) just doing bug fixes for the duration of the sprint. This team rotated so team members had experience on both streams. 

Kanban
Scrum worked for developing something based on a story, but we would sometimes have a backlog of bug fixes that needed doing (and, as mentioned, might have a bit of time between some sprints). For this we used Kanban. 

All issues scheduled to be fixed were in the "To Do" column in JIRA. Anyone could pick what one they wanted to do to move into the "In Progress" column and work on (my personal best was fixing 5 issues in a day). We still had daily stand up meetings, but there was no task estimation (as there were no stories). 

Scrumban 
At some point we decided to a variety of factors to mix the two together. We wouldn't fill a Sprint completely with stories, instead reserving some of it for bug fixes. On the JIRA board, each story had its own section, with all sub tasks underneath, and there was an additional section for "Other" which had all issues to be fixed (with no sub tasks). 

Everything being on the same board meant that at the stand up meeting we could see everything that everyone was working on in one place. We still had weekly backlog meetings for upcoming stories, occasionally discussing an issue that needed fixing, but only when a major change was potentially needed. 

At this point we had stopped estimating the time required to complete a sub-task of a story (we had stopped doing that before we switched to Scrumban however); we hadn't been following the automatically generated burndown chart anyway as it was fairly clear from the board how things were progressing. We had a stable velocity so that was used to fit in the number of stories we could do in a sprint, and as we were experienced with the process it was generally accurate; we didn't miss a submission deadline and had all features delivered before any system testing started. 

Sprints had gotten longer, which meant we had more to do in a sprint, but more time to get it done in. We just had to keep a closer eye on any delays. The longer sprints did mean that we didn't do a demo as often, so whenever we did one we had to ensure that it was well prepared beforehand so we could go over it quickly (this is a general good idea for a demo). 

We had stopped doing a retrospective, I don't think consciously, we just forgot a couple of times and didn't really start doing it frequently again. There was less of a need to have one as we had already had a few years of fine tuning our process to work well, but I still think we should have done it occasionally. Also, with the longer sprints, we would be implementing improvements on an ad hoc basis, in order to benefit from the change straight away (which was a good thing, considering the alternative would be potentially waiting 5 weeks before we would discuss it at the end of a sprint).   

The team size was smaller than when we first started, so the combined approach worked well; we didn't have enough people to realistically split the team into separate streams, meaning having story development done at the same time as fixing issues worked well as we could get them both done without having to focus on one or the other. 

In summary, I think our Scrumban experiment worked well overall. We could only get to it through our experience of both Scrum and Kanban, meaning we could take what benefited us most from the two in order to get a process that was a more custom fit for our needs. We were good with hitting deadlines, and I think having a process that we knew well helped a lot.