How to Structure Mendix Teams for Optimal Results
How to Structure Mendix Teams for Optimal Results by Roald Kruit
In my first post, we outlined The 7 Keys to Deliver Better Applications Faster through Effective IT/Business Collaboration. In many ways, that post embodies the very goal we set out to solve with Mendix: to improve collaboration between IT and the business as a way of accelerating the application development process while ensuring greater project success.
This collaborative approach would be much harder without the Mendix App Platform. And just as the platform facilitates an innovative approach to building applications, it also necessitates a different way of thinking about your development team.
In this post, we outline some important considerations to help you structure your Mendix team to deliver optimal results.
Create Teams that are Small, Focused, and Productive
Amazon CEO Jeff Bezos pioneered the notion of the “two-pizza team”: If you can’t feed a team with two pizzas, it’s too large.
The business value of small teams is clear: less cost, greater focus, and higher productivity. Within application development, small teams also mean shorter lines of communication and less documentation and more efficient knowledge transfer—all of which result in better software and faster time to market.
Unfortunately, two-pizza teams have largely been a pipe dream due to limitations with traditional development methods. The Mendix App Platform makes them much easier to achieve. Because productivity is significantly higher and engineers are able to fill multiple roles, you’re able to have much smaller teams: 2-5 people versus 7-9 people or more, depending on the size of the project.
Moreover, rather than having a separate project manager, we see in practice that assigning this role to your senior-most business engineer is much more effective. Because he/she understands both the business and the platform, they can make the best decisions for the project and ensure optimal knowledge transfer of what the project wants to achieve.
TNT Express, Agis Healthcare, Achmea Healthcare, and LV= insurance are all examples of Mendix customers that built large or complex applications with only 2 project members: one with a business focus, the other with a technical focus. An even more telling example is a North American bank, which plodded along for four years on a large .NET development project. Using Mendix, the team is now roughly one-tenth the size and the project is marching along toward completion.
Balance Business and Technical Engineers for Optimal Results
In contrast to highly technical development tools, the Mendix App Platform’s visual modeling environment [see application model on right] can be understood by a wide range of users. Even non-technical team members can very quickly and easily build business applications.
Thus, the general profile of a Mendix engineer varies from the traditional developer to the business analyst. Our customer Digital Risk recently shared how their Mendix engineers tend to sit somewhere between IT and the business; in other words, they have some technical skills but they’re also business-facing and process-oriented. Over time, this client built its team around two types of Mendix engineers: one more business focused, dedicated to understanding business processes and delivering the best solution, and the other more technical, focused on extending the framework through custom widgets, advanced platform features, etc.
This best practice holds universally true: a successful Mendix development team consists of both business and technical engineers. While the line is blurring between these roles, each has a different perspective that helps ensure the solution is sound both from a functional (process, usability, etc.) and technical (security, performance, etc.) perspective. A small team of one business engineer and one technical engineer literally can sit with the business, collaborate closely, and deliver results quickly.
For example, a global logistics company needed to build an invoicing application to support an extremely complicated business process. A Mendix engineer sat with a business user on the finance team to build the application. At one point, the business user took control of the laptop and said, “I will build the microflow; you make sure it works.” This example illustrates how the two roles can work together to develop applications very quickly and effectively.
Empower Fly-in Experts, New Members, Etc. to Quickly Get Up to Speed
The Mendix App Platform makes it easy for team members and other participants to get up to speed quickly, even when they’re joining projects already in progress. The reason is that visual application models are far more intuitive than Java or .NET code, reducing ramp up and knowledge transfer. Project members can quickly understand a specific process or piece of functionality, and immediately add value.
This is particularly useful for fly-in experts. As discussed in our IT/business collaboration post, a single Mendix resource can fill multiple roles that were traditionally split among multiple specialists. In the process, they’re able to complete 80-100% of the work themselves, with the exception of topics, such as theming; custom widget development; integration; performance optimization; etc. In these cases, fly-in experts are brought in only when needed, rather than sitting idle for long periods.
At a large consumer products company, fly-in experts were brought in for specific SAP integrations, theming, and performance. The SAP specialist was flown in only for a week. After the other team members were trained, they were able to handle many of the integrations themselves. This was a very effective way of working, as blocking issues were resolved fast and a scarce and expensive resource wasn’t used more than absolutely necessary.
While fly-in experts are often brought in during the middle of the project, we’ve also seen them used quite effectively at the beginning, particularly for UX design and architecture. For instance, at a pension fund, experts were brought in early on in the project for design and styling of pages. The Mendix engineers were then able to fill in the functionality and technical details of the application.
Get More Out of Junior Members, Balancing Quality and Cost
The balance of senior and junior team members has traditionally been a tough nut to crack. Put too many senior resources on the project and costs quickly spiral out of control. Offset that with too many junior resources—including an army of offshore developers—and you run into quality issues, potentially jeopardizing the entire project.
The Mendix App Platform addresses this challenge by allowing teams to get more out of their junior members, effectively balancing cost and quality while minimizing risk. For starters, the learning curve is extremely short thanks to Mendix’s intuitive, visual modeling environment. Within three weeks, junior team members can go from zero to hero—becoming fully productive on the platform.
In addition, when you have such small teams, you’re able to have really effective master/apprentice relationships where a senior member works closely alongside a junior member, reviews their work, etc. These relationships—which are difficult on large teams—further accelerate the learning curve.
At one client, 2.5 senior members were paired with two junior developers right out of college. The junior members took the basic and advanced Mendix training, and within 3-4 weeks, were working on their first project, building modules and functionality.
Lastly, it is much safer for junior team members to develop in Mendix compared to traditional code-based environments. With Java, you have a high probability of runtime mistakes, whereas Mendix has 10 times more design time checks due to model analysis techniques to increase software quality. The Mendix Business Modeler even guides users on how to fix the issues, helping to prevent errors in production.
“It takes two flints to make a fire.”-Louisa May Alcott
With the Mendix App Platform, you typically need only a small team of two people working closely together for productivity to catch fire. In addition to keeping the team small and focused, it’s important to balance both business and technical engineers as well as junior and senior members. This way, you’re able to optimize productivity and cost within your projects, while ensuring you deliver applications that are both functionally and technically sound.