当连续进行 Scrum 冲刺时，是否会发生倦怠？

One solution is to reduce the number of hours in the day spent on the sprint.

I know some people whose workdays consisted of a mere two and a half hour of sprint, with the remainder of the day focused on a variety of other activities: support, relieving technical debt, research, etc.. Their development velocity was set accordingly.

That may seem a bit extreme, but if I'm not mistaken it was a profitable company until the recent widespread economic shock hit.

No matter what development process you're using, if the team is getting burned out something is wrong. It may be as simple as people not taking the vacation time they need, or it could be in the details of how you handle your scrums. Teams are effective over the long-term because everyone gets the rest they need along the way.

You are in your 18th sprint!?

Considering 2 weeks per sprint, that means 36 weeks nonstop working on the same project. You also comment that work around 6 hours each day. That sounds like a lot!

I don't know that much about agile methodologies (although we're actually using Scrum in our current project), but there's a principle about your working hours (I mean, the amount of time you spend doing a task) should be 60%~70%. Now, doing numbers again, if your labor day is 8 hours long, and you spend 6 hours working, you're really spending around 75% of your labor time. This could be a little deviation that has finally make you have that feeling.

OTOH, I believe that if your project will take long time to be done, sprints should be larger, not 2 weeks, but not a month. Consider a downward curve on your burnout chart: Start your sprint with a regular task burn, and reduce your activity on the last 2 or 3 days before the sprint ends.

Agile is not a stone with the engraving:"work faster/stronger/better/harder", it's more like a blue sky with white clouds that read:"work nice, beautiful more productive". (a little lol at the end courtesy of daft punk + radiohead).

This is relatively normal and can sometimes be a complaint of our team members if projects continue for a long period of time.

The key to what we're talking about here is sustainable pace. If you and your team are able to sustain your pace over the long term, that's excellent -- you've achieve the hyperproductivity that all Scrum teams are striving for.

Alternatively, if you're finding that you overestimate how much work you can actually get done in a day, then you may need to reevaluate that during your retrospective. The amount of productive time in a day that a team chooses to recognize when doing their capacity planning for a sprint is referred to as a focus factor.

Henrik Kniberg has this to say:

The “default” focus factor I use for new teams is usually 70%, since that is where most of our other teams have ended up over time.

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

However, what it sounds like you're talking about is simply the nonstop momentum of sprint after sprint, not necessarily your productivity in a day. Here's some suggestions of things we have tried to deal with that:

• End the sprint on a Friday morning. Have your sprint review and retrospective in the morning and let the team work on something else the rest of the day to clear their heads. Pick up with Sprint planning on Monday.
• We introduced the notion of "lab days". These are entire days that the team is taken away from the project and they spend the day working on improving their own technical skills through research with each other and collaboration on specific technical topics. Most of the time they have absolutely nothing to do with the specific project and allow team members to think about lighter topics.

Sustainable pace is a key tenet of agile. When doing the management (SCRUM) practices along with the engineering (XP) practices, a team can deliver sprint after sprint indefinitely. However, because one can does not mean one should.

It sounds like you need a change against the endless string of sprints you see ahead of you. A number of options can be offered. Every X number of sprints, a team member (or pair) can rotate off of a team. During your rotation, you can support the run team, take a class, focus on a set of spikes, take vacation etc.

If the team has 5 pairs, and you rotate a person off the line, A person could take an off rotation every 10th sprint (if a single person) or every 5th iteration (if a pair). Issues of budget and return on investment for your activities will need to be addressed by your leadership and or business partner. But clearly, having some time to "sharpen the saw" would bring benefit to the team thus the project. Keeping the team fresh and focused is a very good thing. But we must remember, we are getting paid and we need to bring value for the dollars we earn.

You’re getting worn out after 36 weeks of hard work; that’s not Scrum, that’s human nature! Scrum is not there to make you work harder, it’s there to help you work more consistently and with greater predictability. I often see people confusing the symptoms of normal project management with what they perceive are symptoms of agile methodologies (i.e. “the customer keeps changing requirements – it must be Scrum’s fault!”). It’s an important distinction though because without identifying the cause you can’t treat the symptoms. Personally I’d be looking at ways to reduce burnout such as stress management techniques. There’s heaps of info out there on how to succeed in a stressful environment.

The team that I am currently working on solves this problem really nicely. After three sprints we have a week in which each developer may work on what he wants. Those side projects should be linked to business value, but there is no pressure to get it done. It is a measure to allow us developers to explore new technologies, but it also provides us with a week of more relaxed, fun work.

This for sure helps me to not get burned out.

A Sprint is not a 100 yard dash; it is one (random) mile in a marathon, i.e. a pace that you can sustain indefinitely.

Is your Team conducting retrospectives at the end of each Sprint? This is the Team's opportunity to "inspect and adapt" their process? As a ScrumMaster, I regularly ask the Team to rate how the Team as an entity 'feels', and if they're having fun. We explore why or why not, and experiment with adjustments and alternatives.

In my experience, Team members enjoy (up to a limit) the 'pressure' that the Sprint timebox constrains. The key is to approach, but not exceed, that zone. As needed, calibrating that zone is a prime checkpoint in a retrospective.

As for "... time in a Scrum environment that is unassigned/untracked to get done some minor things and to clear your head", keeping the Team commitment at x% of the available capacity (points, preferably, but hours can be used if needed; in either case I've found something in the range of 60-70% seems the norm) is key to sustainability inside of a Sprint, and an occasional 'free code day' works well for outside Sprints.

From Wikipedia on burnout: "burnout is largely an organizational issue caused by long hours, little down time, and continual peer, customer, and superior surveillance"

They might as well have an icon image of Scrum next to the definition of burnout.

If you think you can send someone onto something else for a brief diversion to fix burnout, you obviously haven't thought it through. Ever go on a vacation after being burned out and go back to work thinking, Wow! Now I'm refreshed and ready for another 6 months of this torture until I finally get a break again. Nope, what happens is you realize, Wow! My job sucks. Now I can really see how my stupid manager's micro-managing, development process is just another way of getting more out of me for less and life's too short for this... I should find something else to do or change jobs to something less stressful.

IMHO, short 2 weeks Scrum should be prohibited except in small doses, not more than 4-8 in a row. Use it as a tool for exceptional or critical things, not continually. Use common sense.

I fully understand what you are saying. For those of you that say "your pace is too fast," I'm not sure I agree that pace is always the problem when people get burned out by this process. Even though keeping track of all your progress IS a good thing, it can also be a stress factor itself (and not keeping track can be as well), not just because your boss/PM will be on you if they see something is not going according to plan, but for yourself. Just having this logged info is something that WILL make most people work just that little bit harder than you normally would ALL THE TIME and I'm not sure putting more time on your time estimates will fix this for everyone. I don't think a motivator (like your burn down chart) is always positive.

Some people won't feel this way, others will. There is not ONE way of work that WILL fit all. Never will be, in my opinion.

Also, if you say that these agile methods and sprints are not becoming more effective/productive, why are you using it at all? Why do you think companies want to use these methods at all? It's not because they are fun....

Effectiveness/productivity always comes at some type of price, in my opinion. It doesn't pop up from nowhere just by using the magic methods (if you get my point).

The only way for you to become more effective (work and pressure-wise) and do less work is make someone else do the work or by automating it.

In my opinion, one should always review ones processes and see what can be automated and spend time on automating your processes instead. Automation comes at the price of doing extra work instead of doing "the real work" but no matter how small the automated task you will always profit in the long run. ALWAYS! If not one day, in two. Not one month, two. Not one year, in two years. You get the idea.

However, I like the idea of having time off to work on personal projects. Most companies will never allow this though. But perhaps you can persuade your employer to get this time to automate your processes and this work could be "outside of sprint control" to allow the time you are talking about to "rest" and get energy back for a new sprint.

Those were just my 2 cents. I get a bit frightened when people say these methods aren't here to make us more effective and work harder. Of course they are! When you have no trace of what you are doing you will rest when your body tells you to. When "everything" you do is traced, you will push yourself. Or I correct myself, most people work this way, some will rest anyway.

I think you are missing something, but you are not the only one. As Jim Highsmith says: “Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.”

I’d guess that is what is happening to your team. I recommend reading this Highsmith’s IMHO seminal post: Velocity is Killing Agility!