Agile Fatigue

In long running Agile projects there are observations that the productivity of the team(s) come down as they burnout. In the (bad) old waterfall days projects had ramp up and ramp down time which gave developers and team members some breathers but in the (good) new Agile days its sprint after sprint relentless teams hardly get time to catch a breath.

Agile Fatigue is more worse when you work with not so matured product owners, product management teams who thinks development teams as run machines and expect them to deliver sprints day in, day out without a break.

Some of the symptoms of Agile Fatigue includes user stories that drag from sprint to sprint, user stories that are too big or broken down inappropriately, lack of or improper use of epics, and QA/Test organizations falling behind because they are handed too much functionality all at once. Don’t let the team con you into waiting ‘until the next big function’ because it’s ‘too much trouble/delay/work’ to fix the problem immediately.

To help the teams overcome Agile fatigue , some of the industry practiced best practices are

  1. Ensuring the backlog is “just good enough” : Don’t waste time perfecting a list of product features or tasks that, by the nature of agile, is going to change over time. Start with an imperfect and still well defined backlog and transparent communication to keep anxiety and fatigue from building and know that the grooming and retrospectives will mature the backlog quickly and continue over time.
  2. Learning & Innovation Sprint: Make every 5th or 7th sprint lean and learn and innovate, in the sprint the team took fewer story points and committed to learning a new technology/trick , this kept the teams ticking.
  3. Plan hardening sprints : Give tech debt ownership to development teams and ensure we had planned hardening sprints where the team took care of upgrading frameworks/libraries, clearing technology backlog, refactoring quick and dirty hacks , fixing defects, fixing performance issues that piled up over a period etc.  This often gave the team a sense of technical ownership.
  4. Encourage and make Automation part of Sprints: Identify repetitive manual tasks as part of retrospectives and add stories to automate them. This keeps the Enthusiasm moving across the teams.
  5. Team Building/Reset Day – A fun day where the team creates working agreements/charters, builds trust and has fun. It is essential all teams do this as setting expectations when times are good will see you through the times when they are not.  Money in the bank so to speak.
  6. Sprint Retrospective Action items Folow UPs: Over a period, sprint teams gets bored and lose interest as they feel there are no takers to the action items discussed in the Sprint Retrospective meetings. Especially for long running sprint teams , this is more evident. Teams actually improve more often and quicker due to heightened transparency on Retro action items. Having the support from the Product Owner, Business Owners is very important, because it gives a clear sign that whatever the team agrees to improve upon is really important and should be solved!.

A more Optimistic CAN-DO Attitude without understanding the reality is more dangerous than a more practically approached attitude understanding and balancing the reality and yields more results 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s