Taking a Break From Sprinting

"bennyou.cpt1" has a question about taking a break from sprinting to focus on other things:

Delivering sprint in and sprint out can almost cause content fatigue. The team becomes so engaged in developing on the same project or product that they sometimes lose site of the bigger picture architecturally.

Has anyone else ever tried or considered breaking in between a long set of sprints and just regrouping with some sort of strat sprint?

[...]

The analogy I like using is that it's difficult to look at a map while you're driving. Sometimes one needs to stop, regroup, and make sure they are on the right road.

Wolfgang Wiedenroth doesn't see the need to regroup:

1. The Product Owner controls the map and corrects the path the product is heading. [...]
2. Every sprint is timeboxed so there are planned breaks for the team, where they got the opportunity to take a look at the map. First time in the Sprint Review and later on in the Sprint Planning, where they are able to adjust their course.

So there is no need for an extra break or "adjustment sprint" just as much there shouldn't be a need for "bugfix sprints" before a release.

The team should be working in a sustainable pace to have enough time to plan their path.

Dave Barrett's experience with Scrum hasn't yet shown him the need to take a break from delivery, at least with respect to burnout:

Certainly, I wondered if the constant grind of churning out feature after feature after feature without a break was going to become a burden in itself. I can say though, that after 7 years of back to back Sprints without a break burn out has never become a problem.

My guess is that the trade-offs for the Team members in moving to Scrum are almost all positive. The Team is now constantly have success, deadlines are all self-imposed and unreasonable customer/user demand can almost always be dealt with by, "We'll have to put that in the Product Backlog". So yeah, we expect them to deliver a bunch of stuff every month, and as soon as they've got that done we turn around and hand them a new batch of stuff with a new deadline but now it's all set up to succeed.

Jon Archer offers this approach with regards to stepping away from the product backlog:

We are releasing every quarter and just decided to have an "innovation" sprint in between each release. Partly to decompress, partly to let people do whatever they fancy for a bit...only caveat is they have to come back and do a little "show and tell" on what they got up to. We haven't had our first one yet, but I really like the idea and think it will be worthwhile.

Jussi Mäkelä seems to have the same idea, but at a faster tempo:

I know a company that runs three-week sprints, the last day of the sprint is always dedicated for learning, tinkering etc. It seems to work very nicely, it's a nice break from the "normal" stuff and you get to focus on things that you find interesting.

Alan Dayley lists some other ways to get perspective:

Some teams create a culture of sharing via events.

• "Tech Talks" are held at least once a sprint to describe new architecture, invite stakeholders to present or do deep design discussions. Topics for the talks are either naturally needed based on the product communication needs, are suggested by team members and management or someone volunteers do fill a needed gap of knowledge. Time box: One hour.
• Learning Lunches are held once a month. 2-3 people offer to present on anything (gardening, photography, pinball machine collecting and repair, book review, whatever). Everyone brings their lunch or chips in to have pizza delivered.
• Design and code reviews are scheduled with standing appointments, four per sprint. During Sprint Planning or in the daily meeting people step forward to have their work reviewed and a primary reviewer is set. The whole team is welcome to attend if they are interested. Time box: 1 hour. Continue the review in another session if needed. Reviews over an hour tend to loose value quickly.

All of the above events are also open to people outside the particular team that is providing the content. Cross-team attendance is very frequent.