3 ms·

Hi! I was involved in the Agile movement before the term existed. I came up through the "Extreme Programming (XP)" school of thought, and later on the "Lean" on

Hi! I was involved in the Agile movement before the term existed. I came up through the "Extreme Programming (XP)" school of thought, and later on the "Lean" one (in the Poppendieck sense of the term). Here's my take. The "sprint" is an artifact of the transition away from waterfall. Getting people to go from an 18-month planning cycle to a 30-day planning cycle was an actual advance. But as you are seeing, it has its problems. If you keep turning up the dials, as the XP folks tend to do, you get to weekly cycles. Those are about the smallest effective "sprints". I like them a lot better than monthly sprints, which are much more likely to be mini-waterfall in orientation. At a weekly cadence, you can start to see what might be beyond that. For me that generally involves a weekly meeting schedule, but otherwise a Kanban-ish flow of work with strong WIP limits and aggressive effort to keep work unit size to be well under a week. So yes, I think you're correct that continuous delivery (which was invented well later than the original Agile methods) means that sprints no longer have a release-related reason for existing, especially when you have a good feature flag practice. In practice, I think humans do need some regular rituals and that some planning work is better off batched, so I'm ok with keeping some sprint-like rituals, like a weekly planning meeting and a weekly retro. But I think high-functioning teams treat those as convenient sync points with flexible adaptation of plans as new learning happens over the course of the week. And yes, I think the Agile community broadly got stuck in a mini-waterfall space rather than what I think of as actual agility, so your read there is correct too. I think the main driver of this is managerialist ideology [1], which centers managers as the vital actors in business. In contrast, flow-based processes like you describe make managers mostly irrelevant. Unfortunately for those of us who like to actually get things done, managerialism is the dominant ideology in American business, so much so that its tenets are not only mostly unspoken, but that alternatives can be unthinkable to many. So I expect things like "scrummerfall" and SAFe to continue to dominate large-company software development for the forseeable future. [1] See https://en.wikipedia.org/wiki/Managerialism https://en.wikipedia.org/wiki/Managerialism and https://www.amazon.com/Confronting-Managerialism-Business-Economic-Controversies/dp/178032071X https://www.amazon.com/Confronting-Managerialism-Business-Ec...

Lutger 3y ago
This rings true to me. The way scrum works in practice is a, forgive my language, perverse inversion where the process has become the goal and the outcomes are less important. I worked with 4 weeks, 2 weeks and 1 weeks sprints, and with 'just kanban' as well. I now work with Shape-Up, where the build cycle is 4 to 6 weeks, but rather than having a backlog we just have a defined (and designed) problem solution and get to create user stories (or whatever) when we need it and often fill in a significant amount of detail as we start tackling the problem space. We started working in pairs, sometimes but not always pair programming, so most of the planning work is just with your buddy and fairly ad-hoc, it doesn't cost the whole team. This works pretty well. But a good team will invent an ad-hoc 'process' on the fly as is required to solve problems, without descending into chaos.
- dragonwriter 3y ago
  > But a good team will invent an ad-hoc 'process' on the fly as is required to solve problems, without descending into chaos. This is the heart of agile, but rarely gets implemented, in part because the Agile advocacy was not largely directed at the people who make the decisions that make implementation possible, but at people who lack that power.
  - wpietri 3y ago
    For sure. XP looked at first glance to be heavily prescriptive. But the initial set of practices were always meant as a starting point for a team. The notion was to give them a safe context in which to experiment and adapt. That was never really compatible with large companies, where managers need to feel in control and appear actively responsible for success. It also wasn't compatible with a top-down desire for "legibility". So in practice we end up with uniform process that's a bad fit for individual breeds

Lutger 3y ago

This rings true to me. The way scrum works in practice is a, forgive my language, perverse inversion where the process has become the goal and the outcomes are less important. I worked with 4 weeks, 2 weeks and 1 weeks sprints, and with 'just kanban' as well. I now work with Shape-Up, where the build cycle is 4 to 6 weeks, but rather than having a backlog we just have a defined (and designed) problem solution and get to create user stories (or whatever) when we need it and often fill in a significant amount of detail as we start tackling the problem space. We started working in pairs, sometimes but not always pair programming, so most of the planning work is just with your buddy and fairly ad-hoc, it doesn't cost the whole team. This works pretty well. But a good team will invent an ad-hoc 'process' on the fly as is required to solve problems, without descending into chaos.

dragonwriter 3y ago
> But a good team will invent an ad-hoc 'process' on the fly as is required to solve problems, without descending into chaos. This is the heart of agile, but rarely gets implemented, in part because the Agile advocacy was not largely directed at the people who make the decisions that make implementation possible, but at people who lack that power.
- wpietri 3y ago
  For sure. XP looked at first glance to be heavily prescriptive. But the initial set of practices were always meant as a starting point for a team. The notion was to give them a safe context in which to experiment and adapt. That was never really compatible with large companies, where managers need to feel in control and appear actively responsible for success. It also wasn't compatible with a top-down desire for "legibility". So in practice we end up with uniform process that's a bad fit for individual breeds