I don't like sprints.

I don't like sprints.

Design Thinking, Lean Startup, Scrum, 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.

Last week, at the ALE 2022 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 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 my clients to check how they like my work and to better understand their concerns. I also have a private call with each partner, which depends on?their?availability.?(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.

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.

p.s. The visuals of the innovation vortex are available for all?free?members of the?unFIX community.

No alt text provided for this image
Alice Jakins

Helping businesses run better, with improved processes, practices and platform wins.

2 年

This opens up so many exploratory topics. A big one for me is around purpose. If one teams purpose for sprints is for sprints to serve as mini goals in reaching the bigger goal and deciding what needs to working for that mini goal to be real, practical and valuable then I think sprints are great. The processes and practices and platforms to support delivery of the mini goal can be a collaborative and creative for sure.

回复
Lorant Dankahazi

Agile and DevOps coach

2 年

I can respect and accept your opinion and preference. We just discuss this topic on Tuesday in a meetup. I would say there are many rituals and regular activities during a sprint which are not natural, evident or easy for everyone. After a certain maturity and team cohesion working in a flow can be the next level. Mastering that is also a nice challenge. I dont think we should work as the identified streams stimulate the individuals. I believe in teamwork!

回复

This touched me, as I've felt the same for some time. I have sometimes compared the problems of Sprints or any fixed planning timeboxes to the well known problems of fiscal year budgeting. A rigid, inflexible timebox which has little to do with how the real world works. If you finish what you planned to do in a sprint 80% and can demo working software next Tuesday, it's not a failure. Who cares? It's still working software. If you find out end of October that if you invested a 100k now and would get a 200k return, but only have 50k left in the budget, who cares? Don't hold it off until January, spend the money now if you have it, it only makes logical sense.

Michael Dougherty

Author of "Shift: From Product To People" | Driving Agile Transformations & Sustainable Change at Scale

2 年

Yes, maximizing the flow of work through an empathy-led approach will yield better results than forcing sprints on teams!

Cliff Berg

Co-Founder and Managing Partner, Agile 2 Academy; Executive level Agile and DevOps advisor and consultant; Lead author of Agile 2: The Next Iteration of Agile

2 年

I agree completely. In fact, I would say that for most things at a team level, one should be event-based, not calendar-based (and timed iterations are calendar-based). But to be event-based, leaders need to be paying close attention - not managing by a clipboard. They need to know what is being worked on at all time, where the issues are, and what progress is happening. They need to be doing continuous Gemba; and being inquisitive, and stimulating discussion about issues.

要查看或添加评论,请登录

Jurgen Appelo的更多文章

  • Ten Times the Impact with One-Tenth the People

    Ten Times the Impact with One-Tenth the People

    Is the speed of learning and innovation more important than ever? Jeff Sutherland, co-creator of Scrum, claims, "The…

    7 条评论
  • The AI Code Tsunami

    The AI Code Tsunami

    ?? I am rebranding my newsletters. From this day, I continue writing as the Maverick Mapmaker.

    13 条评论
  • Just Because You Can, Doesn’t Mean You Should

    Just Because You Can, Doesn’t Mean You Should

    Sometimes, the Best Experience Is Getting What Everyone Else Has Remember that time you bumped into someone and…

    9 条评论
  • Hardcover Woes - Mea Culpa!

    Hardcover Woes - Mea Culpa!

    One of the perks of self-publishing is that you get to be both the problem and the solution. So, imagine my surprise…

    10 条评论
  • AI Should Go Fast So We Can Go Slow

    AI Should Go Fast So We Can Go Slow

    Hey, buddy. Well, well, if it isn’t my favorite rule-breaking synthesist.

    5 条评论
  • Humans Are the Bottleneck

    Humans Are the Bottleneck

    Why I Fired My Beta Readers I Don't Use Beta Readers Anymore Beta readers are a disaster. You announce a new book, and…

    16 条评论
  • The Four Moats Theory?

    The Four Moats Theory?

    Who needs Deloitte, McKinsey, and Accenture, when you have Zed (ChatGPT), Claude, and Vera (Gemini)? In the following…

    7 条评论
  • AGI—Complex, Not Complicated

    AGI—Complex, Not Complicated

    Every year on King’s Day in the Netherlands, the streets transform into one giant flea market. Citizens of all ages…

    4 条评论
  • Why 2025 Will Both Suck and Be Fantastic - The Stockdale Paradox

    Why 2025 Will Both Suck and Be Fantastic - The Stockdale Paradox

    My prediction for 2025 is that each day will find some creative way to suck, but overall, the year will be fantastic. I…

    10 条评论
  • Agile Is Undead … A Synthesis

    Agile Is Undead … A Synthesis

    "Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket." - Eric Hoffer…

    100 条评论

社区洞察

其他会员也浏览了