What is the best way to divide work among developers

Question

My team and I are rebuilding a site we developed around ten years ago, and we want to do it in Agile.

So after I spent a lot of time reading (probably not enough) I am having trouble with the question how to divide work between developers.

I'll be more specific and say that the site is divided to separate modules that doesn't have much integration between one another.

What is the best / Most accepted way to divide the work between the developers?

• 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 It's UnitTesting, DAL and Mapping and UI...

Or maybe something entirely different?

Answer 1

My team has been trying to go "agile" for 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.

• Dividing developers per module:

  • You need to be careful because if 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 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, well... not so much. If people work in isolation, your senior guys won't be able to train the junior ones.

• Everyone works on the same module at the same time

  • We tried that for one release, when management decided they will impose agile on the whole team and it will be completely their way. It as 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 bounds what 9 people have agreed on.
  • All meetings went forever to a point of me wanting 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 group 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
  • With this approach, stand ups are fast and planning meetings take 1-2 hours compared to solid 4 hours.
  • 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 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 have their own module, but after several months, developers would start looking at each others code as areas started overlapping.
  • Code reviews are essential. This was the second release where we had strict code review policy and everyone on the team loves them. Expert of a specific area is always on a code review when someone else modifies that code.
  • With code reviews we have a ton of knowledge sharing and you can visible 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 few times already.
  • Larger portion of each team is sucked into design review meetings, so even if they've never seen the code, everyone is familiar with 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 isolated module approach and morphed into everyone works on everything. But at the same time, no one feels like they are cramped or limited. And to make sure the guys still have sense of some authority, we left them as area experts, even though that's mostly a formality now.

We've been doing that last thing, and although there's a ton of room for improvements, overall our entire team has been very happy and that says a lot, when we are part of giant corporation.

One important thing that we got wrong the first 3 times we "went agile", is each one of those times people were told how to work and they were told what to work on. That's 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 as a manager/leader (if you are one, if not make your manager repeat these words), your job is to make sure they are as productive and happy as possible. 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 is 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 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 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 2

Have a meeting with the team, show them the to-do list, and ask who wants to do what.

Answer 3

Don't think in modules. Think in functionality elements. Describe those functionality elements by user stories (or other way) and don't forget to describe acceptance criteria (probably defined by your current application and changes the business expect). 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 usually divided into multiple tasks and team members will select what tasks they want to do - that is called self organization. When you are starting with agile, self organization may need some help where somebody will make sure that unpopular and popular tasks are equally shared by the team. Once the team is more mature, developers will not hesitate to speak their disagreement with the current self organization and this will be handled automatically inside the team.

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

Answer 4

Although I do agree with David's answer, I felt it could profit from some elaborating:

• Agile means, you do not make these decisions and push them onto the team. There is no project manager/leader like that. Only the team.
• The ones who know best, how to divide work are the team members themselves.
• Discuss your backlog, and find out what you want to realize in the next iteration/sprint.
• Use planning poker or similar methods to get an idea of how much work you are going to divide anyways, and only then start dividing up actual work packages together.

Basically, the bottom line is: No one here on SE can answer that question for you, nor is there much of a point to it, because it's much better if you come up with an answer as a team.

Answer 5

The simplest approach is often the best.

I would avoid dividing tasks into groups such as testing/log/UI/etc unless you can define some very good and clear reasons for doing so. My reasoning is that when you allow programmers to work outside of their usual areas of expertise, it can keep things more interesting and challenging for them, and allow them to develop and grow within their field. If you do feel that time constraints require you to divide work based on expertise, at the very minimum ensure that each developer is still required to do their own unit testing, and use code review and acceptance testing to pick up problems. Writing your own tests is very agile, and waiting for testers time to become available can be very wasteful.

When faced with this same sort of dilemma, I have employed the following approach:

• Scope the project. Give yourself an idea about what you're getting yourself into, and develop a list of features by breaking down the project into a series of tasks.

• Prioritize Features. Decide which features must be completed early, and which will provide immediate value to your customers. Don't worry if your developers end up working on the same modules, but make sure you have a good process and tools to manage code merges.

• Get your team involved, and ask your developers to aid you in breaking down the features into a list of more easily managed tasks. Review as a group and adjust tasks as needed so that they can be more easily estimated.

• Ask each developer to choose a task to implement - or a group of tasks depending on how your iterations are going to run - from the top of the priority queue, which the developer would like to work on.

• Have each developer work on only one thing until it is completed before moving on to selecting the next item from the top of the priority queue. You may be tempted to have your people change tasks occasionally, however this will lead to waste in terms of the developer's time. If you find yourself with dependency bottlenecks, you will need to adjust your task priorities and minimize the waste.

• Don't be afraid to have developers running with overlapping iterations, and manage your releases accordingly. This will help minimize time wasted between releases waiting for tasks to be completed.

Ultimately, being Agile is about finding a solution that works well for your team, your company, and your customers. It's up to you to tune your process by finding the balance of practices that will work best for you. How to divide your tasks is going to be a very important part of a much larger process, but should be kept as simple as you can make it to encourage willing participation, and to avoid difficult to solve process related problems developing later on.

Answer 6

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.

Of course this doesn't always work ...

Answer 7

No developer team organizational discussion would be complete without mentioning Dr. Fred Brooks' Surgical Team.

The basic formula is: one Surgical Team per Unit of Work

Defining a Surgical Team

The concept of the surgical team is based on two fundamental ideas:

1. Fewer developers are better per unit of work because cross-talk kills productivity.
2. High-output developers way out-perform low-output developers (and according to Brooks, there is no such thing as a medium-output developer), so you had better give them the most important work to do, and limit their distractions.

A surgical team is comprised of 3-10 developers:

1. A chief programmer. A high-output developer, who does most of the actual programming.
2. A co-pilot. Another high-output developer, who does some programming, but also some administrative tasks, like attending meetings and gathering requirements.
3. 1 - 8 assistants. Brooks describes these as developers responsible for things like documentation, code cleanup, research, writing tools/algorithms, testing, etc. Back in the 60s Brooks proposed exactly 8 roles, but with modern tools you may need as little as 1 or 2, and should probably be assigned based on your project's needs.

Defining a Unit of Work

So now that we can put together a team, what do we assign them?

• If the project is very small, this is easy. You assign one surgical team to the whole project.
• Otherwise, then you will need start with a person or team that is in charge of the entire project's architecture. It will be their job to modularize the software appropriately so that work can be split amongst additional sub-teams. The achitecture team can also take on other work, too, as to not spread developers too thin.

You should see three basic, acceptable patterns emerge:

1. Exactly 1 sub-team for each layer (UI, DAL, etc)
2. Exactly 1 sub-team for each module (Home Page, Support Site, Shop)
3. A mix of the two (a low-level framework team, and a UI-focused team for each module)

Answer 8

Here is what I would do:

If all the modules are small, then you can give each a module to work on. Otherwise, do this:

1. Define each module size, complexity, skills required to do it.
2. Define each team member skills.
3. Define which people work together well and which ones don't work with others well.
4. Assign large modules to teams of people that work together well based on module skill requirements and team skills.
5. Assign remaining modules to people who can't work well with other people based on module skill requirements and team skills.

The above will not work if the people who don't like to work with others are the most proficient ones and this is a common case, so make an exception to 4 and 5 accordingly