did you find the talk you were looking for? I've probably watched most of them 5 times or so, so I might be able to help you find it if not... as for sprints, we 'use' them, but it's basically just managers that pay attention to it... for the people doing the work, the routine is to work the work that's there, what sprint it is or what sprint it will be tomorrow or whatever doesn't change how the work happens

and if you have a key phrase or something, searching in <https://github.com/matthiasn/talk-transcripts/tree/master/Hickey_Rich> might help

That’s from Simple Made Easy

re “did you find the talk you were looking for?“: in a way, yes (will get to that later); thank you for asking. I was looking for “Are We There Yet?” It looks like the original source is https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey/ … but I wasn’t able to find it with https://www.youtube.com/@infoq/search?query=are%20we%20there%20yet; presumably because InfoQ (or whoever did the recording) never did the work to combine the slides + video of the speaker into a single video. Searching the rest of youtube (and that’s how I came across this one on sprints), I see 2 so far that have done this work of combining slides + speaker: 1. https://www.youtube.com/watch?v=ScEPu1cs4l0, with more space given to the slides and Rich only in one little corner 2. and https://www.youtube.com/watch?v=E4RarTAZ2AY, with more space to see Rich. My question would be (and thank you if you’ve watched this already and are able to help!): for the purposes of my education, is 1 or 2 preferable? Does Rich actually turn around to write stuff behind on that whiteboard and that’s why I want to have a visible view of that?

re https://clojurians.slack.com/archives/C03RZGPG3/p1697330028717179?thread_ts=1697328969.846909&amp;cid=C03RZGPG3: thank you Alex! I will be sure to check that out for more 🙂

from what I recall, Rich never uses or references that whiteboard behind him, so the only real difference would be gestures/facial expressions

gotcha. Thank you!

Going back to your original question: where I work we've used Scrum and sprints while we are in product development mode but each time we've gotten a product to market, we've switched to Kanban for ongoing maintenance and additional feature work. As Rich says, you don't want life to just be endless sprints 🙂 But we found the structure of sprints -- with regular retrospectives and planning every two weeks inbetween -- to help with getting everyone on the same page about "what is/are the next most important feature(s) to build?" while you are going from zero-to-product. For us, Kanban is more suitable once we have an established product along with automated CI/CD, and developers can pull whatever items they want to work on from the "selected" pile and we can deploy fixes and features as often as we want as each piece of work gets completed.

We use kanban boards at my place and don’t really have a notion of sprints, unless you consider weekly meetings for mid-term planning as sprint planning meetings 😄 There is an unspoken assumption that you get easy tasks done fast, however. For instance, if you are asked to change labels on some buttons across the UI and it takes a week, you will almost certainly be asked why it took you so long in your next meeting with managers. With that said, we understand that a single ticket does not convey much information on the difficulty of a task. So for not-easy tasks, nobody will bat an eye if it takes you a week or even more to get done. For this reason, we disregard metrics such as “ticket velocity”, nor do we use JIRA’s scrum boards, since they require grouping tickets and forcing them to fit into 2-week time frames, which for many tickets, is simply unrealistic. At my previous job where we did make use of scrum boards, there was always a story that would cross between sprints, because it was something we couldnt reliably develop, test, and ship in 2 weeks.

The key with stories like that is to break them down into smaller pieces. You can always use feature flags to allow you to ship incomplete features without breaking existing features (we use feature flags heavily). I try to make sure an individual ticket's work is generally at most one day -- even if that ends up being one of a dozen subtasks in a story (and a story that genuinely spans more than one sprint should be an epic with multiple stories in it 🙂 ).

I used to like the feature flags approach, but I quickly found them frustrating because they were almost always used to simply hide a bunch of unfinished features and introduce “noise” in the the codebase, where “noise” means “branches of code that are ultimately meaningless, since clients will never cause their execution”. I do agree with your first point on breaking down stories, though!

With that said, we have a few feature flags on the software we work on. I’m just not as excited as before when my manager requests a new feature flag 😄

Sprints, as with any tool, should provide a well understood value by everyone involved in their use. The team should be able to decide which ways of working are most effective and have the scope to learn how to use any tools effectively. There are many stories of teams being abused by sprint and many other process tools, which is driven by limited understanding of how a particular team works. Personally I use kanban as it encourages the team to consider how they work and allows for incremental improvements to their workflow. Understanding the challenges of each team is the first step in deciding if they have the most appropriate tools to support their work. Kanban also helped me focus on writing smaller stories with a more consistent scope, minimizing the need for estimation and allowing a more flexible approach to planning work, e.g what is the next most valuable thing to work on. All these things can be done with any process tools when they are used as tools rather than dogma.

I much prefer Kanban, but often when people say they do Kanban, they mean something like "Scrum without the sprints", and don't use real WIP limits, SLEs, or statistical controls (e.g, item aging, cycle time distributions). But most of my Scrum experience has really been waterfall-style development with scrum ceremonies.