Essential and Beneficial Software Development Organizational Roles

Question

Our software development department currently consists of a project manager/chief architect, a few developers, and a DBA (as well as some support/helpdesk staff.) We're looking to expand and formalize the roles/positions of the team members as well as bring on addition members.

What roles do people feel are essential, ie: absolutely necessary, to an successful software development team? Also, which roles aren't necessary but have useful benefits?

We're trying to work out an agile methodology so which roles best fit that process?

Answer 1

Like many answers in Software Development, It Depends.

Support roles become more important as the size and complexity of the project grow. There is no one-size-fits-all answer.

It also depends on the skills present in your core developers. If it is a small project, and one or two developers have great SQL skills, you might not need a DBA. If the developers are awesome at writing unit tests and disciplined in performing their own integration tests (again small project!) you might not need dedicated QA.

For a very large project, all of the traditional roles are necessary.

For most projects, that fall somewhere between small and very large, the degree to which each role is nice-to-have vs. essential depends on the nature of the project and the skills of the team members already participating.

Answer 2

If you're trying to be agile, you'll want to have a customer or customer surrogate working closely with the team. On a small team you could double this with the Chief Architect, but it could be useful to get someone who's not involved in implementation-level things to represent customer interests, as often customers aren't going to care about the specific inheritance model you're using...

Answer 3

You'll have to look to the particular agile methodology you're implementing, presuming you're following a model and not trying to roll your own. If you were following XP (the prototypical agile approach) you need a customer representative and a project manager, and a bunch of competent developers. You don't need more internal structure in order to be agile. Of course, some agile approaches have a lot more structure than that, but then you have to match the structure to the approach.

If you're planning to roll your own, and just try to be agile about it, my belief is that the point of agility is not to formalize things to the point that you can't rearrange them. You add structure and process when you need them, but you also try very hard to get everyone to be self-aware and empowered to remove structure and process when they turn out not to be useful. The hard part is remembering why the structure was imposed in the first place so you can distinguish opportunities to remove it from times when it's momentarily costly, but saving you from big headaches you were supposed to have learned from.

Answer 4

Where are you feeling the pain?

• Are there quality issues? Look for a QA person
• DB needs not getting fulfilled quickly? Look for a DBA/DBD
• Low end development work bogging down the Sr. people? Look for entry level/JR developer
• problems with usability/design - Look for a designer
• Translating business requirements into technical documentation - Look for a BA
• Handling server capacity and configuration - Look for a sysadmin
• Managing domain names, network configuration - Look for a network analyst
• Technical leadership among the developers - Look for a team lead

You need to mold the team around what the client is looking for and where you're feeling the current pain.