My team and I are rebuilding a site we developed around ten years ago, and we wa
ID: 650669 • Letter: M
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?
Explanation / Answer
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.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.