What is ScrumBan and why is it a popular option for agile teams?
Welcome to part 16 of our agile coach interview questions series where John McFadyen answers common questions asked of agile coaches and scrum masters in interviews and client engagements.
I’m going to assume that you know what Scrum is and I am going to assume that you know what Kanban is when I answer this question. ScrumBan is simply the mashing together of Scrum and Kanban in an agile product development environment.
Why is ScrumBan popular?
Very often, you will have a scrum team working on product development but for some reason, their cadence in the form of sprints just isn’t working well for the team and they decide to let it go.
Once that happens, you often find that the team will migrate over to full KanBan for a while but also find that it doesn’t check all the boxes and they aren’t achieving the goals and objectives they want or need to achieve.
In my experience, the team will migrate from one to the other over a period of time before deciding to settle somewhere in the middle.
Sprint Planning
Very often, that looks like Scrum without the planning element.
So, they drop the formal sprint planning meeting but retain the daily scrum. They haven’t dropped planning altogether because they are now planning every day and using the daily scrum to update the team on what they are working on, when they anticipate being done, and what potential impediments are in the way.
Sprint Review
The team will still host a review because they need to present a finished product or feature to their product stakeholders and customers, and they still require the feedback from those reviews to inform what they work on next and what they need to go back to the drawing board with.
Sprint Retrospective
A retrospective will also still take place because the team are committed to continuous improvement, and they want an event that empowers them to tackle problems and identify opportunities for improvement.
It also makes sense for the team to schedule the retrospective after the review because it allows them to use the feedback from the review to inform what they should be considering in the retrospective.
Backlog Refinement
They also tend to work with the product owner on a more ad-hoc, informal basis than a formal sprint planning event. They will still engage the product owner to identify what is valuable, when the most valuable time to perform that work is, and what the requirements are for that work to be considered done and ready for release to customers.
The product owner will work with the team to ensure that the most valuable work is always at the top of the backlog and make sure that they are available to talk to the team, or individuals on the team, as and when needed throughout the product development process.
The team are still doing backlog refinement. They are still selecting items from the backlog and making sure that it is ready to go for production and as such, they may need to call on the product owner, product stakeholders or customer to have a conversation about what that problem might be and what the most valuable outcome looks like.
Summary of ScrumBan
So, there will be continuous pull from the backlog items but there will be a cadence of delivery where every two weeks or four weeks, the team host the review followed by the retrospective.
The team simply review whatever has been completed in that period, rather than focusing on what they thought they would achieve and why it wasn’t achieved. It is just a straight up focus on the items that have been completed and are ready for delivery.
Measurement
The agile team will still use burnup charts or burndown charts to assess what has been delivered within the cadence of delivery they have selected, and they will still be able to project estimates for work in the future based on past performance.
Why do Agile Teams opt to go with ScrumBan?
I always start a product development team with Scrum.
Some might think that is a preference, but it is quiet simply because I have found that Scrum is the best grounding for a new team. It is the best way to get them started and delivering valuable increments right away.
Why Scrum is a great place to start
If a team shift to agile, they must learn a whole new way of doing their job and in my experience, Scrum is the perfect foundation for that transition and provides a useful, lightweight framework for them to work within and evolve from.
Kanban is also a great approach for a new agile team, but I have found that it is far easier to let things slide in a Kanban environment than it is in a scrum approach.
The cons of Kanban
In a scrum environment, you have a sprint of 2 weeks and within that 2 weeks you have either delivered something or you haven’t. You can explore the reasons for that and identify what blocked progress, but you still are accountable for the delivery or non-delivery of a product within a timebox.
In a Kanban environment, some organizations would simply say that they aren’t finished yet when the two-week period rolls over, and simply carry on before without accountability, a review, or a retrospective to identify what went wrong, how to prevent that, and how to improve in future.
It isn’t ideal for a team to continuously let things go and proceed with accountability or review over extended periods of time. Your goal is continuous improvement, and your objective is to delight the customer through frequent and continuous delivery of valuable products and features.
Team Evolution
Once a scrum team have mastered scrum and are evolving into the next level of competence and capability, they might find that scrum constricts them. They may decide that they want to be more flow based rather than cadence driven. They may want to experiment with something new that allows them to progress to the next level of competence, capability, and excellence.
That is a great thing and as such, we should encourage those teams to explore other elements of agile and embrace things that serve the team well.
If the purpose of agile is continuous improvement, we don’t want a team to be locked into a framework that prevents them from finding the optimal processes, systems and practices that lead to excellence and customer delight.
This is the primary reason why an agile team may adopt elements of Kanban and Scrum. They may even explore other agile frameworks or practices and cherry pick the best elements to include in their environment.
A great agile coach will help them make those decisions, gather the data, and create experiments to prove or disprove hypotheses.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster