7

We are a product based website company. We deal with online sell/purchase of automobiles. We have an already-established product with daily 100k visitors on our website.

Current scrum team - six full stack developers and one Tester. Full stack developers deal with C#, JavaScript, SQL. Average experience of developers in around 2-3 years.

What is the best approach for this?

  • All full stack developers:

    Since some sprints have more backend work, some have more front end related work so we need not worry about fetching adequate work for (frontend+backend) for each sprint.

    Less dependency on individuals as all developers work on different language time to time.

  • Backend developers, Frontend developers:

    I feel this way better quality code would be written as people would need expertise in just one language i.e. either C# OR Javascipt. Things would be delivered faster with better quality as people would get work which they know really well. Easy for them to focus and improve their knowledge in one particular domain.

Just wanted to know if someone has already experimented this, or what is the general view on this problem?

| improve this question | |
  • 4
    What best does mean for you? – Laiv May 20 '17 at 8:16
  • I mean if there is any recommended approach for this. – maverick May 20 '17 at 8:35
  • 1
    There's no magic formulas or techniques to create balanced work teams. It very much depends on company organization and the strategies for production. Both options are fine as soon as they satisfy the specific needs and expectations. – Laiv May 20 '17 at 8:54
  • How is the team doing actually? Is there any leack on the productivity? Is the knowledge within the team enough to deal with the project and its needs? If the team is already formed as your option A, why to change now the strategy? – Laiv May 20 '17 at 9:14
  • 1
    Team is doing well, but expertise is missing, everyone knows many things, but all partially. So sometimes we end up making bad decision due to business urgencies. – maverick May 20 '17 at 9:17
18

Or option C: All the somewhere in between-stack developers.

Recognize that everyone has their strengths and weaknesses and use them that way.

Make sure all your developers can support the full stack, but have people work in their expertise most of the time.

This way you get best production out of your people while also securing your team will not tumble over when for instance your front-end developers both decide to leave in the same month.

| improve this answer | |
1

The idealic scrum team would be composed entirely of people who are all experts at every single function necessary to deliver the product. Of course, life is not perfect, so you make do from there.

Specialization is great, as long as your organization is cool with paying people to do nothing at times. That may sound sarcastic, but it's actually a decision some business actually make. They accept that because the resources are specialized, there may be periods when there's nothing for them to do, but the organization has weighed the benefit of having that specialization as more valuable than the resource waste.

You'll of course get more bang for your buck from jacks of all trades, but overall quality may not be as good. Again, that's a perfectly acceptable business decision an organization might make.

The answer to your question, then, is whatever your business wants. Personally, I prefer jacks of all trades. Specialized developers can give you a bit more quality, but I've found it's a bit like the different between those $150 headphones that sound really good and the $400 one's that sound about 5% better. Yes, they're better, but is it worth it for so slight of a difference in quality? If you're an audiophile or someone in the industry that needs absolute top-of-the-line, then probably it's worth it to splurge, but for the average consumer, it's not worth it. It's much the same with developers. I'd rather have one developer that could do 5 different things 80% as well as anyone ever could than 5 different developers that are masters at just one thing. However, again, it's a personal choice, and the opposite may make more sense in some organizations.

| improve this answer | |
0

If there is a specific area where you are experiencing problems (say website doens't look nice enough) you could go with frontend developers who has more of a feel with design.

In general though i'd consider developers with more than 2-3 years experience. Hire a team lead/senior who has 10 years of development experience if you want to improve quality.

On a side note, (less experienced) full stack developers work best if you have a framework or two you focus on. For example angular & entity framework. Those frameworks avoid having to write detailed implementations (like you don't need to write your own sql queries) and force some structure on you. If your requirements can't be met by general frameworks then you also have a business case to hire a developer specifically with more experience in that area.

| improve this answer | |
  • 5
    The chances of coding spagetti-code with Frameworks is almost the same. Frameworks won't make your programmers better. The learning curve is unavoidable. So I would rather prefer to see the juniors learning the basics from the ground up. – Laiv May 20 '17 at 8:22
  • A leaning curve is unavoidable, yet juniors take in only so much new information. If you can simply something's they can learn other things better. And frameworks give no guarantee but can help with structure – Batavia May 20 '17 at 17:47
  • Destilling and filtering the info in the appropriated proportions is what seniors should do. To my experience, juniors are thrown to the wild with nobody keeping track and mentoring. Then nasty things happens and everybody throw up their hands. Frameworks have to little to say here. – Laiv May 20 '17 at 17:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.