“What do you mean it won’t be ready for another six months?”

“When am I going to see something that works?”

“That’s not the app we wanted.”

“You said you could do this…”

Ever have conversations like that with an outsourced development team? Ever get that sinking feeling when you suddenly realize your project won’t be done on time… if at all?

What do you do?

Look for the Warning Signs

The first step to solving a problem is to realize you have a problem. And sometimes, companies don’t discover these problems until it’s much too late. So here are some of the warning signs you should look for from your mobile development team:

  • You’re not seeing demos of real, working software at least every two to four weeks
  • You don’t get a demo version to “play around with” in the first six to eight weeks of development
  • If you do receive a demo version, it’s riddled with bugs
  • The demos either don’t look right or don’t appear to be headed in the direction you wanted the software to go

Needless to say, you should be getting working demos on a consistent basis and those demos should be mainly bug-free. This is not to say that these demos won’t still need work on final look and feel or still have features that need to be completed… but the functionality that is there should be “production ready.”

Now that you know the warning signs, what should you do about it?

Assess the State of Development

One crucial bit of information you need to assess is this: how easy would it be to transfer the project from one team to another?

This can have a huge impact on your decision either way, so starting with this question is a smart move. Does the developer own intellectual property on the project or do you own it all? What sort of subject matter training or other investments have you made in the current team that would need to be duplicated for a new one?

Is the time it would take to “change hands” and get a new team up to speed worth it?

Damn it! That’s Not the App I Wanted looks at several ways you can deal with a development gone astray.

Ultimately, your decision hinges on another important question: do you feel like you can – and should – continue working with that developer? In other words, are the issues you find correctable… and are they willing to correct them?

Conduct a Mobile Development Assessment

This can be a delicate situation, as most developers will consider themselves the experts. But in my experience, although most development teams have a very good knowledge base, they also have some “blind spots” where they could improve their processes.

In How a Mobile Development Assessment Can Put You Right Back on Track we discussed the benefits an MDA can provide to a struggling or off-track team.

Keep in mind that you, the “buyer,” have plenty of options available here. You could make continuation of the project contingent on an MDA. You could allow a self-assessment (if they normally provide that service) or require a third-party intervention (recommended). You can pay for it yourself or negotiate a shared cost with the development company.

The outcome of an MDA should be an impartial look at what needs to change for you to move successfully forward. It provides both peace of mind for you and constructive feedback for the development team. Either way, an MDA can be a win-win proposition.

On a smaller scale than an MDA, you could bring in a second development team to listen to your user stories, review the code, and provide a more general or localized assessment. We’ve done this with a few customers to help them figure out what’s going on, and the results have been very productive.

Improve Your Communication

Often, when a developer “screws up,” it’s a sign that communications between your organization and theirs was not adequate. As you move forward, fixing the problems might be as simple as implementing more progress reporting, feedback points, and meetings. Scrum has built-in controls – such as demos every two to four weeks – to make this happen. But it only happens if those processes are being properly followed.

If you’re not receiving enough communication (or if the right things aren’t being communicated) then you should question whether agile development methods are truly in place. Start by looking for those demos. Ask to see the most recently prioritized user stories to see if they match your expectations. Make sure the Product Owner on the outsourced team is accurately conveying your requirements to the programmers and testers. And if you’re not sure where the communications are breaking down, you can always request an MDA.

Switch Developers

In some cases, you might feel like the best way forward is to cut ties with your existing development team and hire another. This option of switching developers is not an easy one, and should really be done as a last resort. Consider it when:

  • You’ve identified the underlying problems but the developer refuses to work with you to correct them
  • You’re no longer confident the development team can produce the product you want

There are many costs and concerns when switching development teams mid-project, so never take this choice lightly. Time, money, and intellectual property costs should all be carefully weighed in making this decision. In most cases, it’s far easier to correct a process problem than to get a whole new team up to speed.

If you do find yourself in this situation, you’ll want to thoroughly vet your next team. Some excellent points of guidance can be found in 11 Questions You Should Always Ask App Development Companies.

Your Software, Your Responsibility

When a screw up occurs, the responsibility to fix it falls on you. Whether that means giving the development team another chance or moving in a new direction, you need to make a decision that’s in the best interests of your company.

So don’t let your developer push you into producing a product you don’t want. And never fall into the “I’m not technical so I’m not sure if this is right or not” trap. You should be looking at real demos, not flowcharts and code. If you’re not seeing the demos and the progress being made, then the “screw up” has already happened.

Remember, this is your software, and the best time to correct mistakes is now.

If you have questions about fixing your software development process, or about Ascendle’s Mobile Development Assessment (MDA) services, we’re here to help. Simply contact us today.

Share This Article