It feels like déjà vu all over again.  A team of experienced developers is having trouble meeting its deliverables.  It feels just like the last team that struggled with the same problem.  Even when you’ve instituted Scrum, you’ll have to pay attention to these issues every day.  Here’s a list of common mistakes and how to address them.

POOR COMMUNICATIONS

Whatever the size of the team, communications is always a problem.  This is part of the human condition. Typically, when a team gets in trouble you’ll find that the individuals on the team don’t really know what the other team members are working on.  The results range from doing duplicate work to having people go on vacation unbeknownst to anybody else in the team.

I almost cry because the solution is so simple:  daily, stand up meetings.  Take 15 minutes every day to sync up and most of these problems disappear.  Just ask four questions:

• What did you do yesterday?

• Did you run into any obstacles?

• What are you planning to do today?

• Is there anything that may prevent you from accomplishing your goal?

BUG CREEP

Developers tend to minimize the impact of the defects they’ll generate.  I’ve heard the same rationalizations over and again, “they are not critical,” “we can fix them later in a single day,” “better to keeping working on new features now to show progress.”  Unfortunately, bug creep will kill a project or, worse, keep it at the “90% done” state for the rest of the life. The solution is zero bug tolerance.  Quality must be the top priority for the team.  Make QA and users work hard at finding a bug.  In fact, that event should be rare, not a given.  When bugs show up, new code development must be stopped and continued only after fixing the bug.

WHAT DO YOU MEAN BY "DONE"?

Ask each team member what “done” means for them. You’ll be surprised how many different defintions of “done” you’ll get.
The solution is to come to a common definition of what it means to be “done” among the team.  The definition must include that the code be unit tested, code reviewed, bug free and nothing but ready for release.

QA IS NOT PART OF THE TEAM

QA input in a project is critical.  Some developers tend to exclude QA, not including them in planning sessions, stand up meeting or design meetings. QA, and particularly manual testers are viewed as not being part of the development team.
The solution: Locate testers near to developers, if that’s not possible at least pair test with developers, ask developers to look at the test cases testers have written, invite testers to meetings, testers must be perceived as useful by testing and providing early feedback so they become a necessity to the team.

WRITE CODE WITHOUT STORIES

The reason that developers are developers is because they love writing code (and I know whereof I speak).  That’s great, but it also means that sometimes they’ll write code even though the requirements are not clear, even without User Stories.  Unfortunately, in those cases there’s a better that 50-50 chance that the result will not meet whatever requirement the Product Owner was thinking of.
The solution is to make sure that requirements are clear at the during Sprint planning.  Ensure that everybody understands them.  Make sure no question is left unanswered.  Once coding starts, revisit the Stories on every daily meeting.  Ask each developer how confident they are that they understand the results they need to create thoroughly.  Put the infrastructure in place to support continuous integration.  Even if somebody misinterprets the requirements, at worst you’ll waste only one day.  Make sure you’re getting continuous feed back from QA as well.