The challenges faced when building software can be hard to define. Unlike tackling an Ikea flat-pack or building a bridge, progress can be unclear and problems often aren’t recognised until it’s too late. Collaborative, adaptable approaches have been proven to work best, because they allow teams the flexibility to bail fast and keep on moving. But these ‘agile’ test management methodologies can be anything but. So, how can you stick to plan without risking budget blowouts and PR disasters? To begin with, it’s integral to be aware of exactly what you’re doing and where it could go wrong.

Let’s take a closer look at the key risk hot spots for software developers.

A disconnect between management and the team
Because areas of tech expertise are often very specialised and abstract, there is a tendency to delegate, then abdicate. But whatever you’re building, there’s no substitute for switched-on, communicative management. ‘Once technical quality assurance is assigned, you really need key decision-makers to stay on top of it,’ says KJR’s New South Wales General Manager Adam Bird.

It doesn’t take a PhD in IT to stay abreast of the day-to-day challenges of a development team. As Adam states, ‘Managers need to be saying: you’re my champion on this. Keep me on point and if you need anything from me let me know, otherwise I’m assuming you’re comfortable. I’ll check in with you in a week to see how you’re progressing.’ In this line of business, what can seem like a small bump in the road can end up costing millions to fix down the track – so it’s crucial that teams feel supported when problems inevitably arise.

One technical quality assurance is assigned, you really need key decision-makers to stay on top of it.

Misappropriation of agile management systems
Even the most capable leader can’t effectively oversee every aspect of software planning, design, analysis, testing and construction. That’s why agile approaches have become the go-to. In a traditional management strategy, each stage of development needs to be completed before the next can begin. With agile, you loosen the rigidity of task sequences and decentralise responsibility, meaning that teams can work more collaboratively and efficiently. Shorter development phases are also intended to leave more room for feedback from stakeholders before excess money is spent.

While this is great on paper, decentralising responsibility can also exacerbate three major problems: teams reinforcing bad ideas with groupthink, working on bad ideas for the sake of appearing productive, and passing the buck once it becomes apparent the idea was bad in the first place. ‘Generally an entity won’t want to recognise that it’s on a trajectory to failure,’ says Adam. ‘It helps to have a fresh pair of eyes, someone external to the team, to tell people they’re in the wrong space.’

Unrealistic goals
Of course, gains in efficiency don’t matter if you haven’t set realistic goals. ‘You hear this term velocity a lot when people talk about agile,’ says Adam, ‘but velocity isn’t speed. Velocity is speed and direction.’ Ultimately, it comes down to knowing what the problem is that you want to solve. If it’s framed upfront, you can communicate it to the team and unify yourselves around a common goal. There’s so much pressure to upgrade, update and revolutionise, but the first step should always be to realise the purpose you want your software to serve. That way the difference between perceived and actual progress becomes clear and the product gets delivered on time. And everyone’s happy.

Contact our team for further information 1300 854 063 / info@kjr.com.au