0

We have a full-time developer team that consists of 3 Backend developers, 2 Mobile developers, 2 Frontend Developers, and 1 QA. Let me give them simple code-names: B1, B2, B3, M1, M2, F1, F2, QA.

Each product gets assigned to different team members based on their availability and skills. For example, we could have 4 ongoing products.

Product A developers: B2, M1, M2

Product B developers: B1, B3, F1, F2, M1

Product C developers: B1, F1, F2

Product D developers: B2

Could that be a valid practice in any way?

Improve this question
6
  • 3
    Not quite sure what/why you're asking. Could it ever be valid? Sure; depends on the situation.
    – Sarov
    Jun 30, 2021 at 15:00
  • @Sarov I thought software development teams (in general and especially agile) all members should be involved working on the same product. And If there is need to work in parallel products they might split themselves in both fixed teams. This was my suggestion to the management.
    – Unsuccessful Scrum Master
    Jun 30, 2021 at 17:18
  • 1
    What is your goal for this question? As-is, you asked "Could that be valid?". The answer is "yes". But what are you trying to accomplish?
    – Sarov
    Jun 30, 2021 at 19:33
  • The goal is that I wanted a convincing way to backup the idea of having a fixed one or two cross-functional teams where all team members work on the same product. I'm trying to prove my management that the current practice is wrong or at least a poor one.
    – Unsuccessful Scrum Master
    Jul 1, 2021 at 4:53
  • 1
    What isn't working with the current approach? Arguing that there should be fixed teams due to Agile theory isn't going to convince people if the results of the current practice are productive.
    – DaveG
    Jul 1, 2021 at 15:18

4 Answers 4

Reset to default
1

With only eight people involved I suggest you treat this as one cross-functional team with one backlog. A single team is much simpler than creating specialist silos of work, and cross-functional software teams are usually more efficient. Having one team provides flexibility, allows them better scope to self-organise and encourages synergy and ownership. Allow team members to assign their own work rather than someone else assigning it to them.

Improve this answer
2
  • This was my suggestion to the management, but can't emphasize this enough yet without proving that the current practice of splitting work is wrong.
    – Unsuccessful Scrum Master
    Jul 1, 2021 at 4:58
  • This sounds pretty much like what they are doing now. There's one team (so clearly cross-functional) and team members do work based on their availability and skills.
    – DaveG
    Jul 1, 2021 at 15:50
1

I'll answer this with another question: What would you do if someone went on vacation or was otherwise unable to do the required work?

I'm looking specifically at B2, but it could happen to anyone else. Say B1 has major surgery and F2 quits. There's a term for this problem: siloing.

The Silo Mentality as defined by the Business Dictionary is a mindset present when certain departments or sectors do not wish to share information with others in the same company. This type of mentality will reduce efficiency in the overall operation, reduce morale, and may contribute to the demise of a productive company culture.

https://www.forbes.com/sites/brentgleeson/2013/10/02/the-silo-mentality-how-to-break-down-the-barriers/?sh=2fd1177c8c7e

You've siloed your developers. Sometimes that's fine, but many times it's not. Siloing can lead to a number of problems, including having too much work for some people and not enough for others.

The military has another term for siloing that many other industries have appropriated, since it fits: bus factor.

The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus." It is also known as the bread truck scenario, bus problem, beer truck scenario, lottery factor, truck factor,[1] bus/truck number, or lorry factor.

https://en.wikipedia.org/wiki/Bus_factor

The lower the bus factor, the more likely you are to have problems when something critical happens. This focuses mostly on a bus factor of 1, meaning there's only 1 person able to do something, but any low number can spell disaster. Product D has a bus factor of 1 and that's bad. If something happens to B2, what do you do? Answer: you'll have to give the task to someone else who has no experience in the project and will take at least 2 times as long to finish and may make some sort of hidden mistake that B2 would likely know to avoid.

But your situation is special? Well, sort of. With a mix of specialties it makes the bus factor a little more complicated, but it can be understood.

Here's your bus factor breakdown:

Prod A: Backend 1; Mobile 2
Prod B: Backend 2; Frontend 2; Mobile 1
Prod C: Backend 1; Frontend 2
Prod D: 1

There's actually several bus factors of 1 here. You've stated there are 3 Backend developers, 2 Mobile developers, 2 Frontend Developers. Ideally, you'd have all 3 Backend devs working on all projects that need backend work, and all Frontend devs working on all projects that need from end work, and the same for Mobile.

This is the basic idea of cross training.

Cross-training will actually make you a better software engineer. By understanding the unique features and structure of each project, you’ll gain a deeper understanding of the problem space, and you’ll be able to use that understanding to compose the best possible solution for each individual project.

https://dzone.com/articles/cross-training-for-software-engineers

Yes, that can take time, but it'll be worth it to avoid a major catastrophe. It doesn't even need to be 100% full understanding of each project, just more than 0 (zero) and enough to get some idea of what they are getting into when they have to work on a project.

However, you can do a bit better still. You can cross train all your developers to handle all aspects of each project. Yes, that's going to take more time, but you'll get better developers in the long run. You'll also have a bigger pool of developers to pull from when the work piles up.

Some of this can be helped with code reviews. Get your non-Mobile devs to code review the Mobile code, and do the same with Backend and Frontend work. Once they get an idea of what they are looking at, have them do tasks and have the people who normally work on those tasks do the code reviews.

Example:
Dev B1 code reviews Mobile work for 1-2 weeks. (M1 and M2 still code review each others work.) B1 then takes a task and M1 or M2 code reviews their work and deals with any feedback. B1 then takes another 2-3 tasks and learns from code reviews. B1 eventually can take 2-3 tasks on any week and not have to worry about much feedback from code review.

I get that you're looking at different languages here, which will make things a bit more difficult. However, most are likely to be fairly similar, so it shouldn't be a major problem. Speaking from experience, C++, C#, VB, JavaScript, PHP, Java, and more are all very similar. I've used all of them, and many more, to do full stack and mobile development. In on week, I used VB.Net, ASP.net, and Oracle for work, personally I then used C++ for Arduino programming, Java and XML for Android work, plus HTML, CSS, JavaScript, PHP, JSON, and MySQL for a website.

Your devs don't need to be an expert in each language to complete work. The people doing code reviews are there to help make sure they aren't making any major mistakes and to help improve their knowledge.

Train people well enough so they can leave. Treat them well enough so they don’t want to. -Richard Branson
Employees are a company’s greatest asset. Yet many companies treat their employees poorly. Sadly, our system has fallen into a self-reinforcing command loop construct as follows: Increase shareholder value at all costs without regard for the human factor. The greatest investment you can make is in people. Employees are the backbone of any organization.

https://thriveglobal.com/stories/train-people-well-enough-so-they-can-leave-treat-them-well-enough-so-they-dont-want-to-richard-branson/

Your people will likely eventually leave, that's nearly a given, but you can make it so their time at your company was a beneficial to both you and them. And I'm not talking just financial gain. Having people you respect and trust when you go to work and even when you leave is significant. There's a lot of employers I don't care to have as a reference, since I don't trust what they'll say about me, but there's plenty of co-workers that I'd use as a reference. In fact, most of the places I worked were made tolerable because of the people.

Ok, so siloing and the bus factor focus on two different aspects, but it's two sides of the same coin. Siloing is often used to describe how a dev gets stuck in one specialty and can't get out, are always working on the same project, can't get promotions, and can get bored or burnt out by doing repetitive work. And bus factors are geared towards the unfortunate effects of an emergency situation, but siloing creates the bus factor problem in many situations, so they are related.

Improve this answer
0

The validity in sharing employees across projects, a very common practice, is derived in the quality of the planning, communication, calculated contingencies, and reasonable project controls to monitor performance and variances.

Improve this answer
1
  • Sorry, I just edited my question, I meant Product instead of Project, if that would make a difference. As I've said in the comment above, I thought teams should focus on only one Product at a time.
    – Unsuccessful Scrum Master
    Jun 30, 2021 at 17:23
-1

This is a Waterfall approach. Software engineering is better suited for an Agile approach.

So, the situation you're portraying where different team members are assigned to work on specific things in a specific order is a part of what is typically called the "Waterflow" approach to project management, because tasks flow from one stage to the next and going backwards is expensive. It works really well for tasks you can predict and plan ahead for, like building a skyscraper.

Unfortunately, software management is a domain that is extremely difficult to plan for, due to changing requirements and the vastly different outputs between different workers (a senior engineer might be able to do in 5 minutes what a junior engineer spends all day doing).

As a result, software engineering is generally better suited to a more Agile approach, where the team works as a whole to accomplish their goals, dependencies are minimized, and changing direction is much less expensive because you've done less up-front planning.

Improve this answer
11
  • "Software engineering is better suited for an Agile approach." That's a matter of opinion. Many teams work well under waterfall, it's just that devs tend to prefer to have a higher perceived level of control over their work. All too often, waterfall is disguised as Agile and the devs don't seem to know the difference.
    – computercarguy
    Jul 6, 2021 at 17:32
  • @computercarguy "That's a matter of opinion." No, not really. Software engineering is firmly in the "unknown unknown" Complex domain of the Cynefin framework, and the appropriate methodology to use in that domain is Agile. Waterfall is the appropriate methodology for the "known unknowns" of the Complicated domain, which would be things like designing and constructing buildings.
    – nick012000
    Jul 6, 2021 at 17:47
  • Searching for "agile vs waterfall software development", there's a lot of people who disagree with you, saying that waterfall can be better than Agile at times, and vice versa. seguetech.com/waterfall-vs-agile-methodology and hygger.io/guides/agile/agile-vs-waterfall and I could list many more.
    – computercarguy
    Jul 6, 2021 at 18:02
  • @computercarguy Like I said, the Waterfall approach is appropriate for projects in the Complicated domain like designing and constructing buildings, where things like dependencies, time elapsed, and cost can be predicted to a high degree of accuracy (e.g. where a change of 5% is considered highly inaccurate), but not all details are fully known at the beginning of the project. In the Complex domain like software development where these things can't be predicted with accuracy, Agile is the correct approach.
    – nick012000
    Jul 6, 2021 at 18:14
  • The links I posted were specifically about software development, where they say that Waterfall does have a place. I'm guessing you didn't read them? Or are you saying that you know more about the topic than the dozens, maybe hundreds, of people who wrote articles about the topic?
    – computercarguy
    Jul 6, 2021 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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