Thursday, September 18, 2014

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





Share/Save/Bookmark

Sunday, March 23, 2014

I was recently asked 3 questions about working with remote software development teams, the questions were specifically about quality issues


1) Why customers get poor-quality software while working with remote software development teams?
Being successful with remote teams requires a level of maturity that many organizations lack. Often there are no documented standards, no processes, no vision, and so on… This leads to delays, quality issues and general frustration with the remote team. Generally the problem is not the remote team, it’s the customer.

2) According to your experience, if you could distinguish three key reasons of poor software quality, what would they be?
  • Product requirements that are unclear and/or poorly documented.
  • A weak product owner or a product owner that will not work off hours to remain in contact with the remote team.
  • Not taking into account cultural differences, both location and company cultures can have a big impact on team dynamics.
3) Could you give customers a practical piece of advice, what they should pay their attention to in order to avoid low software quality?
Always check for understanding when reviewing the product backlog. Since your product owner can’t be there with the team you have to fill the void with documentation, mockups, and conference calls. Spend the extra time to prepare these artifacts one sprint ahead of development and review them with the remote team leads. Get your stories clear ahead of the sprint and a lot of trouble goes away. Insist on frequent demonstrations and good software process. Be very sure the team is on the same page.

Share/Save/Bookmark