My team and I are rebuilding a site we developed around ten years ago, and we want to do it in Agile. After I've spent a lot of time reading (probably not enough), I am having trouble with the question of how to divide work between developers.

I'll be more specific and say that the site is divided into separate modules which don't have much integration between them. What is the best/most accepted way to divide the work between the developers?

I'm considering a few options:

- Giving each person a different module to work on.

- Assign all developers to the same module, and split the work by different parts of the module (UnitTesting, DAL and Mapping, Logics, UI)

- Assign all developers to the same module, and split the work by different logics (For example, each developer is in charge of a specific logic (probably a method in the BL) and its UnitTesting, DAL and Mapping and UI...

Or maybe something entirely different...

Answer: The Long Answer (14 Votes)

My team has been trying to go "Agile" for a few releases now, but being part of a large corporation hasn't exactly made it easy. I won't pretend like I have the answer, but I can share some of my observations.

Re: Dividing developers per module

- You need to be careful. When people work too much in isolation, your team doesn't benefit from cross-sharing of skills and knowledge.

- Planning meetings and daily stand ups can become incredibly dull to everyone if people focus too much on their own modules and don't see the bigger picture. Once people get bored, they start checking out and you lose much of the benefit Agile brings to the table.

- You might end up with some components written really well, and other components written not so well. If people work in isolation, your senior guys won't be able to train the junior ones.

Re: Everyone works on the same module at the same time

- We tried that for one release, when management decided they would impose Agile on the whole team. It was an absolute train wreck. We had a team of 9 developers deliver in a year what typically would've been done by 1 developer. (I might be exaggerating here, but not by much).

- No one felt like there was any breathing room. Those that didn't care about software felt right at home because being part of a larger pack, they just get diluted in the group. Those of us who had passion for software felt absolutely stifled as there was no freedom to move or go outside the boundaries that 9 people had agreed upon.

- All meetings went on forever to the point where I wanted to shoot myself. Too many people with an opinion in the same room forced to work on the same freakin' DLL. The horror.

In the last release, we've decided to try something different...

- First and foremost, break development groups into smaller teams of 3-4 developers. Each team worked in relative isolation from each other, but within the team, people worked much more cohesively.

- Everyone feels engaged because each team only discusses what the developers on that team care about.

- Tech lead from each team talks to other tech leads periodically to make sure the overall project is on track.

- Instead of making people "owner" of a specific module, we assigned areas of expertise to people, so when we first started the project it felt like people had their own module. But after several months, as areas started overlapping, developers would start looking at each other's code.

- Code reviews are essential. (When to do code review?) This was the second release where we had a strict code review policy, and everyone on the team loved them. An expert of a specific area is always on a code review when someone else modifies that code.

- With code reviews, we had a ton of knowledge sharing and you could visibly see the overall improvement of our teams' code quality. Also, because code gets reviewed so often, when people go into someone else's area of expertise, chances are they've already seen the code at least a few times already.

- A larger portion of each team is sucked into design review meetings, so even if they've never seen the code, everyone is familiar with the general flow of all modules that their team is responsible for.

We've done this for about 10 months and it kind of feels like we started with an isolated module approach and morphed into everyone working on everything. But at the same time, no one feels like they are cramped or limited. And to make sure the guys still have a sense of some authority, we left them as area experts, even though that's mostly a formality now.

Although there's a ton of room for improvements, our entire team has been very happy overall, and that says a lot (we are part of a giant corporation, after all).

One important thing that we got wrong the first 3 times we "went Agile," is that each time people were told how to work, and they were told what to work on. That's the number one way to have your team completely lose interest in the project, and then you are in real trouble.

Instead, try the opposite. Tell the team they can do whatever they want and then as a manager/leader your job is to make sure they are as productive and happy as possible (that's if you are one. If not, make your manager repeat these words). Process is not a bad thing, but process should be there to help your team when it realizes it needs one, not the other way around.

If some of your team members prefer to work in isolation, let them (to a degree). If they prefer to work in pairs, let them do that. Make sure to let your people pick their own work as much as you can.

Lastly, and this is very important and always overlooked: YOU WILL NOT GET THIS RIGHT (unless you are superman, or at least Batman). Having regular retrospective meetings is extremely important.

When we rolled out retrospectives, they were done by the book and it felt like yet another process you had to sit through. That's not what retrospective is for. It is for listening to your team, identifying areas that cause the most pain, and fixing them so that everyone can move on with their work. Apparently software engineers in general like delivering products and features, and the most important message a retrospective meeting needs to communicate is that it is solely for their benefit. You want to identify and tackle obstacles, starting with the biggest ones (or the easiest ones, there's some kind of 2D map involved) and get them out of the way so your people get their work done.

Answer: The Short Answer (9 Votes)

Answer: Don't think in Modules (6 Votes)

Don't think in modules. Think in functionality elements. Describe those functionality elements by user stories (or another way) and don't forget to describe acceptance criteria (probably defined by your current application and changes the business expects). Put your functional elements into backlog. Then let business prioritize which functionality must be delivered first (you will work incrementally and iteratively, and priority will tell you what must be implemented first).

Once you have this—at least for part of your original application—you are ready for development. What happens next depends on your selected Agile methodology. The important part is that each functionality can be divided into multiple tasks, and team members will select what tasks they want to work on—that is called self organization.

When you are starting with Agile, self organization may not occur completely on its own—someone might need to help ensure unpopular and popular tasks are equally shared by the team.

Thinking in modules from the start isn't always a good way to do things. You are rewriting the application for some reason and maybe the current application architecture based on incorrect module separation is one of the hidden reasons behind visible problems. Also, you can find that some functionality from existing modules will be completely redefined and moved elsewhere.

Answer: Choose & Assign (2 Votes)

Depending on the number of developers and modules (and timescales) I generally get my developers to pick one interesting module (to them) and one challenging module (preferably something they haven't done) and then the remainder I divide out by skill level and time constraints. I find this gives my developers something they want to work on and something to push them.