Software Development Team

Software Team Members

On a typical DevOcho nearshore software team we will have the following positions:

1. Software Developers - These are the builders. Depending on the project they are typically selected based on their experience and skillset. We typically recommend at least two software developers and no more than 4 per pod/team. At DevOcho, will look at the project requirements and make the recommendation on experience level, skillsets, and number of people on the team.
2. UI/UX Designers - if the project has a user interface or will have users interact with it we recommend having a UI/UX Designer on the team. Engineers are great at making things work, but if we are being honest, they often overcomplicate things. The UI/UX designer wants the software to be simple and beautiful. They work to reduce steps and sand rough edges. Software built with a UI/UX on the team is polished and fun to use.
3. Scrum Master - The old saying, "everything rises and falls on leadership" is also true on software teams. Developers might get carried away and "over-engineer", Designers might work on tasks in the wrong sequence so the developers are left without designs. Customers are often inexperienced in leading software projects. All of DevOcho's projects are run with the oversite of a trained and experienced Scrum Master.
4. QA Automation Engineer - Amazon is famous for not hiring QA people to work with their software teams. What works for a company with 1.5 million employees isn't going to work for your much smaller team of software developers. Amazon has 35,000+ software developers and an additional 30k to 40k tech roles. They can specialize and focus on single things. It's different on an Agile development team with 6 to 10 people. Someone needs to be focused on quality. That being said, we believe in automating the QA process as much as possible. We have QA engineers that build out automated tests to run against every single change in the software.
5. DevOps - There is a famous saying among software engineers, "it works on my box." This is in reference to things working in their development environment but then not working when they software is "deployed" to users. DevOps bridges that gap between the developers and the cloud. Our DevOps teams maintain continuous integration / continuous delivery (CI/CD) pipelines that will automatically test and deploy software as changes are made. They work hard to make sure that the software / system is online and that everything is automated.
6. Machine Learning Engineers / Data Scientists - It's rare these days for software not to have an AI or machine learning component to it. At DevOcho the ML Engineers and Data Scientists will analyze your data and build custom models, or they will engage with the large language models via "prompt engineering." They work with DevOps and the Software Developers to integrate those models into the finished software. AI/ML can bring magic to software.

Is Fractional or Full-Time better?

At DevOcho, we follow a modified Agile Scrum framework that we call "The DevOcho Way". What that means is that we work to ensure that each team is able to ship software without needing assistance from an external person or team. There is a ton of supporting research on this subject but to simplify: It's faster, and often cheaper, if the team doesn't need to wait on another person or group to do their job. The priorities and goals of the team are aligned when you are on the team.

In a perfect world, that would mean that everyone on the software team only works on a single project at a time, and if your budget allows that, it is our preferred method. In practice, most companies are more budget conscience, so we will place fractional team members on a team. These fractional roles are normally Scrum Masters, DevOps, and UI/UX. Scrum Masters often are needed a lot in the initial planning phases and then can scale down until the end of the project. Designers also often need their time to be front-loaded, so they will work more heavily at the beginning of a project and then are not needed as much until the end when users start doing more thorough user acceptance testing. DevOps will typically work a lot at the beginning setting up the environments and build pipelines, but can occasionally work less in the middle of the project. They will start back up at the end as the software is deployed to production and goes through user acceptance testing.