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
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
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.
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.
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
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.
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.
My answer is based on a couple of assumptions
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.
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.
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).
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
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.
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.