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


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.


Monday, May 31, 2010

Out of Iteration Software Bugs

I did a presentation last week at an Agile event and during the Q and A session one of the questions was about “out of iteration bugs”. Specifically how are they handled? Good question, not all the bugs found in a software project will come from QA activities. It is inevitable that the users are going to find something with the software that needs to be fixed and or changed. What to do?

In most cases the issue is treated like any other backlog item to be prioritized and addressed in an iteration. Depending on the severity / priority rating of the issue, the product owner can weigh the cost of fixing the bug now or having the Agile team complete a different user story. It’s just a matter of cost/benefit tradeoff of where the Agile team’s resources are spent.



Monday, May 3, 2010

To Squawk or not to Squawk

The daily standup meeting is one of the core concepts of Scrum. In the meeting the team members talk about just three things:

  • What I did yesterday
  • What am I doing today
  • What are my impediments

And that’s it…   However, the teams that I see can’t keep it that simple, there is always some banter ( a good sign of team happiness ) and extended discussion on what is going on that may derail the team or another team member.  If the discussion goes on for more than a few minutes we table the discussion for right after the standup.  While it’s important to keep the standup moving its more important not to squash communication.

Who should participate? Anyone who is involved or interested in the project.  Who should actually talk?  Only the folks directly involved in working on the backlog.  The other participants should keep their thoughts to themselves until they get a chance to talk to the Scrum Master away from the team. 

Now I’m going to break the rule, one last thing at the end of the standup I want to know if there are any announcements.  This is a time for individuals that are close to the project but not working on the Product backlog to give the team any information that is valuable for the team.  Usually I limit who can give announcements to a very few trusted individuals.

Daily Stand-ups.. keep them simple fast and open to the team.


Monday, March 1, 2010

Agile and Team Motivation - Goals

I recently started a series based on an Esther Derby Amplify discussion about how to demotivate a team. Esther mentioned in her discussion that unclear and changing goals are a big demotivator for a software development team. Besides agreeing whole heartedly my first thought when reading her discussion is how a good Agile implementation combats these demotivators. Let’s see how Agile methodologies thwart some of these potential demotivators for software development teams.

But first, a high level review of some key Scrum concepts; The Prioritized Product Backlog, the Sprint Backlog, and the Sprint Planning Session.

The Product Owner prioritizes the Product Backlog to identify the highest priority / value product features to be delivered by the Agile software development team.  By viewing the Product Road Map and the Product Backlog the Agile software development team can get a fairly clear idea about the project’s long term goals. 


Scrum and Goal Stability / Clarity

  • The Product Road map is created by the product owner to provide a long term view of the product vision.

  • The Product Backlog provides a view of the desired functionality expressed as user stories. The Product Owner prioritizes the user stories to place the highest value user stories to the top of the Product Backlog.

  • The Sprint Planning Session and the Sprint Backlog; The Scrum team conducts a Sprint Planning Session in which the Scrum team selects from the Product Backlog a set of user stories and then commits to complete the selected user stories in the next Sprint.

    • It’s important to note that once the Sprint commitment is agreed upon by the Scrum team, the contents of the Sprint cannot be changed by someone outside the Scrum team.

  • Every day the Scrum Master conducts a Standup meeting with the Agile software team to review progress against the Sprint commitment. Using burn down charts the team can see if they will complete the user stories and meet the commitment (goal) of the Agile team.

  • Once the Sprint completes, the Agile team demonstrates the completed code to the product owner to validate that the Agile software development team delivered what was expected by the Product Owner.

    In the Scrum / Agile environment, the team can see all aspects of the project, from the macro level Road Map to the micro level of the individual task. The Scrum team members set their own commitments on what they can deliver and are responsible to deliver on their commitment. It’s reassuring for the software development team to know they won’t be thrashed with constant change. It’s also very satisfying for an Agile software development team to deliver functionality on time, demonstrate it, and have the product owner validate that the developed user stories are what was expected.