A manager working for the media industry asked me a few month ago whether his teams should use Scrum or Kanban. He had sponsored agile teams I coached for 2 years. We worked together but didn’t get into the details of methodology, so we knew each other (explains my familiar tone). Here’s my answer.
TL;DR : since I’ve been working at France Televisions Editions Numériques I’ve already been coaching your teams to Kanban, so you’re not going to get lost. You’re already doing flow development, like M. Jourdain speaking prose.
WTF are Scrum & Kanban ?
- two variations of Agile methods = two subset of practices, not necessarily exclusive
- Kanban (also labelled Lean IT or Lean Software) is a software development flow = you pop functionalities from a backlog and you check the counter every iteration
- Scrum follows the same principle but with strongly imprinted iterations, more protocol and meetings, in particular iteration planning, detailed task decomposition, estimation and a « commitment to deliver » at the beginning of the iteration. That’s not far from being a mini-waterfall cycle.
These methods are just starting points. While continuously improving teams will perfect them. Over the course of the project new practices will be integrated, modified or removed in regard of the time and context.
Kanban, because you’re worth it
My reasons for recommending you a development flow are
- it encourages better coding practices : baby step development, systematizing development and quality processes, emerging and minimalistic design
- Scrum do recommend good coding practices but enforces nothing and it’s a lack. I find that teams doing Scrum usually do not care enough about their coding practices, or too late in their product development.
- In a flow you’re more reactive, you can introduce minor evolutions on the fly (just in time), let an ambulance pass through the traffic, which is more adapted to your activity [my client was working in the web / news media]. It’s never a 0 cost operation but it’s never a problem of methodology. With Scrum, adding a feature inside an iteration is seen as a disturbance (translation : violating the dogma)
- Kanban is just more efficient, drier : less chit-chat, less fuzz, simpler to deconstruct and to adapt to each context. Scrum needs half a day of ritual meetings per week of iteration, with Kanban you get down to 2 hour.
This evolution is where, by dint of continuous improvement, long journey team goes (after more than 50 iterations), or projects with high stakes or high risks, or mini-projects (having an implicit risk level due to their size).
It’s been 3-4 years I’m asking myself « what if we start by the best of ? » and it does work : young teams reach in a short time the maturity of long journey teams.
What duration for iteration ?
Apart from questioning the coding practices, the underlying question is the duration of the iterations : Scrum is more 2-week suited, but become too burdensome on a shorter pace (cf half a day of ritual).
Today I always recommend 1 week long iteration when a team starts : twice more learning because twice more retrospectives, short-term adjustment to their functioning, etc. I’ve let the [XXX] team start with 2-weeks iteration and we kicked ourselves (waiting 14 days to see if problems get resolved was unsustainable as the project start).
On the contrary, a seasoned team can be caught in the day-to-day (which is the point at early steps) and lack vigilance on long term planning. Some teams do like 2 week-long iteration to bring tempo within a long journey without specific deadline (like 4 month of development without a planned public release). That’s what the [YYY] team has chosen for example.
I think it can be meaningful to go on 2 weeks pace to a far away release for any team older than 10+ iterations, that already masters its flow with 1 week rhythm.
Like I usually tell the teams I coach,
I could have you do Scrum, but you’re better than that.