The 10 problems slowing your development workflow (and how to fix them)

The heart of any engineering team is its workflow—how projects move from ideation to a working product, how customer feedback makes it from a ticket through the latest sprint. Engineering teams have never needed external motivation to improve—iterating is central to the job. Now more than ever, though, customer’s growing expectations for speed and quality should drive lasting improvements to your workflow.   

Even though agile is meant to be flexible and enable room for quick shifts and pivots, there’s a long tradition of "just enough" in terms of process, design and testing. The point is that you need some foundational process, even if it's minimal. At a high level, most agile development processes look similar, even Kanban or Scrum. Both prioritize quick turnarounds and continuous refinements that deliver results. Most systems, even minimal processes will have some flavor of these five fundamental steps:

• New Ticket
  
• Development
  
• Review
  
• Testing
  
• Deployment
  

Before diving into the weeds, examine your workflow from a critical distance. How many steps are in your system? How many were there a year ago or when your team first implemented the workflow? 

It’s likely that your process has evolved over time, but not necessarily for the better. Workflows can become muddled with additional steps that create bottlenecks and delay cycle times. For example, a bug slipped through on a sprint, and as a consequence, your team added a second review step at the end. That fastest way to improve your workflow is to remove redundant or unnecessary processes. 

Now that we’ve explored the workflow from 1000 feet, let’s get down to the ground level. Each step in the system from the new ticket all the way to deployment can be optimized for speed and efficiency, and together, work in harmony to create lasting improvements to your workflow. 

At each step we identify problematic patterns and behaviors that you may recognize across your team and solutions you can use to address and resolve them, fixing cycle times and improving efficiency flow.

Work starts with a new ticket, so how are you getting it out the door? How engineers interact with new tickets has lasting consequences across the lead time, cycle time and workflow. 

The Problem: It takes the project manager too long to assign new tickets 

You consistently find your lead time, or the time from when a client submits their ticket and sees a result, remains just outside your target. 

The Fix: Utilize a pull system

Pull systems let the engineer pick up new work when they’re ready. New tasks constantly enter the funnel, and as engineers finish one ticket, they can readily move to the next. They don’t need to worry what they should be doing and work stays at a constant flow. 

The Problem: Tickets are slowed and team is maxed out 

New tickets are starting to pile up and move slower and slower through the workflow even though you’re maxing out the team’s available resources.

The Fix: Start optimizing for flow efficiency

Optimize for flow efficiency instead of resource efficiency. Flow efficiency is the ratio between active time and total time on a task, and it can help you understand what work is actually in progress. Here’s why: If a developer is given four days to build a feature, their workload according to resource efficiency could suggest they’re tapped out. But, if hey need only one day of focused work to complete it, that equates to flow efficiency of 25%. Resource efficiency also puts more focus on doing more things at once. Humans are technically incapable of multitasking, so the goal should not be to do more at once. The goal should be to optimize the speed of the task. Focusing on flow efficiency still keeps a team busy, but they’re able to focus on completing one task at a time at a natural cadence. 

The meat of the work takes place in the development stage but tasks are easily delayed or bottlenecked right from the start. To maintain good flow, it’s critical to remove development roadblocks. 

The Problem: Development stage slowdown

Your development stage takes longer than expected due to one or more of the following: An unusual amount of time refactoring, high churn or tickets bouncing backward in the workflow.

The Solution: Check for high churn, refactoring and backflow

While improving old code is important, it often leads the developer outside the scope of the ticket. You can spot this by looking for high levels of legacy refactoring. Don’t necessarily discourage this work — it is important, but encourage the developer to follow a more formal work pattern. Ask them, along with your entire team, to report needed updates that you can submit as a task later on, giving consideration for the holistic scope and depth the project requires. 

If your team is sustaining higher than usual churn levels or that tickets keep going back and forth in the development process, there could be issues with ticket requirements either changing in flight or missing altogether. Review churn and ticket backflow regularly with your team to understand the trends for refactoring, churn and backflow. This will allow the team to spot the issues and see where the break in the process is.

The Problem: Overloaded team member

You see a backlog of work behind a team member, though the quality of their work is always at a high level. You also notice other developers handing off certain tasks to this person.

The Fix: Cross train the team to spread the work

Each team has a domain expert or two who unintentionally bottleneck work. If their domain expertise lies in a critical area, consider cross training other team members and manually assign these tasks to multiple hands. You may even ask the domain expert to conduct the training. At the same time, assign the domain champion other tasks that help them round out their skills. 

The review stage is a chance to collaborate and problem solve together. If it’s too rushed or squeezed, you’ll see more problems and churn down the line. 

The Problem: Code review crunch

You’d like to conduct code reviews more frequently on smaller commits, but instead, they tend to happen toward the end of a sprint. Team members don’t like to share their code until they think it’s perfect. 

The Fix: Focus on continuous delivery

Teams might not share their work with each other because they feel they’re uniquely qualified to complete a task, they fear the judgment of their peers or sprint deadlines are creating an end of cycle rush. To address the first two potential issues, you may require work to be submitted a certain time before the review or implement a midway step that gets another set of eyes on the code. Less formally, you can encourage collaboration in team meetings, adding time for a small code review, or by manually facilitating collaboration in one-on-ones, helping point developers to their team members for assistance. If you feel the issue is related to sprint cycles pushing reviews to the last minute, shifting your team’s focus on delivering continuous value to customers, instead of finishing the sprint, could help alleviate the end-of-sprint crunch.

The Problem: Last-minute pull requests

When large pull requests come in right at the end of the sprint, it can make the team feel too rushed and unable to give appropriate time to the review process. Likewise, the code often has more errors as they weren’t spotted earlier by another developer or vetted informally.

The Fix: Create a better cadence

When someone is dropping big pull requests at the end of a sprint, or hoarding code, they’re creating an unnecessary last-minute crunch. Typical engineers might submit completed pulls multiple times a day, whereas the code hoarder may submit only once a week. Working with a code hoarder takes more empathy — they likely just finished a lot of work and could feel burned out. If it’s one or two developers hoarding, approach the topic casually; get them talking about their last pull request and how they felt the process went. They may not realize all the help at their disposal or see the benefits of frequent commits and review. To help them overcome this, you can implement a culture of checking code in at regular, short intervals. By creating a regular cadence for submitting code, it will decrease the likelihood of huge pull requests coming in last-minute.

If it feels like hoarding is more widespread among the team, it’s a good idea to establish or reestablish team values around incremental progress and delivering continuous improvements.

Testing is the true litmus test of all the work that’s come before and exposes inefficiencies in other parts of your system. Whether you build testing upfront or after you commit code, it’s a critical step before deployment.  

The Problem: Solution disconnect

As you’re testing the code, you learn that the solution doesn’t quite match the original problem in the ticket. In retrospect, maybe the ticket was never that clear to begin with. You see high churn and lots of jitter, or back and forth between the developer and the ticket submitter. Code ends up back in development, slowing down your cycle times. 

The Fix: Clarify your requirements

To be effective, user stories or original inputs, need to describe a clear outcome. This can’t be overstated. The more the concrete the objective or user story, the less potential for churn. For example, a ticket that says, “fix the button on the landing page” will result in more churn than a user story that says, “add the hover transition from blue to green on the landing page button”, or better yet, “the landing page button does not change when hovered over. Please have it transition from blue to green.” 

The more complicated or multi-staged a fix is, the more critical it is to have clear inputs. Lack of clarity on an input may be a result of unclear requirements, lack of system understanding ahead of time or plenty of other issues, but establishing concrete inputs are the responsibility of both the engineer and the product leader. Adhere to a clear ticketing process, including sending problematic tickets back to an earlier part of the workflow. This will allow the data to develop to provide the necessary insights into ticket backflow and its implications on your production cycle.

The Problem: Scope creep and indecision 

In addition to the initial jitter, you’re seeing lots of back and forth between developers as the ticket moves through the system. Someone goes beyond the intended scope or a project manager’s indecision leads to changes in the middle of the workflow.

The Fix: Keep your communication clear

Again a ticket should have a clear, simple objective. Anything left open for interpretation can and will be interpreted differently, creating more back and forth discussion on what actually needs to be accomplished. But beyond clear objectives, there’s more you can do to avoid a game of telephone between your team members. You can improve handoffs by keeping all the information within the same work management tool. Reduce the amount passed through email or chats. Anything that requires the new task owner to look up information, clarify the task, or change tools will increase the cycle time.

At this point, work should move out the door and developers move back to the start of the process. What’s holding things back? 

The Problem: Last minute code fixes

By the time your code reaches deployment, you expect to ship it quickly only to find last minute issues arise that send it back to development, review, or testing. 

The Fix: Set new review expectations 

Heroing, or last minute code fixes, while helpful, signal that something is broken earlier in the process. At its worst, the team could wait for the hero to step in, and their last minute fix becomes an expected step in the process. Don’t enable or encourage heroing — instead, set the expectation that your team catches issues in the review and testing steps. If necessary, build in an extra review or testing step in the workflow to keep last minute adjustments to a minimum.

The Problem: Post-review adds

Also at the last minute, you’ve got team members who add just one more thing right at the end of a sprint, usually after the main pull request was already approved. 

The Fix: Identify the cause and adjust

Reiterate that by the time you reach deployment, the time for additions has passed. It’s time to ship. Try to understand whether a certain type of late pull request is common or if it’s just a specific developer who’s coming in last minute. If it’s a type of code, go back to the user story to ensure it captures the full scope and has clear outcomes in mind. If it’s a specific developer, work with them to submit more frequent commits and collaborate with others. It could also be an opportunity to reallocate resources and time to different parts of the process. Identify bottlenecks or tight turnarounds and adjust as needed.

More than ever, customer expectations are shifting and realigning to new realities. To continuously meet the needs of their customers, your engineering team needs every advantage it can get. Start with data to objectively understand the nuances and patterns of the team to build lasting improvements to your workflow.