Large team compositions, do you specialize or stay all round? - Mendix Forum

Large team compositions, do you specialize or stay all round?

1

When you work in larger teams, or perhaps even a whole department organized in several teams, do you specialize your team members or stay all-rounded?

 

And if you specialize, how do you organise your teams?

 

Examples could be that there are specialized developers, testers, scrum masters/coaches and other roles.

This could be within one team or perhaps you have specialized teams working on the portfolio of applications that your department manages.

Posted
1 comments

In general, it's more likely to find an all-round Mendix developer compared to traditional development. Nevertheless, I do see that specialized knowledge for certain topics is needed for a bigger or non-standard Mendix practice.

 

As I see it, the power lies in the ability to use skills and knowledge when needed, without keeping it unnecessarily occupied within an app or project. For example; a member specialized in UX or front-end work should not be tied to one app only. If you fascilitate this member to move from app to app, the specialized skills can be utilized effectively. Additionally, including other team members in such collaboration should be mandatory if you would ask me. As there is a need in another app, it's likely that the Mendix practice soon needs more of this skill. By enabling other team members to tap in to this knowledge, you'll end up with more T-shaped members over time. This can be applied to topics like testing, automation, cloud, certain integrations, etc.

 

In short: all-round by default, specialized/T-shape in addition. By aiming for many all-rounders by default, it's more likely that this group is able to recognize the need for specialization when needed.

Created
I totally agree, Jeroen. And I even see it going one (or two) steps further when it comes to low-code. Because to me, T-shaped is something that is pretty common in high-code as well. But low-code means faster delivery and often less team members. But, the team members still have to cover the full span of the SLDC. Is being T-shaped then enough? I'd opt for at least pi-shaped: broad knowledge of multiple aspects and deeper knowledge of at least two. Another aspect is from my own experience as a tester: when you are T-shaped, you know a lot about testing and something about developing. But, having deep (enough) knowledge of Mendix development helps me as a tester. It makes me more efficient, I know the pitfalls of the platform, can help with RCA, and can even help fixing bugs if needed. To me, being (at least) pi-shaped increases team collaboration and delivery efficiency. And I love pies.
Created