Do you also use Kanban only for simple tasks and maybe for operations or DevOps teams?
Often you see an image of a Stacey matrix in which methods/frameworks like Kanban or Scrum are mapped.
Do these illustrations only describe the predominant use of these methods in reality, or is it also a valid statement about the suitability of the methods for complicated and complex tasks?
What is your opinion?
Here are three examples of such mappings (the first one needs a little scrolling and all are in German, but I’m sure you get the point anyway):
Maybe its because it is late on Friday, and I will admit never having seen the Stacy Matrix before (looks like its Cynefin which means we are immediately into culture wars and cliques) so maybe I’m missing something here, but the idea that you decide on method based on these criteria looks like non-sense to me.
I usually tend towards Kanban for teams with lots of BAU - unplanned but urgent work - and Scrum style working for teams with more control over inflow, but then, I usually tend towards my own Xanpan method.
I recall an airline team I worked with 10 years back were we adopted Kanban not because the problem space was complicated or because the requirements were unknown but because the airline had outsourced everything which moved and everyone blamed everyone else. Until we mapped out the workflow and ran it we couldn’t start to debug the processes.
As to “not knowing what is needed” - almost everyone I meet believe they know what is needed and challenging that belief requires subtely.
The choice between Scrum and Kanban has nothing to do with different levels of complexity. In short: Scrum optimizes throughput, while Kanban optimizes reaction time.
You should choose Scrum, if the backlog items are mostly known before each sprint and sudden tasks with overwriting priority leading to the cancellation (or re-planning) of a sprint are a rare exception. In contrast you should choose Kanban, if new tasks often have to be worked on before the next sprint. This choice may even not be constant for a team: you can for example run Scrum during the midst of the development and switch to Kanban once the system is in beta tests with the customer. Similarly, even within the same product development, teams working on inner core parts may use Scrum while teams working on customer individual parts may use Kanban. (There should be a transparent and clear decision process on such mixed setups, though.)
(Maybe this is what Allan wrote, just in different words).
I hope no one here gets the idea of starting a culture war over Cynefin vs. Stacey Matrix.
From my point of view, it does not make sense to classify Kanban and Scrum in this matrix as it was done in the illustrations. Why I referred to these graphics is because they obviously reflect the perception of many users, but also consultants, that Kanban is not suitable for complexity. But I also must admit that the supposed Kanban systems are mostly just a status board. Many teams (especially outside of software development) make the work with these boards transparent, but for it to become Kanban, I think they should at least have work-in-progress limits. Something that already seems too complicated and needless to many users.
Oliver, could you elaborate a bit more on your opening statement?
“Scrum optimizes throughput, while Kanban optimizes reaction time.”
I agree that Kanban can have a shorter reaction time, especially for unforeseen events, than Scrum. What I don’t quite understand is why Kanban should be more optimized for this than for throughput, and even more so why it is less optimized for throughput than Scrum.
My understanding is that Kanban has elements of throughput optimization like the WIP limit already built in. Of course, it is also possible to use them in Scrum, but it is not a mandatory element of Scrum. Is it really throughput that Scrum is optimized for? I would like to understand the reasoning behind it better.
Fast reaction time requires changes and changes in turn increase effort (discussions, re-planning, unexpected dependencies, sometimes adapting your programming environment etc.) - what in manufacturing is called set up or changeover cost. This is the reason, why Scrum fixes the sprint content after planning. It makes it easier for team members to optimize their work and thus increases efficiency. The fixed sprint cadence in Scrum simplifies planning, i.e. when people or multiple teams depend on each others work. (Some Kanban teams do iterations as well, but this is then already a step towards Scrum.)
You can also see it in the key metrics of the two processes (again at least according to the plain vanilla methods): velocity versus cycle time and lead time. The first is a metric for throughput, both latter for reaction time. This reflects where each puts its focus on.
With all those technological advancements i.e. Cloud native and end2end responsibility within product teams, I wonder if the Scrum Guide shouldn’t promote very short product cycles more clearly.
progress toward a Product Goal at least every calendar month
(Scrum Guide)
Not sure why they left the monthly progress towards a Product Goal in the “The Sprint” chapter.
If I add up your arguments on top of my hypothesis “Scrum is not needed anymore in a Cloud native world”, this would be an advancement for all those who want to stick with Scrum but want to leverage the benefits from Cloud native and other technological advancements which speed up change rate and deployment frequency.
Too many organisations and teams are left with “standard implementations” with 14-day sprints.
Even the Stacey Model is easier to understand than the Cynefin model it provokes too much misinterpretations. Also the Inventor / Author of the Stacey-Model is saying don’t use it anymore.
I need to confess that I also suggest to try out Scrum and XP in the complex domain instead just using Kanban for several reasons. But I always also suggest to use it together - not one or the other.
When things become more unpredictable, where more is unknown than known - I feel : just using Kanban isn’t enough. For emergent work I think these agile methods put something new to the table and that addresses better the complex domain.
In software development for instance we don’t produce so much non-variable parts (Gleichteile, see a classical production line), but unique parts, that we try to re-use (like lego blocks). Looking for bottlenecks, optimizing for cycle-time, using WIP-Limits, etc. isn’t enough here.
Finally we shouldn’t forget about trying to move from the complex to the complicated and finally to the obvious/clear/simple domain over time.
A cloud native environment obsoletes several types of efforts, which are required for deploying to classical servers. A major difference may be, if your users are “only” humans or (how much) other software depends on you (e.g., are you implementing a B2C page or Amazons IAM service?). Depending on the type of software and customers, a release still can have significant constant effort. There may also be effort for the customer implied. It can also depend on whether you define a sprint by a potentially releasable increment or just an intermediate development version. In most larger development organizations, it is probably in-between: CI within a team, the result of a sprint can be reasonably used by other development teams, and releases towards customers (except patches) are a subset of that. (All this of course again, only where the focus is work efficiency, not reaction time - otherwise Kanban. In a mixed environment, the Kanban teams may not profit from fixed iterations themselves, but only do it for synchronizing with other teams.)
A further question may also be not development related though, but how often you want to do cost/benefit discussions to decide priorities and the work content for the next weeks.
Regarding the Scrum guide, my interpretation is, that they do not want to recommend any direction and instead leave it to your own responsibility. If I remember earlier versions right, the current phrasing became more relaxed compared to “2 or 4 weeks”. In the same paragraph, it actually says: “Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame.”