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.

10 Reader Comments

At work we just throw 'em in the parking lot, and let 'em fight over it. Generally, it comes down to beating someone up until they agree to take the parts you don't want, but it pads the profit margin a bit to sell tickets.

(And yes, I'm kidding; though it would be less painful than planning meetings, I think.)

I usually have my developers choose which functionality they would like to do and if someone proposes they can do it faster i have them pair up to get an idea how that person does it, encouraging learning and such. Breaking it by functionality with emphasis on completing milestones in order so clients\q&a to create unit testing as time goes on.

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.

There isn't a single best answer - part of being a good manager is knowing your team. Sometimes you have redhot superstars who will always get you solid code on time with elegant solutions, and you should just leave them alone, so long as they are playing nicely with others. Everyone else, make sure they have reasonable amounts of work for each person (if you have some velocity on them from past projects, so much the better) and let them get on with it.

Keep your tracking by functionality, and be brutally binary about it (if it's not D.O.N.E it's not done) and you will keep your schedule under control.

Without wanting to start a religous war, I am a huge believer in constant integration and a constantly functioning build. Nothing shows you where you actually are like making people make the code they have written up to now actually compile and integrate. There are going to be a few "two week megasystems" but they should be few and far between and easy for you as a manager to keep a keen (yet companionly) eye on!

If you have crummy developers in your team you're dead no matter how excellent your processes are. You will spend more time fixing the problems they create than making meaningful progress.

If the project manager has an inflated ego you're dead for he/she will suck credit and belittle other people's accomplishments. In a few weeks, the good developers will quit and the project will be left with the crummy ones (see above point).

If you have two prima donas in the same team you're dead as they will fight each other and will create gridlock. If you don't have any, you're dead too as no one will set any kind of direction. Managers who try to instill the "family atmosphere" in a company are either idiots or think everybody else is. You can't have a good developer unless he/she has a huge ego. I believe the same can be said of any professional. Ego is what makes people want to be at the top 1%.Whatever you do, you need people in the top 1%. If you don't have these people, be assured your competitors have them.

My advice is to be really smart at stimulating people's egos in as much a constructive way as possible, knowing that battles for prominence are inevitable. You wil have to let go of really good people unfortunately but that's how this game is played. If you do this right, everything will fall eventually into place and your competitors will eat the dust you leave behind. Also be ready to get fired if you aren't as smart and hard working as your people are.

In the first or second sentence of the original question he says they intend to use Agile (I assume that means either Scrum or XP since those two constitute about 85% of the implementations). Either way, the answer is in the process itself, and the fact that the question was asked at all tells me that the questioner has not received any training in the process.

If you know the specific Agile meaning of "cross functional teams", "self organizing teams" and "collective code ownership", then you would already know the answer to the question.

My advice: get some professional training!

Also, many (most?) of the answers given above are incorrect. I'll give the responders the benefit of the doubt and assume that they missed the part where the team would be using Agile, and just gave a general response.

Have to agree with @curthibbs here, the answers are in the process you choose but they may be hard to see for people new to agile. Assigning tasks to the team is definitely not agile.

I'd develop a product backlog of features, prioritize them by business values, and let the team figure out how to implement them. The features need to be end user features, not things like "develop DAL". Don't prioritize by technical dependencies, e.g. don't say developing the DAL is the highest priority because we need it for the other stories. These feature might cross modules.

The developers work in a timebox (two weeks is the norm), pick the highest priority product backlog items they believe they can deliver, plan how to implement them and start working. At the end of the timebox they demo what they have completed and verify it meets the acceptance criteria and the teams definition of done.

I'd recommend trying to work on a single feature at a time. This often requires stubbing in bits to allow other people to continue working while bits are implemented, e.g. I'm just going to stub this bit to return a hard coded list while we work on the db layer that way the UI bits can go forward. If there isn't enough work on that feature, the free developers move on to the next highest priority.

Depending on how many developers there are, team size may be an issue. Scrum generally recommends a team size of 7 - 9, but I've found the sweet spot for us seems to be 4 - 6. There may be an opportunity to have multiple teams working on features. If so, you'll need to coordinate them, Scrum uses a Scrum of Scrums for this.

Finally. gotta agree with @curthibbs here, if you can do it, get some training. Either way the scrumdevelopment, and xp groups on Yahoo would be a good place to ask questions.

My IT leadership has no idea what skills we have as a team. There are those of us with less than 10 years experience and those with more 10. We get divided along those lines. New ideas are unwelcome and met with open hostility from the old-heads. When the shit hits the fan and us younglings are scrambling to fix our latest debacle, they either force us to work overtime or bring in outside help.

ANECDOTE WARNING: I interviewed for a team lead spot last year. My manager looked at my resume and gasped in surprised. He had no idea what I specialized in or what I was certified in. I had a great interview explaining how I could use my skills to promote efficiency. He promoted the guy who'd been on the team the longest and assigned me to be his secondary. Is it still considered anecdotal if it happens every single time?

Maybe I wasn't the best fit. Maybe I'm not as good as I think I am. But every time our NETADMIN brings down the entire network, I wonder if it would have happened under my leadership. They certainly don't mind calling me in when they need help.

1) Keep teams small and manageable. I prefer a team (including the lead) of 4-5.2) Let developers pick the tasks, and if you're comfortable with their design skills, let them design portions. Make sure you stay on top of the overall design and architecture though.3) Let them work how they want to work. If they work better with music blaring and no one bothering them, try and give them space to work. If they prefer to pair program, or work next to a coworker they can chat with, let them. If they feel comfortable they'll be more productive.4) As for how to break down who works on what part of a project, I usually put them in separate module buckets about 80% but make sure everyone gets an overlapping task that takes them into another module, ideally without interfering with whoever is "80%" in that module at the time. This can be tricky to plan, but once you get used to it you find opportunities to make it work more easily. This provides an expert on each module while keeping everyone familiar with more than one module.5) Lastly, as the lead, fix bugs regularly. I find the hardest thing to do as a lead is have time to get real coding done. I get interrupted a lot, have meetings that split my time up, and generally find it difficult to get a solid, uninterrupted chunk of time to code. But, by fixing small bugs that I see come up, it gets me into most of the code base so I can maintain knowledge of the entire thing.