At the last few companies I worked for, my organizations happened to follow a similar agile methodology. It worked really well for us, but I don’t have a name for it. Maybe you can help name it. For now, I call it “Beyond Scrum.”
I’ve followed the Scrum methodology on a handful of teams in the past, including all of the ceremonies (colloquially – daily standup, sprints, sprint planning, demo, retro). I was even a certified scrum master.
But over time, some of the ceremonies seemed more useful than others. For one, sprints (a.k.a. iterations) especially created friction without providing any benefit. At the end of a sprint, there would almost always be stories that either had to be split, taking partial “credit” in the current sprint and the rest in later sprints, or pushed wholesale into the next sprint without getting any recognition for any of the work in the current sprint. We could get better at fitting stories into one iteration, but you know what makes more sense? Don’t arbitrarily chop our work up into sprints and then fret about whether the last few stories fit into the time at the end of the sprint.
My recent teams evolved into more of a Kanban sort of flow, where we would finish a story then pull the next story off of the backlog. There was no sprint backlog, just the overall project backlog. I don’t really know how much of Kanban we followed, because I don’t know much about Kanban. But I do like the continuous flow of starting a new story as soon as people were available to take on something new. Caveat: one team used a project management tool to groom at least a week’s worth of work at a time, which looked on the surface like a 1-week sprint, but the reality was that they always wanted at least a little more than a week of stories so they wouldn’t run out and have to groom more stories mid-week. Any stories that weren’t finished at the end of the week would flow smoothly into the next week with no anxiety about what sprint it was a part of.
Speaking of stories, story sizing seemed to lose its value. With no sprints, we didn’t need to calculate velocity in order to know how many stories we could cram into a sprint. Discussing size may have had value in terms of making sure the team understood the scope of a story, but ultimately the teams didn’t care what T-shirt size or Fibonacci number was put on each story. What did still matter, though, was writing good stories that had clear acceptance criteria and weren’t too large. Large stories that couldn’t be finished in a week were difficult to manage. But writing small stories was often difficult to do. Sometimes we’d split a story after seeing that it was taking a long time, or we’d just march on for two or three weeks and get it done.
My last few teams were working on infrastructure software–someone that a product owner might have difficulty relating to customer-visible features. So we found that the product owner role wasn’t very active or useful. Typically we would have a manager or designated person on the team take care of accepting stories, which was often rather informal. Often we wouldn’t even have clearly written acceptance criteria, and often the acceptance process was a rubber stamp that didn’t provide any value to the team. On a related vein – the sprint demo didn’t make much sense. We might demo individual stories as needed to facilitate story acceptance, but with the diminished participation of the product owner, we often skipped the demos. In their place, we might demo significant new features or newly introduced technologies to our team as needed. One team had a weekly time slot for this and other technical discussions.
Besides Kanban, another methodology we borrowed from was Extreme Programming (XP). We didn’t strive to follow all of the essential XP elements, so it would be disingenuous to say we were an XP team. But we did follow the most commonly known XP practices, test-driven development and pair programming. Another element of XP is the 40-hour workweek, and we did pretty well at that one too. Many of the other elements were there, like collective code ownership and continuous integration. But not the iterations and not much of the iteration planning.
We kept some of the other Scrum ceremonies. The daily standup was still useful, especially with a remote team. There were experiments with going more lightweight with an asynchronous standup in a chat tool, and in the other direction with adding a daily stand-down. And the retro was still popular, at least once every two weeks but more likely once every week. It wasn’t hard to find recent things to celebrate or improve on.
So there you have it – the elements of “Beyond Scrum” that were remarkably similar at two different companies. Maybe many companies have evolved toward something similar? Let me know if any of this sounds familiar to you.
feature image photo credit: Tom Natt (CC BY-NC 2.0)
swalchemist 
I like your overarching theme, that terminology can interfere with methodology instead of helping. It sounds like you have worked with healthy teams that don’t get bogged down in fixed processes, and had the “adapt-fast-to-new-facts” kind of atmosphere, and “take-what-you-need-and-discard-the-rest” approach. This sounds like what you are describing as “Beyond Scrum”: Don’t be boxed in by strict method definitions. I wrote something similar about Agile methodology in general, but I think it is à propos of your post—“Frankenstein and the Agile Casserole” (https://www.bobzeen.com/blog/agile/). I think a similar concept is well argued in the “Context-Driven Approach” advocated by Kaner/Bach/Pettichord in their book “Lessons Learned in Software Testing” (https://www.amazon.com/dp/0471081124). I read it back in the SQE days, 2001/2002, but if I remember right, it was an early example making the case for “Beyond Scrum.” Not to drift too far away from time-tested and well-defined processes—knowledge of them makes deviating from them more effective as we customize methods to current needs.
Thanks Danny for another thoughtful blog post!
Thanks for your thoughts, Robert. Regarding the agile casserole – yeah, we put no thought into convincing anyone that we were Agile or even agile. We just wanted to follow an effective process to do our job.
I can include the Beyond Scrum approach in the broader category of “pragmatism.” Which reminds me, I have the 2nd edition of The Pragmatic Programmer sitting here that need to read.
Thanks to Patrick Baumgartner for pointing out Urs Enzler’s Caretaker Model. It shares several things in common with the approach I wrote about here.