Is it better to spend resources on a skilled team or good process practice?

Question

Which one of these is of more importance? Skilled team or good process practice?

When I say skilled, I mean logical, creative members with good coding and testing skills. Good process would be the development methodology, like agile, scrum, etc

I feel like process keeps changing and we are spending too much of time in implementing the process & its perfection. — juststartedmycareer, Mar 30 '12 at 14:27
As the answers show, there is still some ambiguity around the word _skilled_. Do you mean competent or experienced or above average? — Joshua Drake, Mar 30 '12 at 19:51
Have a skilled team, and a good process will come (so long as you listen to recommendations). The reverse is not true. — user16764, Mar 30 '12 at 23:28
What is wrong with doing both? A good process should not cost money. It should be seamless, be natural, and cause as few ( non-organic ) problems as possible. — Ramhound, Jul 19 '12 at 11:52
a skilled team will get you the best out of your good process. A good process does not a skilled team make. — jwenting, May 09 '15 at 16:32

score 12 · Accepted Answer · answered Mar 30 '12 at 14:22

If your team isn't skilled (as in your definition), you will get nothing done at all. In this case the process doesn't matter.

Not skilled in the sense of not much experience would be another matter. If your people are talented, but have not much experience with projects, then a good process may help avoid problems. Testing and early response from customers as Agile provides would most likely avoid many problems in such a situation.

score 6 · Answer 2 · answered Mar 30 '12 at 14:27

6

A skilled team is most important.

A skill-less team with all of the right processes will fail. If you don't believe me, bring your agile/scrum processes over to a different department (say, accounting) and see if they can make good software!

answered Mar 30 '12 at 14:27

brian

3,579
1
20
22

3

The problem with that view is that a lot of not actually very skilled people espouse it in order to defend their unwillingness to follow any process. – Michael Borgwardt Mar 30 '12 at 15:21
If management will let someone exist as an unskilled developer and as someone who won't follow their processes.. then most of the discussion we have here is moot because they've persuaded enough people, and perhaps themselves, that what they're doing is positive. – brian Mar 30 '12 at 16:03
management think all programmers are just 'resources' to be slotted in. Hence the fashion for outsourcing to the 3rd world. – gbjbaanb Mar 30 '12 at 21:45

score 6 · Answer 3 · edited Apr 12 '17 at 07:31

Your development process is only as good as the weakest link, so both are important.

An otherwise good team who have a disastrous process inflicted upon them, one which stifles development rather than facilitating it, could actually end up less productive than a team of poor developers helped along by a good process (I've seen this happen).

In my experience however, good developers tend to gravitate towards a work flow which is more efficient, if they have the autonomy to do so. Inefficiencies or pointless bureaucracy tend to be imposed from above, so a good manager/team leader can be critical in preventing teams being stifled by process.

Another point is that changing a team is something that takes time, whereas changing a process is often something you can do at any time.

In peopleware, Tom DeMarco and Timothy Lister talk a lot about how to get teams to gel, talking about growing teams rather than building them. Different processes can put up barriers to teams gelling or they can encourage the team to grow, so that is a consideration when developing a process.

Optimising a workflow can be a continuous process however - problems or inefficiencies in the process can be discussed and resolved as you go along. If they work you can look at other ways to improve your process, if not you can go back to the old way. You just have to keep in mind that the process is a means to an end, not an end in itself.

On your final point, only you and your team can determine if Scrum, or any other methodology will fit your requirements. If you are working in an otherwise strongly waterfall environment, introducing agile techniques may just cause friction with other teams you need to interact with. Similarly if other teams are using Scrum, you may find that adopting it yourselves can help interaction with those teams.

ChrisF · Answer 4 · 2012-03-30T15:34:13.897

5

As others have pointed out, no amount of process is going to completely compensate for a team that lacks skills. However, it will go some way to ameliorate things. For example, but having a process in place that requires tests to be written and the tests to pass you will ensure that the code you produce works (to a certain degree).

However, a bad process can ruin the efforts of the most highly skilled developers if you allow shortcuts to be taken and untested code to be released (for example). By this I mean that if pressures from management/sales etc. force developers to circumvent otherwise good practice then the process is broken. A good process has to be one that management buys into and acknowledges and honours.

Skills and process are complementary. Without either you can't produce quality code.

edited Mar 30 '12 at 15:34

answered Mar 30 '12 at 14:49

ChrisF

38,878
11
125
168

I disagree with your second paragraph. If a developer releases untested, broken code, she can't be "highly skilled". And I believe this is true for every example of "broken process". – nikie Mar 30 '12 at 15:28
@nikie - I see your point. I've not explained it very well. You can have a highly skilled team - that do usually follow good practice - but if management break that practice then no amount of skill is going to help. – ChrisF Mar 30 '12 at 15:30
Ok, I see what you mean. I still believe a team of good developers will deliver good software if left on their own. But if management actively forces a *bad* process on them, no amount of skill will ensure good software. +1 – nikie Mar 30 '12 at 15:34
1

@nikie - well a team of good developers *should* come up with a good process :) – ChrisF Mar 30 '12 at 15:35

score 5 · Answer 5 · answered Mar 30 '12 at 15:13

I think people are missing a point here.

There is a core level of competence that is essential in members of the team - if you don't have that level then yes there is a problem - however the question then becomes what one means by "skilled", would one regard these adequately competent people as skilled?

If the environment and the processes are good then these competent developers will deliver where a team of more skilled individuals without good processes might not because they will not be working together.

Everyone goes looking for "rockstars" and "ninjas" yet that's not what most of us are - good processes are about getting the rest of us to work to the best of our abilities

score 2 · Answer 6 · answered Mar 30 '12 at 14:45

Only having good practices, without skilled workers, is similar to the 1 million monkeys at 1 million typewriters writing all the great works... I've seen too many out-source companies who play up their [CMM / ITIL / Agile / whatever] practices with developers who couldn't code themselves out of a figurative paper bag.

score 2 · Answer 7 · answered Mar 30 '12 at 16:02

My answer is based on a couple of assumptions

The point is, which one will create better software?
Will one choice negate the other?
By skilled we're assuming at least a base level of competency

Is the fear that a process that is too rigid will prevent the team from hiring or keeping highly skilled developers? Does having a process hinder creativity, flexibility and delivering on time? And if that's the case, is it a poor process or one that needs some adjustment?

A structured process may make it easier to keep lesser developers or those with a tendency to be careless in line. Good processes by definition are the ones that return the best results.

A "highly" skilled developer that can't work within your team or your process for all practical purposes is not skilled. Skilled people deliver results in the context of the requirements. I'm not sure how far I would be willing to drop standards to appease some self-proclaimed, guru, prima donna, rock star, ninja, all star. Rowing faster than everyone else in the same boat can be counter-productive.

score 1 · Answer 8 · answered Mar 30 '12 at 15:02

As technical people, we have a tendency to judge things based on their technical merit. Our definition of "important" is that the software is creative, elegant, and interesting. A company's definition of "important" is that the software has a positive effect on the company's revenue. Having skilled team members is more important by the first definition. Having a good process is more important by the second definition. However, one being more important doesn't imply that the other is wholly unimportant.

Agile's whole point is that the process should adjust quickly to fit the needs of the business and the developers. If you're doing it right, it's generally beneficial to both, but it takes a little time to settle in. If you're trying to enforce some ideologically "pure" version of agile, you're going to have issues.

+1 But note that even "Pure Agile" means valuing "Individuals and interactions over processes and tools...while there is value in the items on the right, we value the items on the left more." — Matthew Flynn, Mar 30 '12 at 15:54

score 0 · Answer 9 · answered Mar 30 '12 at 15:19

Trying to implement a process perfectly is definitely the wrong thing to aim for. The goal should be to create useful software, the process is merely something that helps you reach that goal. If you ever feel that it's actually hindering you, you need to change that (and every good process description stresses this point).

score 0 · Answer 10 · answered Mar 30 '12 at 15:45

I think to be successful at software development you need to have a competent team and a good process. But a competent team with a good process will beat a team of experts with no process (of course real experts wouldn't work that way and almost no companies have a whole team of real experts). Incompetent developers with no process is the worst of all possible worlds. So really what you need to compare is a good process and competent developers and a poor process and competent developers and in this case the good process will win.

I would rank them this way

Expert developerts Good process
Competent developers Good process
Expert developers Poor process (bad process will drag you down and cause delays and bad choices etc)
Competent developers Poor process
Incompetent developers Good process (but more likely to turn into good developers with time)
Incompetent developers Poor process

Now the real problem is in defining competent developers and good process. A formal process is not necessarily a good one (see waterfall) and a developer with ten years of experience is not necessarily good either.

Scrum can be a good process in a legacy app, it can also be a bad process, the devil is in the details.

score 0 · Answer 11 · answered Mar 30 '12 at 21:31

There are a lot of good answers here already, and so I won't try to comprehensively answer the question in all its possible aspects. My own judgment on this issue would depend quite a bit on how hard the problems are that you're trying to solve. That's obvious I suppose; if your problem is sufficiently cutting edge, you need creative, able, insightful programmers. Process is no substitute. But if your project diet is humdrum, you can certainly build an environment where the senior developers you do have can coach the inexperienced, and you can use some software development processes to provide a support framework for this to happen. As long as you have perhaps >50% skilled developers, you should be able to get the project to move forward and develop your team's skills at the same time. This assumes that "skilled" includes having some coaching abilities, and of course that isn't always true.

Certainly given a choice I would establish a relatively modest skills floor; take on only developers who have already worked on maintaining an existing code base successfully. Grinding out crap software is easy. Maintaining an existing code base for a period yields vital insights about how to design good software.

Is it better to spend resources on a skilled team or good process practice?

11 Answers11