How to Tell if Your App Development Practices are Toxic

Inefficient development practices can creep into development teams all too easily. After all, the pace of change in our industry is such that a trick you picked up a few years ago that once saved you time and made you look great, could actually be hampering you now. Let’s take a look at some of the signs that bad habits are affecting your development team. And let’s be clear: there is no shame in recognizing and owning up to these habits. The difference between ineffective development teams and five-star app gurus is first recognizing, then changing those bad practices.

What are we building again?

Do you find that team members seem to be working towards different goals, or they’ve interpreted the goal in different ways? It could mean that the application’s original objective has gotten lost, or become unclear. Or perhaps the original objective has expanded bit by bit and you’re now suffering a serious case of scope creep. You have the same budget, people and time to make the app, but the project has sprawled and no one’s clear on which parts to prioritize. It happens all to easily.

Answer: Strong, clear leadership from the get-go is important so that the whole team understands the same long-term vision. Everyone needs to be able to answer: What’s the app for? Who are the users? How many users? What should it look like? How fast does it need to run?   You also need to be prepared for tough conversations if external stakeholders start tinkering with the original scope of the project.

Too many chiefs…

We’ve spoken previously about the dangers of allowing internal politics to interfere with the app dev process. Are the app’s objectives changing or becoming confused? If so, one reason could be that too many people are inputting advice, changing the goal posts and hindering progress. If everyone and anyone is able to make changes the app will never get made…or the resulting product will be unrecognizable from the original plan.

Answer: Letting different stakeholders have a voice can be a great way of ensuring people feel vested in the app. Even if only a small idea that they had ends up in the app, they can still feel part of it. But there are caveats: be careful who you share information with, be clear about when it’s okay to offer inputs, be clear about the app’s overall look and purpose, and don’t be afraid to stand your ground.

Stagnant practices

Development teams often lapse into bad habits while transitioning from a waterfall model to agile. We call this state “agile-fall” and you can see our checklist here for whether you’re living through it.  Teams often start strong with the move to agile, but then fall back into old ways: sprints take too long, planning happens in the initial sprints, then testing in the later ones, and not enough is automated.   These are classic signs you’re slipping into stagnant practices.

Answer: If this sounds familiar, you may be in “agile-fall” territory; that is, somewhere on the spectrum between waterfall and agile.   The way out is for the development team to keep challenging themselves and the organization to push the boundaries towards the agile model of best practice. It can be hard to do it alone. In this scenario, working with a development partner can help put you back on track.

Don’t re-invent the wheel

In short, don’t write it or test it yourself if there is a perfectly good alternative already available. Time and again we encounter technically highly proficient developers making poor choices on how to apply their considerable skills.

Answer: If you or your team is spending time on jobs that could be done more efficiently, it’s important to understand why and address the root cause. With some developers, it’s an ego game (“I can do it, so I’m going to do it”).   With others, the issue has to do with time management and understanding what platforms and tools are out there and can help. The old adage, “I’m too busy to delegate” springs to mind.   Perhaps the team is working to unrealistic time frames, in which case altering these would actually enable everyone to take a breath, think and then solve the challenge more efficiently. If the issue is skills-related, then training, building in time for experimental projects or choosing a development partner who can help transfer the much-needed skills are all options.

Team-building

Take a look at team structure.   If you’re working in a group that’s a dozen strong, or more, in which everyone’s role is clearly defined and segmented then you may be missing a trick, especially in the field of mobile apps.

Answer: In mobile, building great-looking, high-performing apps fast is imperative. You need to tailor your team to the task. Take a look at Forrester’s report, Build Five-Star Mobile Apps, 2015 for some great tips. Smaller, more focused teams of two to six people work better than large teams. Cross-training developers to increase the breadth of experience is important. And, since everything needs to happen faster in mobile apps, the traditional center of excellence QA needs to be replaced with something closer to a test automation model with frequent testing during development by developers. Of course, we’re biased, but then again accelerating mobility is our specialty and tools such as CI/CD with Jenkins and the Selenium framework will create great efficiencies in the way the app is built and tested.

Why not contact us to see if we can help you shake off any bad habits and improve your processes?