Agile Fatigue

Agile is an excellent development methodology, responsive to business changes with quick turnaround and highly visible results. The concept is in widespread use, particularly in software development, but having implemented Agile almost from the inception of eXtreme Programming I've seen issues arise related to people being on Agile teams for extended periods of time. These can be mitigated or even avoided entirely if you know what to look for. I call the problem 'Agile fatigue'.
Burnout is the most prevalent symptom of Agile fatigue. The pace of an Agile project is unrelenting. Unlike Waterfall and associated development methodologies there are very few built-in times for team members to catch their collective breath and celebrate milestones. To help combat burnout, try a few of these techniques:

• Set your own team goals, publicize them, and celebrate when you achieve them
• Move people among teams whenever possible to change the scenery, so to speak
• Report and celebrate small victories (see Tanya's excellent tips on ways to do this)
• Set a periodic 'down' iteration/sprint where everyone can work on something they'd like to do (or rotate that ability amongst the team members). You'll get some interesting research, something to look forward to for the team members, and a break while still working.

Meandering happens when people start on tasks/user stories but don't finish them. They might even agree to the goals for the day and end up working on some interesting bug that was far down the priority list. Sometimes this is related to burnout, sometimes you see it when the project manager or ScrumMaster is away for a while, sometimes people just are bored and distracted. The best solution is to have a hard and fast rule about taking on more than a certain number of user stories (usually 1, not more than 2) unless one of the assigned stories has been officially been blocked. To enforce the rule, the project manager/ScrumMaster will have to unassign the offending user stories (past the limit) as soon as they're picked up to get people back on track.

Stagnation materializes when people get so caught up in the short burst nature of the sprint user stories that they don't improve their skills or acquire new ones (hard skills and/or soft skills). Watch for stagnation carefully, since it can be a little hard to spot. Periodically assign user stories that stretch a team member's skills, even if there's someone else on the team who already has the skills. Create some 'administrative' user stories to send people off to pick up a new skill that *might* be needed in upcoming user stories (people like to use their new skills and your project might get a nice shot in the arm). Finally, periodically ask in wrap-up meetings or daily meetings what new technologies, techniques, or processes the team members think might have a place in the project or be worth a try/evaluation.

The daily stand-up turns into a grind. This may take a little more work on the part of the project manager/ScrumMaster. First, be sure you're keeping the meeting to the shortest time possible - it's 'stand-up' for a reason. If it's over 15 minutes something is wrong. The agenda is quite fixed - what did you finish, what do you plan, what are your blockers, so don't veer off the agenda (set separate meetings if needed so it doesn't get confusing). If two people need to discuss a strategy or a blocker, send them off to do it after the meeting (don't use the whole team's time). If someone runs too long every day talk to them in private and get them to make their part shorter. You may want to schedule something just a little longer once a week if you have a team that wants to deal with process issues, etc., more often than once an iteration, but get the stand-up part of the meeting done first to avoid any confusion about the format. Most importantly, make the meeting fun whenever you can. Bring something to eat, start with a joke, look again at Tanya's post about small victories.

Finally, you might encounter a secret move back to waterfall. When this happens, everyone keeps working within the general agile structure and the team often doesn't realize what's going on. Symptoms include 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. The whole team - and the whole project - will continue to suffer until the issue is fixed. You may have to deal with denial (after all, the team isn't moving this direction with intent, they're moving back to a methodology that's comfortable to them) and you'll certainly have to put up with a bit of whining, but steady the course and it will work out. (And be sure to celebrate when things are back on track!)

Want more? Check out the Project Management blog on IvyBay

Agile Fatigue