Here is a rundown of the main issues with a suggestion or two on how to limit their impact:

Poor Technology Choices

From the outside this can often seem an odd statement. How do you know you’re making the right choice when there are so many to choose from? Many software projects are created in the wrong technology set and either just put up with it or pivot into a different tech mid project – making all previous work largely redundant. The correlating effect of making the wrong choice in the early stages can be huge.

All development teams have a preferred technology to work with. The question should be what is best for the project, not what is best for the team. If the project needs don’t match with the team then they are the wrong team, it’s not about getting the team to change to adopt something for the sake of working on the project, that has some inevitable conclusions when the team can’t complete the project on time, on spec or at all. The developer must always do the right thing for the client and if that means not working on a project because of a tech mismatch then that is the correct decision.

New generations of software developers will come in with new languages and approaches. New = risk. If the project is safety critical or has a regulated nature then Ada – despite being 25 years old – is the right choice, not the latest fashionable language that’s breaking ground. The mobile space is a lot more fluid and fast pace in terms of change, but should be seen in the same light, sometimes the last gen languages are still the right choice over the next gen.

Agile is the answer to everything – NOT!

Development methodologies come in all shapes and sizes but ultimately no matter what you think of them, you need one. They’re not a magic bullet that will solve all your problems but they do limit the size and shape of issues.

Waterfall – the established wisdom for many companies still remains a viable option. Agile, the young pretender to Waterfall’s crown has become a middle management battle cry, despite many using it not really understanding the concept never mind the associated problems with it.

Under scrutiny Agile still makes most sense when used as part of cloud based application development. The need to rapidly and frequently update applications makes this a sensible approach. Waterfall favours slower release cycles on products that have a larger qualitative code requirement (FinTech, MedTech, Banking, Safety Critical)
Any choice you make is not going to remove the productivity issues that most software teams face but it will keep the development cycle within a monitorable and measurable environment that management can understand and assess.

Inadequate and Under-Resourced Testing!

If your development team is running short sprints, then the testing and deployment process is pivotal to having an efficient workflow. The testing should ensure product quality and avoid broken code making it to the live environment but it must be uber-efficient to not slow or disrupt the successful completion of the sprint.

Automated testing processes, commonly referred to as Continuous Integration (“CI”) is the best solution for allowing the team to test rapidly and deploy when code successfully passes. Designing and implementing CI into the work flow is a specialist task and is expensive at the outset, sometimes making it hard for smaller development teams to justify the cost.

The return on the investment into CI should be huge. Development teams should be able to make quick updates and changes and deploy them into the live environment with the surety that the code has high integrity. What this does mean is that developers need to take a higher level of personal responsibility to create and maintain the automated tests – even if the team includes a dedicated DevOps developer. CI does not remove the need for test engineers but it should allow a smaller number of people to cover a larger code base more efficiently.

No Long Term Product Road-map

Many businesses with a software component often start off with the notion that the software has a path and can be added to, amended and expanded. This intention often gets lost, forgotten about or is the first thing to be cut when times are tight financially. Software dates like everything else and all the company is deferring the cost to a later date, it doesn’t go away.

As the company grows and the user base within the software increases then it’s often a case that strategies at the crazy end of the spectrum are opted for. Every customer having their own version of the software is a common outcome of under-investment at the right times, making maintenance and updates insanely complex and time consuming.

A 12 to 24 month product road-map that is well thought out and funded at the right level will always ensure that both the development team and the customers are aware of the point in time when new features and updates are coming on-stream and can therefore plan accordingly. Anything other than this means the company and the customer are acting tactically not strategically – firefighting today’s issue rather than planning delivery further ahead.

Weak Project Management / No Product Owner

Getting a software project to market relies on a symbiotic relationship between the product owner and the project manager.

The product owner must understand the customer and their requirements. The project manager must understand both the development team in terms of skills and the technology in terms of capability. The two must then come together to produce a rational and reasonable set of tasks and timescales that allow the product take shape with the right functionality and in the right timescales.

The common mistakes include the Product Owner attempting to be the project manager and attempting to guide the team without having the required understanding of the issues. The other common mistake is no product owner at all, the Project Manager is then left to try and create software that has the user’s best interests embedded into the product without really knowing who the customer is in the first place.

Teams split across multiple locations

This is the great white elephant of software development. Outsourcing became a thing for software development in the late 1990’s and despite the huge increase in productivity, work flow and communication tools it still remains a major risk to any software development project.

In an Agile project management approach the daily stand-up is complicated by multiple locations and time zones and therefore loses its basis purpose. In many instances testing and development are not in the same location and that can increase the time it takes to examine and identify issues ahead of agreeing the fix – at which point this goes around the circle again.

Creating different projects in different offices and managing them centrally is less of an issue. Developing the same project in multiple locations and expecting an efficient delivery is unlikely.

Environmental Costs

There is a lot written about what the best environment for software development teams to exist in, its very subjective and circumstantial. It’s often written that open plan offices are very disruptive and that developers do better productivity wise when they are in small rooms with just 2-3 people in each. Whilst the concentration levels might be more consistent you also need to consider the company culture and the wellbeing of the staff.

Like most things in life it’s about balance. If the staff can work to reasonable standards in an open plan environment I (personally) still think that is better than the cubicle farm approach. Some developers definitely need the calm and quiet and some can work fine in the hustle and bustle of an open plan space. It’s something that needs consultation with the staff and for an open platform for discussion so that staff needing quiet can get it and others that need stimulation and human contact can also thrive.

Don’t under-estimate the effect of a poor work environment if the development team is struggling to deliver consistently or has communication issues.