Scrum is designed to let skilled workers tackle complex adaptive problems. If that describes your team, Scrum probably has a lot to offer. Before I go further, let me explain the "Complex adaptive" thing.
Complex: specifically referring to problems with a lot of interacting parts that would either be very difficult to analyze simply with theory or completely impossible. Scrum has a bias towards "try something and see what happens" analysis.
Adaptive: discovering what happens with one thing in a problem may change how I approach the next thing, making predicting how the solution will unfold difficult or impossible.
Because you said you deal with lab work, analysis, research, and development, I would expect that your work almost certainly fits this profile.
As to your team, scrum encourages cross-functional teams. This does mean that you should have all of the skills needed to do the work somewhere on your team, but it does not mean that everyone needs all of the skills or that everyone has to work on every item. A certain amount of overlap provides more flexibility in how your team takes on work. Scrum also asks the team to own the plan for getting the work done. Many teams bristle a bit at this if they are used to being handed tasks, but most find they greatly prefer this approach once they get used to it. Finally, you do have a bigger team than Scrum recommends (the heuristic is 5 - 9). If you have a project management background, you've probably learned at some point that the number of communications channels on the team is equal to (n * (n-1))/2; so exponential growth with the number of people. 5 - 9 is the sweet spot where you get benefits of working as a team without too many communications channels. That isn't to say you can't have a 14-person team. I've seen it work. Just watch out for this problem. Then again, since communication is communication, you probably already see this regardless of which methodology you use.
Finally, if you're not writing software, some of the best practices out there won't quite fit, or you'll have to interpret them differently. For example, one Agile principle says "Working software is the primary measure of progress." We can replace the word software with "product", but what does product mean for you? For these kinds of problems, finding someone else in your industry (or a similar one) can help you learn from other people who've already figured it out. You can also work with an Agile coach to help you find the answers faster.
I know I didn't give you a straight yes/no answer. From what little I read here, it does sound like your team can benefit, but I don't know enough to say that with any certainty. I hope I've given you enough information to at least make a call on if it's worth trying out.
