First, I have to say that we use Kanban and Scrum as Agile Framework. For today, my point is not to know if Kanban is Agile or not. This is like that in my company. As I was saying last time, the It department is more than 1000 in France, so we talk about a big Agile transformation.
At the beginning of the transformation (end of 2010), we only got one Agile framework which was Scrum. We got a lot of success, but also some failures. During the summer of 2012, we got a discussion in the Agile Center and we assumed that it was mainly due to the culture of our society (control & competences) and by the fact that our coaching was always like a big bang. Because we got also one success with a Kanban approch, we decided to adapt our Agile transformation pattern. It is now driven by the impacts whished and pain points to take care. During the qualfication, we want to know why Agile and what are the problems of the team. Then we chose the agile framework which is finally more a patchwork because we use all the practices we think are necessary for the team whatever it is from Scrum or Kanban.
The next question is which information push us towards Scrum or Kanban :
- Size of the team : Scrum is a well framework for a pizza size team. It’s more complicated when the team is small (<3) or big (>10). For the big team, we can work with a Scrum of Scrum. However it’s not always so easy because the scope of each team should remain stable.
- Fixed scope during an iteration : It has to be like that when working with Scrum. But, it’s sometimes difficult when the team is dependant for other one. For example, a team has decided to switch to Kanban because the vendor of a software never respected his commitment in terms of date. They always had to change the scope during an iteration. It could however be interesting to work with Scrum because sometimes the scope change often only because the PO is not so well organized. By highlighting this issue, it’s a could way to start fixing it.
- Workload : When people of a team work on multiple projects or applications, the workload available for an iteration is not reliable. It’s easier to deal with that fact with Kanban because the main indicator is the cycle time. It remains stable, we adjust the number of features done. With Scrum, the velocity is not stable enough to be predictible. It’s often the case when the team also do production support.
- Culture : After reading the book “An Agile Adoption and Transformation Survival Guide” from M.Sahota, we realized that the primary culture of our company is “Control” with “Competences” as second one. We may have some issue by using Scrum which is more on Culture and cultivation due to the fact that the culture of the team is opposite. We know try to understand what is the culture of the team we try to transform
- Start with what you do now : The Kanban practitionners know that I’m talking about one of the main property of Kanban. Ok, but what about a new team for a new project ? They have no current process. Scrum helps a new team by giving them some guidelines to work together.
- Business way of thinking : It’s a little bit related to the previous one. We you build a new application, you mainly talk about scope and delivering some new features. => The indicator is the velocity. If you work close from the front office, they like to talk about the time to market of a demand. => The indicator is the cycle time
- Rupture : We are not a start up. We have started a Agile transformation because our CIO has decided so. This year, he wants 40% of the projects in Agile. So we got a new rule : Every new project should start with an Agile mode. If not, the project manager should explain why and the management should agree. That means that some managers only want to become Agile because they have to. They could be afraid, reluctant,… We had more success with Kanban with this kind of profile because we begin with “Respect current roles and responsabilities”
- And my last one for today. Scrum talks about cross functional team. Sometimes, the reality is different and we got a lot of specialized people. It’s good to have a cross functional team, so we think it’s possible and valuable we push towards Scrum. If not, we push towards Kanban.
I’m quite sure that this list is not perfect, it help us to chose our framework. We have also been challenged by some IT managers about how we chose. So we now have a checking point with another coaches of the Agile Center to confirm the choice of the team’s coach.