You need a lot of technical know-how to build an app.
But where does that know-how come from?
In traditional software development, we typically leveraged highly skilled specialists for just about everything. These experts would come in and focus exclusively on their major area of expertise. When their assigned tasks were done, they would move on to something else.
On the surface, this made a lot of sense: each component of the project was built by the best resources available.
As you might imagine, however, this also led to a lack of cohesion across the project. Components didn’t fit together as seamlessly as planned, changes created snowball effects, and troubleshooting was a painful experience involving far too many people.
Agile development frameworks such as Scrum took a different approach. Scrum envisioned a single cross-functional Scrum team capable of handling all the work in front of them. This generalist approach also made sense: each component of the project was designed and built by people who knew how everything fit together.
In my experience, however, neither extreme is conducive to building great software. You need a little bit of both to create great apps.
A Few Technical Skills Required to Build an App
Consider the sheer number of technical skills required to build an app these days. In this section, I’ve included a few of the most common. Most of them encompass a variety of sub-specialties, as well.
Software Engineering
Coders represent a significant portion of your software development team. And while they might possess general knowledge in many different areas, most of them do specialize in one area or another.
Databases
Database experts also represent a wide variety of specialist areas. In addition to coding all the different types of databases, architects specialize in planning out and designing data structures, administrators configure and maintain them, and data entry specialists populate them.
QA Testing
QA engineers have a knack for finding problems that few other technical resources possess. Their systematic approaches and methodologies are crucial in identifying problems before you ship your software.
Integration
If your application is linked or tied to any legacy or back-end systems or databases, you’ll need integration engineers with expertise in those systems and technologies. This could be for porting data, creating interactive reports, or even connecting systems seamlessly at a deep, fundamental level.
User Experience Design
UX Designers are tasked with providing a smooth user experience. They’ll be the voice of the customer when debating how to implement new features, always looking for ways to improve that experience. Creating an easy, intuitive workflow and eliminating unnecessary actions are their top priorities.
Software Architecture
Software Architects are important because they set the standards for your software development efforts. In particular, they make high level design choices that include your coding standards, toolsets, and platforms.
Visual Design
While UX Designers focus on user experience, Visual Designers are tasked with making the application look good. This is important because poor aesthetics can cause end-users to dislike or even avoid a product. Excellent aesthetics, on the other hand, can improve customer satisfaction and the overall perception of your software.
Building a Cross-Functional Team
As you can see, it takes many technical skill sets to build an app. If you engaged even one specialist for each technology involved, your development team could easily balloon to several dozen people. And that’s exactly what happened in those traditional software development projects.
A Scrum team needs to be small, nimble, and cohesive – typically from 5 to 9 people. For that, you need a carefully considered mix of specialist and generalist resources.
For example, say you have a project where most of the code will be written in C#. But you’ll also need some expertise in AngularJS and Microsoft ASP.NET. Do you want three specialists, one in each area, with limited knowledge of the other two? No. That would create bottlenecks and undue reliance on a single person. Instead, you would want engineers with multiple proficiencies across those three areas, and ideally all of them with some exposure to C#.
This can be challenging when working with larger projects that incorporate many different technologies. In the Scrum teams I’ve helped put together, we always identify “the most qualified person” for a given task, but we try to avoid him or her being “the only person” who could possibly complete that task.
Enlisting Outside Resources
Sometimes you’ll encounter a challenge that needs a specialist to weigh in. And sometimes you’ll face a short-term task that requires a skill your Scrum team lacks. In these cases, you’ll need to bring someone in to help.
There is nothing wrong with a Scrum team enlisting aid from outside resources. But there are two things you need to keep in mind:
- The team is still responsible for their results, not the outside resources
- Outside resources are not always available when you need them
For these reasons, it’s usually best to bring outsiders in as consults or to help design solutions. The actual work should be spearheaded by Scrum team members as much as possible. It’s perfectly acceptable to supplement your team with outside help for a particular production sprint when needed. Remember, however, that the Scrum team retains ultimate responsibility for their success and must make and sign off on any decisions.
Specialists with Generalist Skills
You might say that the best Scrum teams are composed of specialists who retain a variety of generalist skills. There are certain skills you must have on your team… and you’ll need more than an “average” proficiency level in those skills if you expect to build great software. But you also don’t want your specialists to be idle when their specialty is not the focus of the current sprint.
Take QA testing, for example. Every Scrum team should have at least one dedicated QA engineer on board. But does all the testing need to be done by the QA engineer? No. When it’s “all hands on deck” at the end of a sprint, anyone and everyone available can be executing QA test plans.
On the other hand, you probably don’t want your QA engineers writing code in their downtime (that could inadvertently influence their testing). But if they possessed certain generalist skills, they could help with things like data entry, or visual design, or writing user stories, or… whatever fits their particular skill set.
One rule of thumb I’ve noticed is that the more versatile a Scrum team is, the more successful they can be. Specialist knowledge is critical. But when you bring more generalist knowledge to the table as well, you’ll often discover deeper discussions, more creative solutions, and better overall results.
If you need help building an effective app development team, Ascendle can help. Contact us today and we’ll help you find the right path to mobile app success.
