Does anyone else get worn out using Scrum, finishing sprint after sprint?

Question

I'm with a pretty small startup and we started using a form of a Scrum/Agile development cycle.

In many ways I enjoy Scrum. We have relatively short sprints (2 weeks) and I like the Burndown Chart to track the teams progress. I also like the Feature Board so I always know what I should be doing next. It feels good taking down a feature's card from the board, completing it and then putting it in the burn down pile.

However, we are now entering in our 18th Sprint release cycle and I'm starting to feel a little burnt out. It isn't that I don't like job or my co-workers, it is just that these sprints are... well, sprints. From start to finish I literally feel like I'm racing against the clock to maintain our development velocity. When we are done with the sprint we spend one day planning the next sprints feature set and estimates and then off we go again.

For people who work in a mature Agile/Scrum development process, is this normal? Or are we missing something? Is there normally time in a Scrum enviornment that is unassigned/untracked to get done some minor things and to clear your head?

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

I fully understand what you are saying and for those of you saying "you are having too hard a pace", I 'm not sure I agree that is always the case when people get burned by this process. Even though keeping track of all your progress IS a good thing, it can itself also be a stress factor (and not keeping track can be it aswell), not that 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 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 (which your burn down chart is) 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 IMO.

Also, if you say that the idea of these types of agile methods and sprints is not becoming more effective/productive, why should you even use it at all? Why do you think companies want to use these methods at all? It's not because it is fun...

Effectivity/productivity always comes at some type of price, IMO. 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.

IMO 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. Ofcourse 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.