I Don’t Do Sprints
Author: Jurgen Appelo
Scrum, Design Sprints, and other methods show pictures of neat step-by-step process cycles. Some frameworks even suggest a cadence that wraps all processes in a fixed timebox. But personally, I have lost my love for sprints. I don't have one cadence. I have many.
I don't have one cadence. I have many.
Last month, at the ALE unconference, I spent several days observing agile coaches and consultants, watching what they talk about, what their biggest problems are, and what kinds of solutions they prefer. My next opportunity will be the next event where coaches and consultants gather. (Empathize, Synthesize)
My observations are input for my idea generation, which I do almost daily. I use a simple task list as a categorized backlog and add new things to it whenever inspiration hits me. My daily runs and walks are an excellent opportunity for that. (Hypothesize)
I build and release things (mainly blog posts and workshop modules) almost daily, except for my newsletters, which go out approximately once per week. And I happen to iterate on my presentations with precisely the same frequency at which I'm giving them. What a coincidence! (Externalize)
Every two or three weeks, depending on my calendar, I have an exclusive meetup with a stakeholder to check how they like my work and to better understand their concerns. (Sensitize)
Finally, I plan my work every week (often on Mondays) and reflect whenever the mood hits me (usually when I'm traveling). (Systematize, Contextualize)
As you can see, I touch upon all seven streams of the innovation vortex, but I do not have one regular cadence. I have multiple! I do some things each day, some once per week, and a few things every few weeks. Some processes get triggered by external factors or whenever I get the chance to do the work.
It makes no sense to trigger all my processes with the same cadence.
I am not a big supporter of sprints. It makes no sense to trigger all my processes with the same cadence. Some processes are best triggered every Tuesday and Thursday; some should be activated at least once per month, but the exact day doesn't matter, and some can only be triggered whenever the client has an hour to spare in their busy schedule.
I adapt my processes to the dynamics of my work-life, not the other way around.
Innovation is messy and unpredictable. With product design and development, we usually deal with wicked problems, which means our method needs to be equally chaotic and unpredictable. Yes, it would be best if you touched upon each of the seven streams of the innovation vortex as often as necessary. But don't be fooled by neat step-by-step process cycles. These apply only to narrow domains where entire teams can focus on one steady value stream for a long time, in other words, very few people. For most of us, force-fitting our dynamic work lives into one simple regular cadence usually doesn't work. And besides, you cannot attack a wicked problem with a simplistic flow chart anyway.
Life is messy. Embrace it.
