Why kanban and not scrum?
You are here, because I linked this for you and you wanted to know why I think Kanban can do exactly what Scrum does, but without the caveats.
Now stop bothering me about it!
TLDR: Kanban does the same, but with less waste and negative side effects on agency and well-being.
Deadlines
First point is, that deadlines are bad for people and the science on that is clear:
Sprints introduce a superfluous system of deadline thinking and only if it is executed with extreme levels of care, will it work:
“When goals (including deadlines) are set with a clear rationale and in non controlling ways, they can be energising and positively motivating. Yet, when set in controlling ways, often backed by threats or contingent rewards, they can be highly undermining of intrinsic motivation”
(Self Determination Theory, 2017, Deci & Ryan, pg. 149).
This means, you have to take extreme care to nail positive deadlines, and I say, why even try in the first place?
Failed deadlines
Failing sprints is part of the game of scrum, so what is their value when all you care about is increasing your velocity? You can do that without sprints.
Make no mistake, that Scrum also insists on very careful assessment of sprint results. It is an agile framework with a focus on continuous improvement - it is no different in this matter from Kanban.
When you think Scrum is the solution to a lack of understanding regarding your velocity or predictability, you should very carefully assess if you are in fact not doing the legwork to gather the necessary data to understand the velocity.
If you are not assessing the output carefully, you are failing in both Kanban and Scrum!
Scrum will not provide velocity data any more than Kanban, unless the work is done to gather that data. It simply provides a ceremony where people have to answer for why things didn’t happen and why the completely arbitrary commitment didn’t meet the deadline.
A much more important question is why work over time does not flow well. This addresses actual systematic issues and not only issues that are intermittent and visible in a resolution of a sprint.
Most people who advocate for Scrum, mentally associate, that as long as a sprint review is in their calendar and as long as those happen, it is proof that work is being done well.
Both actual Scrum and Kanban disagrees, and goes further to make sure that the speed over time, increases. Kanban and Scrum need data to make this possible, and the work is necessary for it’s success.
In Kanban, the focus should remain on improving the flow and any outliers that compromise the flow must be made visible and be addressed. Same outcome, but no arbitrary line drawn into a calendar and no deadlines.
Extrinsic vs intrinsic motivation
In an environment of deadlines, intrinsic motivators mean less. There is less room or no room for creativity and personal agency.
I personally think, that intrinsic motivation should be fostered and you should work to empower people in ways that allow them to be self driven. Any system that does this, reaps the rewards. Any customer service person who actually controls what they are allowed to say and have a sense of control over their life - does better work.
So I want to create social systems that increase well-being. And for projects that last for multiple years, these things matter. They are micro-societies and their social structures must be managed and structured with well-being in mind.
Agency is deeply important to workplace happiness and health and it is also the most crucial idea in the center of the welfare state.
Scope and crunch
Only managers and product owners have sustainable tools for making things in a certain window of time.
Crunch, quality loss and skipping training is the only tools developers have and these should also be managerial choices - with deadlines people self-impose these and it causes invisible project problems. There are no sustainable ways for an individual to reconcile with deadlines:
Why deadlines and sprints are bad for you
Predictability
Scrum and Kanban predictability are both based on the same system of velocity, it works in neither if it is not implemented.
However, some people say that even when velocity is not monitored, the idea of predictability “naturally emerges” from Scrum and that is the key idea why people advocate it.
It does not naturally emerge. It emerges from the fact, that velocity is closely monitored by the development team and they must make sure, that they do not include more future work into the sprint than their velocity allows.
There is no difference to that, than seeing how much velocity the team had in the last two weeks, and seeing from the prioritized backlog how much work will be completed next.
The work of prioritizing the backlog must be done and it is crucial to make that prioritization central to the whole operation of the team.
Retrospective and demos
They can be added to Kanban, and almost always are. The difference is that, in an environment of continuous delivery, planning is done on demand with only the required set of people and therefore, it scales well.
OVER-ENGINEERING and UNDER-SPECIFICATION
Within Kanban and Scrum and I would argue any framework, it is important to monitor the flow - make it visual and visible. Generate reports on it. The speed of the team should increase in agile as problems are addressed.
You must do the work, to identify outliers that cause the flow to worsen or not be as good as it could be - and investigate further into these outliers. You should find the actual problems, including over-engineering or under-specification with this mechanism.
Kanban and Scrum are no different in that.
Continuous integration
Scrum comes from an era where deployment was hard and it was necessary to have this idea that “we should deliver working software at least every two weeks”. The worry used to be, that we would see the software in a working state far too rarely and that is the problem we set out to solve with Scrum, and it solved it well - it reoriented the mindset from making big things, into making small increments and it solved the problem. This problem no longer exists.
Currently, the norm is that we deliver working software by the hour, multiple times a day. There is near perfect visibility to what is happening in the customer environment at any given time and there is nearly perfect tooling to follow what a distributed set of programmers is doing at any given time.
There is work management tools like Monday, Jira and Trello which can have in them, full transparency as to what is being produced, how long it is taking and what the flow is. There is also GIT and devops and all types of metrics around deployment.
The problems arise usually from the fact that these tools are not utilized properly, in Scrum and Kanban.
Scrum is better than kanban
If all you know is a hammer, then most things look like a nail.
The point is, that kanban can do all things that scrum does, but better. Mobile phones can do all things that landline phones can do, but better.
And landline phones are better if all you know how to use is a landline phone.
And Scrum is better than Kanban, if it is the only way you know how to work. You should still question if it is the minimum amount of management needed for a bunch of programmers to show up and do what you want. You should also question, whether Scrum is the best thing we were capable of coming up since 1993. You should question, who came up with Scrum, and what the Agile Manifesto actually states. You should read up on it, see what others are doing and try to open yourself up to other perspectives.
For any framework to work - you need adequate competence within it for it to be effective. As a professional of programming, if my colleagues ask me to make a program in C++ with them, then it is my duty and job to learn that language. It would be considered gross incompetence on my part, if I were to make the control system of an airplane without taking the time to learn my craft. It is expected of me, to know what constitutes the critical parts of the system, and to build those well.
Now, if you manage a team of people who make said airplane, then would it not also be naturally expected of you, as a manager, to keep improving yourself on the methods with which people are managed. If you think that’s impossible, then this post is exactly for you! It is also expected of you, to know what constitutes critical parts of the agile framework to build them well.
The thing that people in managerial positions and often in any professional capacity consistently get wrong, is that they view themselves as complete when they have a few projects under their belt. They assume, that what they bring to the table is immediately “going to work the best”. I’d invite you to reassess that idea, seriously.
Kanban is clearly not the end all of how lean things can be made. It is leaner than Scrum and hopefully as technology allows, we will find leaner models still.
My responses to common arguments
-
The backlog is not prioritized properly if the team is doing the wrong things.
I would also argue, that your retrospectives are not creating the intended value if you’re not looking at the data that Kanban and Scrum should have. I would argue, that retrospectives for Scrum should also look into velocity and outliers of past work instead of just focusing on how everyone feels every time.
-
It should have the same amount of predictability if the velocity is monitored, and used to generate reports on the work. It fails to do this, if the data is not used and it is implemented halfway. Scrum does not provide any more predictability unless velocity is monitored.
The only difference is, that monitoring said velocity becomes the problem of the team rather than the managers and that is why can be potentially viewed as “better” in Scrum.
-
Deadlines do work, but their downside is a worse workplace.
Dictatorship works, but it makes a worse society.
-
It is silly to assume, that “bad prioritization” is a problem that only exists in Kanban. Kanban allows the product owners to select any single thing or a thousand things, and orient the team to focus solely on that single thing. To do that, you need to make sure, that the upcoming work in the team backlog consists of only a single thing. If you want a team of 8 people to do only two things at a time, then the WIP limit must be set to 2 and you must only track that on the story level.
If you want the team to work on everything all at once, you set the WIP limit to the amount of people you have. This is fully in your control.
Good WIP limit systems allow this to be set across the whole work system, on a single lane, per person, per feature team, whatever you want.
Again, the key is, that that work needs to be done.
-
If you have a big team where everyone works on different things, this is a recipe of bad focus. Kanban can easily scale to doing singular things with multple people or multiple things in parallel and this is simply a problem of managing the parameters.
The team should manage these parameters in lockstep with the customer’s wishes.
Deadlines can seemingly impose better focus, but it does this by forcing people who feel like they are under a deadline to prioritize their sprint commitment over helping out colleagues or reviewing their code. It will shift the dynamic to creating different bottlenecks in communication and in code review.