I have my preferences – Kanban and BDD – but don’t enforce these on my teams. That means I’ve got a couple of Scrum (ish) teams and teams that don’t use BDD. And I also have a bunch of people working in isolation – I just leave them to it.
Programme with more than one method
My preferences
I’m a fan of continuous delivery so favour Kanban over methods that mandate timeboxes (e.g. Scrum). I also encourage folk to use Specification by Example and outside-in-testing from BDD.
So, if I get to choose, then my teams will use these methods. But I don’t always get to choose.
Inherited teams
If I inherit a team that already have a process that works I’ll leave them to it. Although I have my preferences all the Lean-Agile methods – Kanban, Scrum, XP, DSDM – work. Any of these give me sufficient insight for monitoring and control based on sensible approaches to Planning and Scope management.
For example the teams I’ve currently got use any combination of Kanban, Scrum and BDD that works for them.
Individuals
As I’ve said before Professionals manage their own time – I don’t impose a process. So for the people on my programme team that work in isolation, I let them use whatever process works for them.
why do people still think that scrum forbids continuous delivery? it does not! If you read Sutherland 2015 book (how to do twice the work in half the time), he says he has seen teams using scrum and putting into prod updates few times a day. If your product owner is ok with CD, then do it. What is mandatory is the sprint review with all stakeholders. If by that time you already have early feedbacks from users/customers about the new feats you ve delivered, then it shortens the feedback loop and it s great. It s so common to miss the point and view scrum as process over efficiency, which is wrong and zombie scrum style. Plus, if you ve checked the recently released kanban condensed guide, which is a base for anderson 2016 full book, you ll see he is completing the framework so much it looks like scrum, even with same roles without accepting to name them the same way. quite funny, near ridiculous. well, i ll still use scrum with kanban style boards as i like to check teams’ bottlenecks.
6 months before your post, interview of Sutherland, his answer about kanban and scrum :
“Kanban is about making the work visible, measuring cycle time, and minimizing work in progress – and a good scrum team does all of that. What scrum adds is a team, a sprint, a product owner and scrum master. If you look at kanban, it is slow when they don’t have a team but work in silos. They say that the value of kanban is that you don’t have to change your organization, but if you don’t change your organization things don’t go any faster. You just see where the bottleneck is.
In order to make kanban fast, all of sudden people are working as a team, they are having a daily meeting, and someone is managing the flow of the backlog. All of a sudden, it starts to look like scrum.
The same thing happened on the scrum side. One of the major goals ten years ago was to deliver to production at every sprint. Today we are beyond that, delivering to production every day. Now stuff flows into a sprint one piece at a time. It looks like kanban, as the release is de-coupled from the sprint.
The best kanban teams will look like scrum teams, and the best scrum teams will look like kanban teams.”
http://planet-lean.com/in-this-interview-planet-lean-speaks-with-jeff-sutherland-one-of-the-inventors-of-scrum-about-the-evolution-of-this-agile-methodology