Is your product or new feature not coming along as quickly as you hoped? It’s frustrating when everything takes longer than expected and any addition of resources doesn’t seem to add up to more value. Don’t let your competitors with similar project sizes leave you in the dust –  improve your deployment process and get back in the game.

But here’s the problem: It seems overwhelming and you don’t know where to start. How can you fix a problem, when you can’t even define what it is? There are no simple solutions, but we prepared a quick guide that can help you ask the right questions and get back on track.

Identify the bottlenecks by starting from your symptoms and asking why. Here are some questions to explore with your team to find where your major bottlenecks might be.

While debugging is a normal part of deploying new features, it might be worth looking into how many hours are spent on this. 100% coverage has its own set of pitfalls, but you can optimize your testing in other ways.

Re-evaluate how your testing is set up

100% coverage might sound good on paper but it has its own set of pitfalls, but you can optimize your testing to more effective – and more realistic.

• Are you testing the right thing or are you misusing unit tests for complex business flows? 

• Are the tests meaningful and focused, or are you just doing them because you have to? 

• Do you automatically run tests after every change? Untested changes can lead to a domino effect of errors. 

Identify the right tools

Without the right library of tools and easy access, debugging will quickly become bogged down in mystery solving.

• Is there proper tooling in place for debugging? Logs, traces, monitoring?

• Do your developers have proper and easy access to debugging tools and relevant data? 

• Do your developers have quick access to debugging tools? Or does it take hours to just retrieve and access tools through a rigid process?

Remove unnecessary roadblocks

• Does the bug need to go through too many investigators?
  
• How difficult is it to deploy the fix?

• Are there expertise silos? That means, nobody has a full picture, but each developer has a piece of a puzzle that needs to be compiled together.

Sometimes we all need to do an honest reflection – it can be tempting to change direction every time a new trend or market scare comes up. Yet too many adjustments can make it hard for your team to keep up, new directions means new research, new tests, new meetings, and potentially dropping work on unfinished features. It leads to wasted resources or doubled work.

Who is involved

• Is it clear who decides the priorities?

•  Is it someone that has a 360 view of the project and access to all the points needed to make a decision?
  
• Do you have a product team with clearly defined responsibilities?
  
• Are the people responsible for the product empowered to make decisions and set priorities so they can deliver to the best of their ability.

Review your product roadmap

If you’re confident your team has clarity, another place to start asking questions is your documentation.

• Are the goals and milestones clear? 

• Can anyone who joins the team get a clear picture of where the product is going? 

• Do the milestones make sense for the product, with each milestone yielding a better working product? 

• Would the first instance of a working product be done with the last milestone, making the rest of them rather arbitrary?

Some things are impossible to predict and a feature scope can change. How fast your team can react to a changing direction can impact your deployment efficiency. Is your team paralyzed to make a decision and stuck on approvals? If yes, it might be time to loosen up some processes so it can be easier to change course.

Parse down your processes

Make everyone happier and more efficient by critically evaluating your processes.

• Is your team struggling with bureaucracy rather than coding?
  
• What is the reason for each step in the process?
  
• Does your delivery process have irrelevant steps, left over from previous team leads or projects?

Check the fit

If you’ve recently scaled up or down, it might mean that some processes that worked before have become flawed.

• Is the process fit for the size and the situation your company is currently in? 

• Are the right people checking the right boxes? There may be steps you can offload from tech to another department. 

• Is there manual work that could be automated? For example, we have powerful tools for automating testing available and it’s worth the time to implement them.

Delivery is structured into teams so that most of the communication is done within the team, while the communication between the different teams should be kept sparse. However, this is easier said than done.

Map out your team structure

• Why are the teams structured as they are? Keep in mind that there is no escape from Conway’s law – the design of your system will eventually follow your organizational structure. If these two aspects are not in sync now, then there inevitably must be friction in delivery.
  
• Is it possible to restructure the teams to match the common communication patterns? Merge the teams which communicate heavily and split out parts of the team which have a separate concern and don’t need to communicate with the rest of the current team?

If you just went with a trending new language, used what you’ve “always been using”, or just didn’t challenge the selection of a very senior engineer – it’s very possible you’ve ended up with the wrong tech stack for your project.

Match your people to the tech

• Does the team have proper expertise with the tech stack?

• What are the technical aspects that made you choose this tech stack? Are the benefits worth it? Do they actually outweigh the difficulty of finding experienced developers for it?

Justify your choice

If you can’t produce a defined business case for using a particular tech stack, that’s a red flag.

• If it’s a niche tech, what’s the justification for it?
  
• Especially when you are starting a project, would you prioritize time to market or the best performance for the first few users?
  
• Will there be any notable difference in the performance given your expected load? Is it worth the extra effort?

So, you’ve ended up either with too many bugs or features not doing what they should – or both. Now your users need a PhD just to test your product. Struggling to pass this critical stage of development will stop any product in its tracks.

Connect product and tech

Keeping these two disciplines in sync can ensure you build with the end users in mind. 

• Is there a lack of understanding between your product team and tech? 

• How do the tasks from the product make their way to the engineering team?

Communicate Product Definition effectively 

• How are the user stories defined and refined?

• Are the engineers asking the product team the right questions? 

• Are the different happy AND unhappy paths the user might take covered in the product definition? 

• Does the engineering team understand the designs that they should use?

It’s difficult to sign off a UAT or to run integration tests when the environment is unstable. It has a depreciating effect on both quality assurance and delivery efficiency.

Quality control 

• Is the quality of business code delivered to the environment subpar? 

• Is it possible to prevent this with regular, automated tests?
  -> If not, you can consider manual regression tests.
  -> If yes, consider automated tests running in a DEV environment, allowing for some instability, while keeping the UAT environment stable. 

DevOps 

• Is there a space for your DevOps engineers to try out their implementations? If they don’t have access to a closed environment to run tests, trying it out in the same environment as the development team can make it unstable.