Everyone wants everything to be faster in software development.

Ask executives how they motivates employees, and they’re likely say, “I ask my team to deliver 150% of what they’re capable of and hope to get 100%.”

Asking for that kind of output is asking for burnout. You can’t just jam as much as possible into a system and hope something great comes out. The quality of work will take a nosedive, and your employees will quit.

Problems with the software development process don’t usually reside with the engineering team – they’re often found in other areas of the organisation.

>See also: Everything old is new again: how software development will come full circle in 2016

The significance of structure

As an organisation grows, specialisations begin to develop and leadership starts to build vertically integrated teams around them.

For example, let’s say you’ve got a vice president of design who hires design directors, who in turn hire design managers to hire and manage designers.

If a new project requires a designer, you call someone from the design department to put in a request for a designer, and the design team figures it out from there.

The same thing can happen in engineering, business analytics, product development, and every other part of an organisation.

The outcome is a collection of institutional silos focused on their own stovepipes, with little to no idea of what’s going on in other departments, let alone the organisation as a whole.

This siloed approach lengthens the supply chain through which ideas must pass so engineering can prioritise and complete the product.

The implications of culture

Organisational culture often limits responsiveness even further. What happens if your culture dictates that employees must put in 80 hours a week to complete a project?

You can’t motivate people to solve difficult problems or build complex solutions by asking them to deliver beyond capacity.

In fact, doing so tends to have the opposite effect, lowering both the quality of the software and the team’s morale. Not that time-boxing certain items or putting time constraints on a project isn’t effective, but these ‘solutions’ don’t make sense over the long term.

The most responsive teams are those with the tools and authority to get the job done – however, some enterprises think it’s strategic to remove autonomy and decision-making authority from their teams. When people lose accountability, their motivation can languish, and you lose the momentum and efficiency necessary to deliver results.

What practical steps can be taken to improve team responsiveness and accelerate software development?

1. Introduce slack

Slack, just as it sounds, is essentially a lack of activity. Look at the difference between a rope that’s pulled taut and one that’s left to hang loose. The latter is more flexible and pliable, isn’t it? This is what you want: a flexible team that is agile and responsive.

Design and engineering teams use this slack to solve problems that arise as a side effect of their primary tasks. They also use this time to improve product quality and long-term maintainability.

Of course, the opposite also is true: organisations that encourage work at a frantic pace create lower-quality products with maintenance issues.

Giving people in your organisation time to think critically about their work is your first step toward improving quality and steady progress.

2. Limit work in progress

Don’t overcommit. If you don’t limit the number of things you’re working on at one time, you’ll have no breathing room. Your team needs time to incorporate feedback and make iterations rather than hurriedly push projects through the pipeline to get to the next one.

3. Delay commitment

Limiting work in progress can generate a long queue. The solution is to delay commitment until the last responsible moment. This allows you to build time into your plan to make the kind of adjustments necessary to follow through on whatever functionality the team is working on.

Delaying commitment also provides the added benefit of additional information. Not making promises gives you the opportunity to collect the best information available and determine how to proceed with a project. Plus, this data informs your decisions on what you will do as opposed to what you might do.

4. Shorten the queues

Shorter queues inevitably lead to shorter wait times, allowing you to minimise cycle time. While delaying commitment and limiting work in progress helps, you must still monitor these queues.

>See also: 4 directions that will frame enterprise software development

Learn to look at features in terms of ‘weighted shortest job first’, meaning the easiest task to complete is sometimes the most valuable; it organically shortens the queue.

5. Make decisions close to the point of activity

Trying to implement efficiencies from the C-suite doesn’t always work. You’re not close enough to the action to make the best decisions for the team. Even if a decision is in the team’s best interests, you’re often too far removed.

Less is more. Ultimately, the way you speed up business progress is by limiting the volume of work. Shorten queues, give teams the space to do high-quality work on fewer items, and give yourself the luxury of enforcing more economic prioritisation.

Sourced from David Kullmann partner and development manager, Citrusbyte