I'm working in a team where each member is working on an user story. How can we avoid creating duplicate or conflicting functionality?
For example, if my user story requires the creation of class A and my team member needs the same functionality and creates a similar class (maybe with a slightly different name), how should we plan our work so that we both move smoothly?
Communications.
Large part of working as agile team is knowing what your team is working on. You have planning meetings and you should have design discussions prior to going off and coding solo.
On our teams we always know what other developers are working on and as soon as the thought arises that there's a potential for reuse or for overstepping bounds, you get up and walk over to the other person's desk (or if remote, pick up the phone).
UPDATE (response to comment):
At the beginning of every sprint, the team decides which stories are to deliver and which tasks are to be completed. We have a standard template (kinda like a checklist to make sure nothing is forgotten) and one of the things, is design task.
Almost every story has a design task, but generally it is 10 min to 1 hour discussion among team members to discuss the general approach of completing the work ahead. This not only serves as a heads-up for other people, but it is also useful because sometimes other people will offer a different solution that is better than what you were considering doing. In planning meeting, we decide which developers should participate in the discussion based on a) complexity and b) other people's familiarity of existing code that's involved.
If two people know they will be working in similar area, they will most likely participate in the same discussion. Our agile teams also have a technical lead, who typically participates in larger portion of design/code reviews and one of the responsibilities of that person is to spread knowledge through out the team, but I have a feeling this is a temporary position we will get rid off (or maybe scale back) once other team members get more familiar with the product (currently lots of fresh members).
Also during daily stand ups we generally talk about what we've been working on and what's ahead and if I mention that i started writing a utility class to help with feature X, and that class is useful to another developer, then the other developer would talk to me after the meeting and we would discuss how to make sure we are not repeating work and the class is generic enough to satisfy everyone's needs.
Finally, all code written is code reviewed, and we rotate through who reviews what, so in general the team has good familiarity with the whole code base. Even if two duplicate classes slip through (and I can't think of that ever actually happening), 95% chance this would be brought up in a code review and the two classes would be merged into one at that point.
