This post originally appeared on Medium as How to Pick the Best Agile Consulting Company for You.

Technology is eating the world more and more every year. So it should come as no surprise that as companies seek expert guidance and capacity for their software engineering teams, agile software consulting companies are on the rise. With so many choices, choosing the best agile software consultancy to partner with your team can seem daunting. To help you navigate, we’ve compiled this guide on the various types of engineering expertise you’ll find in the top agile software consulting companies today.

While every good agile consultancy will practice some flavor of modern agile engineering (Extreme Programming) best practices, it’s important to know that each consultancy will approach engineering best practices with its own slant when it comes to the details. The important variables are as follows:

Dogmatic vs. adaptive

Most agile consulting companies today are wise enough to understand that there’s no one “best” way to write code. Regardless of which agile consulting company you choose, expect that you will be encouraged to use some combination of test-driven development (TDD), pair programming, continuous integration, collective code ownership, and refactoring.

Beyond this core set of practices, here’s where dogmatic and adaptive consultancies start to differ.

Dogmatic agile consultancies have a set of best practices that they believe in. They will want you to adopt these practices, or at the very least to be on board with the fact that any code they write will be written using these practices.

Adaptive agile consultancies, like Stride, pull from a playbook of best practices and adapt their consulting and software development practices to your needs.

For example, let’s take pair programming. A dogmatic company might insist on pair programming as the default, whenever possible. An adaptive company might be flexible with regard to the percentage of time the team spends pairing.

Which is best for me?

The dogmatic approach can be comforting and reassuring for teams just starting out, whereas the adaptive approach is often better suited to more established development teams that need a boost in capacity and some gentle tweaking or guidance on best practices.

Co-location vs. remote

Agile consultancies prefer either to co-locate with your team or to work out of their office.

• Co-location at your office—There are a handful of agile consultancies that prefer to co-locate with your team at your office. Most of these consultancies will prefer to co-locate with you full-time, so that they can mirror your work hours, your culture, and your workflow rhythms. Some co-location consultancies will prefer to do so only 2–4 days per week, instead of full-time.
• Co-location at the consultancy’s office—There are a slew of agile consultancies that prefer that your tech team (or a subset of your tech team) co-locate with them at their office. These consultancies are often dogmatic in their approach and host as a way to help you absorb their culture and best practices, so that they can teach you their philosophy for building software.
• Remote—There are many flavors of remote agile consultancies. This includes consultancies that are themselves remote, where each team member works from home or from various global locations. It also includes consultancies that have all employees come to their office, yet their office happens to be offsite. Remote consultancies can be in your state, they can be nearshore, or they can be offshore.

Which is best for me?

If you can afford to have the agile consultancy team at your office, it is highly recommended to co-locate at your office. Co-location is ideal for collaboration. Co-location is also ideal for working through complex problems as a team. In addition, the agile consultancy that co-locates at your office gets to experience your company culture firsthand, and they get to know your entire company, not just the tech team.

On the other hand, if you need a team that’s cost-effective to bang out some code when you have a relatively defined product backlog, then working with a remote team is doable.

If your team is relatively new to software development, if you don’t have an existing tech team process, or if you feel your existing process and culture are toxic and you want to send a small SWAT team away from your office to explore different ways of working and bring those best practices back to the larger group, then having your team co-locate at the agile consultancy is the best option.

Build for you vs. build with you

An agile consultancy is either going to build software with your team, or they are going to build software for you.

• Build it for you—Agile consulting companies that build product for you will collaborate with you to identify your prioritized backlog of features. They will likely give you frequent demos and hold frequent planning sessions to ensure they are continuously working on the most important features. Typically, you won’t get to choose who the team members are. You will have less influence in choosing the technology the team uses to build the software or to track things like the feature backlog and bugs. You also have less influence on the agile engineering practices used. Teams that build software for you will need to hand over the product to you once the requirements are met. Good “build it for you” consultancies will offer a maintenance contract after the product is shipped, in order to perform ongoing upkeep of the code they have written, or they will pair with your developers to train them to support it.
• Build it with you—Agile consulting companies that build product with you often co-locate with your tech team, either at your office or theirs. (Note: Remote teams can also build with you. In this case, you’ll likely use tools such as Slack and Google Hangouts to collaborate daily.) If you work with a “build it with you” consultancy, you will likely have your own team members (both engineering and product) on the same Scrum team with the agile consultancy engineers and product consultants. If the consultancy is good, to the Scrum team it will feel as if it is truly one team working toward a shared goal. Agile consultancies that build product with you will have a large focus on transitioning ownership of the software to your team once the product is launched.

Which is best for me?

If you have engineers on your team who will be part of the project team, then “build it with you” is the way to go. If you don’t have engineers, then you’ll need to go with “build it for you.” You’ll likely have either a product manager, project manager, Scrum Master, or product owner who owns prioritizing features you need built. The agile consultancy can also supply product folks, too, but ultimately you’ll want someone who works for you to make the final product decisions.

Specialists vs. generalists

Any agile consultancy worth its salt has engineers who can work in both greenfield and legacy applications. Beyond that, it’s important for you to understand whether the consultancy believes in specialists or generalists.

Specialists are developers who are deeply versed in one particular technology or set of technologies. For example, consultancies that employ specialists may say they have front-end developers and back-end developers.

Generalists are developers who can truly run the gamut, from front-end to back-end. Generalists can often also do a variety of other things well, such as mobile development, data engineering, DevOps, and product management. Consultancies that employ generalists often say they have full-stack developers.

Pro Tip

Please believe me when I tell you there is no single developer in existence who can do everything. Also please believe me that if you are seeking expert help in a technology that just came out six months ago, you don’t need an “expert” in this particular technology. What you do need is to know which technologies are adjacent enough to other technologies for existing expertise to be relevant. For example, Angular 4 came out in March 2017. You do not need to hunt the corners of the earth to find an Angular 4 expert. A seasoned agile full-stack engineer who’s been using React or Angular 2 can hit the ground running quite quickly. On the other hand, a full-stack engineer who’s not up to speed on modern front-end frameworks and who has been coding in Java exclusively for the past two years might have a steeper learning curve.

Which is best for me?

In my opinion, generalists are better than specialists for one big reason: new platforms and frameworks and languages are coming out at a faster pace than ever before. In order to ensure you are using the most valuable tool-set for your needs, you’re best set up for success if you work with developers who can learn quickly. This way, when Angular 4 loses out to the next shiny thing, your agile developer consultants can give you their well-informed opinions on which technology to use, versus having a specialist who will tend to recommend the toolset they currently use, which is not always the best answer for your business.

Employees vs. freelancers vs. staffing agency

The type of employee/employer relationship that agile consulting companies have with their developers is a key component in choosing the right consultancy for you. Some agile consulting companies have full-time employees, some use freelancers, and some are staffing agencies that seek only to find someone for a project after the project is signed.

Agile consulting companies with full-time employees are the top tier of pricing, because you are getting a stable team that brings you years of collective expertise. Agile consulting companies that are staffing agencies have very low overhead and very low risk, so while pricing is lower, you should not expect to get the same caliber of consulting from a staffing agency model as you’ll get from partnering with an agile consultancy that employs full-time developers.

And then there are freelancers. Some freelancers are sole proprietors. Other freelancers work as part of a larger consultancy. Freelancers who work as part of a larger consultancy are rolled into whatever model the consultancy uses for its other projects. Freelancers who work solo find one project at a time, charge the highest rate they can get, and then when that gig winds down, they find their next project. Solo freelancers are, in my experience, really smart and great to work with if you need only one person.

Which is best for me?

If you’re looking for “butts in seats” to pump out code, the staffing agency model is a great choice. If you need only one person, as I mentioned above, hiring a freelancer is an option. However, the minute you need a second person, you’ll have to reinvest your time into finding another company to partner with. Some freelancers have a strong network of other freelancers they can pull in, but most don’t. If you are seeking true consulting that will help leverage the skill set of your entire team and add business value beyond the lines of code written, then the cost of the higher-end consulting companies that carry full-time employees is a wiser choice.

How to pick the best agile software consultancy for you

Now that you have a sense of the variables you’ll find in each Agile software consultancy, the best way to vet and pick a partner is:

1. Speak with three different agile software consultancies. Tell them about your team, your culture, and your needs. Get a sense of their approach, their style.
2. If none of the three consultancies feels like a fit, go back to the drawing board and ask yourself if you really are seeking an agile software consultancy. Perhaps you are seeking a digital agency or some other type of firm.
3. If at least two of the three companies feel like a potential fit, meet with any of the three that you feel could be a strong partner. Do this in person if at all possible, or at least do a Google Hangout.
4. Speak with one or two references from each company you meet with. Ask to speak with a client that’s as similar to you as possible—meaning a client that has faced similar issues. It doesn’t have to be someone in your industry or even with your tech stack. Rather, it’s important for you to hear firsthand how the consultancy helped someone facing similar roadblocks.
5. Ask to meet the people you’ll actually be working with. This can be socially over lunch, or in a team meeting. It’s important that there be a culture fit not only between you and the sales team, but also between you and the agile engineers you’ll be working with. Again, Google Hangouts is an alternative, if the developers aren’t local.

At this point, if you’ve got a company you feel excited about, go for it! Be sure to get an early termination or a trial period, so that you can change your mind if you start the engagement and learn something that gives you pause.