Multidisciplinary Development Teams
Here at KrakenFlex, we don’t just have dedicated teams of front-end engineers, back-end engineers, testers, or data scientists. More often than not, our teams have members from these different disciplines all mixed up together in one big soup.
By going through a simplified example based on one of our recent projects, I want to illustrate the benefits of building multidisciplinary development teams.
Let’s jump into it:
The Goal
To make reports containing asset data available to customers via our customer portal.
The Plan
We need to create:
an app that number crunches asset data and generates reports for our customers
an API to retrieve these reports
a page in the customer portal where users can download the asset reports
Or, put more succinctly:
The Team
Let’s meet the team:
Each component that we need to build requires different skills, e.g. data analysis for generating the content of the reports, setting up cloud infrastructure, developing a UI with a great user experience. You can see that by bringing together a variety of skill sets, the team is more than capable of delivering the new feature.
The Process
Step One: Setup & Design
Our data scientist starts by developing the queries to run against our data lake — this will form the content of the reports once automated.
One of our engineers sets up the infrastructure such as cloud storage, CI/CD pipelines, alerting, and monitoring. Note how this step doesn’t require sending a request to another team; we give our teams the power to create everything they need.
Having our second engineer create a Swagger API specification gives our team a goal when building the API. It also gives our front-end engineer a better idea of what to expect when developing the user interface.
Finally, our front-end engineer creates a mockup for the new reports page in Figma.
Step Two: First Pass at Building App Logic
With the design phase complete and CI/CD pipelines set up, the team begin building out app logic and getting this checked into the code repositories.
Our data scientist fleshes out the report generator app — bringing the report queries developed in step one into code.
The engineers implement the endpoints on the API, adhering to the previously defined Swagger API specification.
Our front-end engineer transforms the mockup into an actual web page.
At this point, all three components are completely separate; the report generator does not write out to the final storage location, and the front-end does not use the new API.
Step Three: Bringing It All Together
The next step is to stitch everything together.
Our data scientist and one of our engineers team up on the report generator app to output the reports to the required location.
Our front-end engineer and second engineer collaborate on the UI to communicate with the API to download new reports.
Note how tasks aren’t ‘thrown over the fence’ and the team members work together to link up parts of the system rather than independently.
As a result of this step, a basic version of the new feature is ready.
Step Four: Testing
Up until this point, our team wrote unit tests for each component. They had to pass before being merged in and deployed. Manual testing followed, using a plan agreed upon when filling out the JIRA tickets. With a simple version of the feature running end-to-end, it’s time to implement some tests against the live services.
One of our engineers develops integration tests using Jest that run against the new API to ensure that it can read and write reports in the development environment. If these tests fail, then deployments of this app to production are blocked.
Our front-end engineer adds to our Cypress test suite that runs periodically to test the complete customer workflow of downloading reports from the UI. Alarms are triggered if these tests fail, and it is up to the team to fix any problems.
The End Product
Following that, here is a clip of the new feature in action:
Final Thoughts
We don’t have a blueprint for our development teams (and probably never will). Our teams are formed based on the areas and problems addressed by the team. We want our teams to have complete ownership of parts of the system, which results in multidisciplinary development teams.
As you can see from the example above, multidisciplinary development teams allow developers to see a feature from inception through to end product. They enable us to deliver products to end-users in a shorter amount of time. They are essential for us being Agile.