Note on Scrum, an implementation of Agile; and Kanban, a method to improve functionality once a system is deployed.
• Use Agile/Scrum: to build and deploy systems
• Use Kanban: when incrementally improving a system once it is deployed and stable.
‘Scrum-Ban’ is a mixture of both Scrum and Kanban. It is a compressed view of incremental improvements once the project or code is deployed and stable. It is not full Kanban, and should not be used to replace Scrum. Scrum or Agile is for project (code, migration, refactoring etc) work. Kanban and the use of Scrumban is for the next phase of incremental, discrete improvements. Neither replaces Agile and neither should be used as buzzword bingo.
When to use Agile/Scrum: when the requirements are somewhat vague, you are building code and engaged in a defined SDLC; when the platform details are not fully understood; when you have a small team and either share the same office, or have proper Agile tools and communication.
When not to use Agile and to use Waterfall: When you have large teams; the project is very complicated; there are numerous sign offs and necessary stage gates; you are a dispersed team; the project and platforms re well known, understood and confirmed.
For most projects a mix of Agile and Waterfall is used.
Scrum vs. Scrumban
(Table above from: https://www.agilealliance.org/what-is-scrumban/)
Summary of Scrum organisation:
• Split your organization into small, cross-functional, self-organizing teams.
• Split your work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item.
• Split time into short fixed-length iterations (usually 1–4 weeks), with potentially shippable code demonstrated after each iteration.
• Based on insights gained by inspecting the release after each iteration, optimize the release plan and update priorities in collaboration with the customer.
• Optimize the process by having a retrospective after each iteration
Summary of Kanban Organisation
• Visualize the workflow
• Split the work into pieces, write each item on a card, and put it on the wall.
• Use named columns to illustrate where each item is in the workflow.
• Limit Work In Progress (WIP): Assign explicit limits to how many items may be in progress at each workflow state.
• Measure the lead time (average time to complete one item, sometimes called “cycle time”), and optimize the process to make lead time as small and predictable as possible.
Summary of what is Scrumban:
• Scrumban = Scrum + Kanban
• Use this if Scrum is challenged by workflow issues, resources and processes
• Or to manage improvement communities during/after Scrum roll-out
• Use the prescriptive nature of Scrum to be Agile
• Use the process improvement of Kanban to allow the team to continually improve its process.
(table above is from https://www.agilealliance.org/what-is-scrumban/)
In Scrumban, there is iteration planning at regular intervals, synchronized with review and retrospectives, but the goal of planning is to fill the slots available. This reduces the overhead and ceremony of iteration planning. Time spent batch-processing for iteration planning estimation can be replaced with a quality control inspection at the time that work is promoted to the ready queue.
Conclusion
In summary, there are some merits to Scrumban, but typically and for reasons around common-sense, ease of management, resources, training, and process-flow you will use Agile-Scrum, and then some form of Scrumban, or maybe Kanban to improve functionality. It is important that engineers are trained in the above areas and that we don’t assume that by implementing ‘Scrumban’ we are accomplishing anything. All methods must fit the purpose at hand.