Is “doing Kanban” just having tasks on a board without any sort of sprint structure? I feel like it’s a bit of a false equivalence. While I won’t ever defend all the cruft that comes with Scrum, the article seems like a bit of a straw man.
Someone is either working on a task, or idle. A task is either being worked on (making progress), or it's not being worked on. -- A task will get completed quicker if you can minimize the amount of time it's "in progress" but not being worked on.
If you have 5 workers and 15 tasks in progress, 10 of those tasks won't be making progress.
Often, a task may be blocked by requiring some action from someone else. (e.g. PR review, or more resources, or blocked on some other task).
The 'kanban board' is about visualizing work in progress. -- By visualising the work in progress, it's easier to identify bottlenecks & inefficiencies.
However, it's not so simple to read. In some cases tasks were blocked because of a superficial or nonexistent analysis, which required to get more information. Which is a clear break of the flow, since it has to be paused for the time before the meeting can happen. But sometimes, the analysis can be fairly bad and very time-consuming on the other department, making the broken flow more efficient than the flowy one if you account for the whole team and not only developer time.
Which seems to me that it's a good idea to optimize for flow only after you have enough consistency in the process, but still a powerful tool.
That being said, I would say that having a Kanban board without any sprint structure (or any attached micromeetings) would skyrocket my productivity. The two-week sprint thing is meaningless to me - in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint, it's an utterly meaningless distinction.
Whatever the management benefit supposedly is, seems like it could be achieved with declaring current (not 'sprint'^) goals, and a filter for tickets done/progressed in a given date range?
(^Even the language is depressing: sprint, ticket, points, standup, sit down, keep moving, ...)
That's not Scrum then. You don't add stuff mid-sprint, that's the whole point. Unless the world is literally on fire, you don't touch the sprint content.
What's your scrum master doing when you get stuff added? It's their job to prevent it.
And if work overflows, you need to spend time grooming the tasks to manageable chunks and adjust the team velocity. You can always pick up more tasks if you run out of stuff to do.
The real solution is of course not to have any "sprints" at all. A manageable chunk of work is a 3 to 6 month project.
Non-tech enterprise treat software engineers as children and create bad software. FAANG and adjacent companies treat software engineers more as professionals and create better software.
Waterfall-style projects had 3 to 6 month timeframes of delivery and we all know how that goes. The result is always either out of date due to changing requirements or not what the customer wanted because there is no way to change course after the project specification was locked.
...or you spend so much time doing an exact specification that the Agile team has already delivered 3 incremental versions.
Waterfall were 1 to 2 year projects with heavy up-front administration. 3 to 6 months is well-balanced and that's what the "elite" companies and research groups tend to use. Two weeks is the current fad at non-tech enterprise.
The team members are too busy with agile meetings to write software. That's a more common problem.
Maybe giving the tech lead a technical secretary is a better idea if you have a lot of administration to be done.
After the team is mature enough, one of them can take the SM duties in addition to other tasks because the actual process runs without extra management.
There's really no point being that strict. I think two week meetings/sprints are good for keeping focus and as an opportunity to agree short term priorities. But the point is to get work done, not to precisely obey scrum rules.
If the "you" is the team, go ahead. Add anything you want, as long as you deliver what you promised in the beginning of the sprint.
If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No.". Then they can start discussing if it is so urgent and important that it can't wait 1-10 business days for the next sprint and/or small enough not to disrupt other work.
The rules are there to protect the team. If the team is willing to take ad-hoc work, nothing in the agile rules says they can't do so. The point is that nobody outside of the team can force them to take on extra work mid-sprint and disrupt their planned work.
I hate working with people like this. So unhelpful.
A scrum master? Man, I thought my team was bloated with process but the fact that role exists elsewhere means I should probably be more grateful.
Some people might debate on how active a kanban board should be.
Metrics/Analytics can be calculated when your done based on actual information, as opposed to the beginning when you're guessing, and likely to be held to your estimates.
Kanban isn't there to dictate process, but as a tool to correctly and truthfully inspect your process.
E.g. we recently used length of UAT column to prove that we need more business people doing testing in next few weeks as we close to feature release and more tests take form of exploratory testing.
Scrum isn't blind to benefits of such inspections either! So doing simplified Kanban board is frequent.
In my previous job we used it and I liked it, but I haven't used Scrum before so I can't comment as to how effective it could be.