Scrum? Kanban? What about Scrumban anyone?
Scrum is probably the most famous and popular implementation of Agile going... It's established, structured and well documented, with clearly defined roles, responsibilities and ceremonies.
I've written a few blog posts about Scrum but if you're new to Scrum it's probably worth reading my article 'The ten must do's of Scrum'
Probably less well known or understood is Kanban, Kanban doesn't have the structure of Scrum, its less defined (or rigid) and is very good for operationally led teams as opposed to project/product based teams (which tend to better suit Scrum)... yes it's another plug for my blog! But if you want to know more about Kanban read 'What is this Kanban everybody is talking about'
A problem I've encountered a lot - especially in smaller software houses is the pull between project/product work and operational work - often with unclear priorities being set, little project management in place to support the process and even less visibility!
Kanban is brilliant as a tool to understand systems and flow.... it show's bottle necks and helps the team and management visually understand the flow of work (or not)
Now at this point... some will argue that good Scrum does or should use Kanban techniques and Kanban should be trying to build better teams as per Scrum - and I agree with that argument.
However I still believe that Scrumban is a technique in it's own right and in many organisations where pragmatism and compromise are part of reality it has something to offer - even if just a discussion starting point!
So how do we do Scrumban? Well, as with all things Agile there are numerous implementations - I'd suggest starting simple (depending upon how experienced your team are with Scrum and or Kanban) and refine in iterations.
1. The first thing you'll need is a board/project board/Information Radiator.... and simply define your 'To-do' Queue and the relevant swim lanes for your organisation - you should also define your WIP (Work-In-Progress) limits... I'd suggest this is linked to team size, team of 4, WIP = 4 (To start.. Or perhaps team size -1)
2. Maintain the product backlog... But not too much! Unlike Scrum you should aim for the product backlog should be smaller, more limited? And be closer to options. The Scrumban Backlog is likely to be event driven, aim to just know what the team will be working on next...... and expect it to change!
3. Planning meetings - In Scrum these planning sessions are held at the start of the Sprint - In Scrumban the meeting is held at the start of a cycle - what's the difference? Sprints are a predefined length - however a cycle in Scrumban are held based on the number of jobs left in the To-do queue. So for example when the number of items left in 'to-do' hits a defined trigger point (lets say two 5) this triggers another planning session - end of one cycle, start of the next! Each planning session will define the priority of work and move these jobs to the 'To-Do' queue, just as you would in Scrum.
4. When the Sprint/Cycle begins... start pulling jobs from the work queue, respecting your WIP swim lane limits - Allow team members to select/pull tasks… No allocation.
5. Respect the WIP limit... if you decide that no-more than 4 tasks are allowed to be in progress enforce it.. if a job hits a blocker, can't continue, or a new job takes priority .. it goes back on the 'To-do' list... doing this helps to enforce focus and reduces the waste caused from constantly switching.
6. Review Meetings - Just as you would in Scrum, Ensure that you have review meetings with stakeholders, clients.... This is often how software teams come in contact with the end-users... it ensure's clarity, understanding and helps to build trust between teams.
7. Retrospective Meetings - I love a good retrospective.... And so should you! try and hold this after the review meeting.... agile is about refining the process, introspection and iterative improvements.... ensure that you hold these meetings and that you feedback into them.
8. Stand-up meetings.... these are probably the most famous aspect of Agile... I've met teams that believe there doing Agile just because they have a daily stand-up. In Scrum these are very defined, "What did I do yesterday?", "today", "impediments"... In Scrumban they should be very much Kanban board focused.
9. Metrics - In Scrum you typically have velocity, this can lead to inflated estimates, poor enforcement of the definition of done (which leads to technical debt) or a rush to complete every story within the 'time-boxed' sprint which leads to a lack of quality and again technical debt! In Scrumban you have a cycle time, the length of time it takes a number of tickets to move through the system from left to right - by calculating mean cycle times and using standard deviation you can gauge a sort of velocity - IE. A team of 5 might take 5 days to complete 10 tickets.
The following guides should be followed by Scrumban
Keep the backlog small
Plan on demand
As you progress - allow some multitasking, perhaps having your WIP = team size + 1
Use average lead and cycle times to measure performance - not velocity!
Let the team pull tasks themselves.... don't allocate!
Think about deployment... and plan for it in the sprint/cycle
Scrumban is perfect for where a team needs to adapt and change fast... where project/product work is not predictable (or poorly defined) or where teams are heavily involved in support work.
By limiting the teams WIP - it helps to ensure that teams finish what they start to a higher standard.
And finally, good luck - and if you have any Scrumban stories... good or bad please share!