Solving 3 common software engineering challenges

After years of implementation and hundreds of conversations with engineering and product leaders, we’ve seen a few things and have some knowledge to share. We’ve pulled together three of the most common roadblocks that teams run into and some recommendations to overcome them to get back on track.

Challenge: Long Pull Request Cycle Times

Long pull request cycle times put delivery at risk, and, in the same vein, unbalanced pull request responsibility creates risk because fewer people are familiar with the codebase. 

Recommendation: Build better PR review habits and equitable engagement from all team members

Start by asking yourself the following questions: 

• Is there a documented PR Review process? If so, what is it?
• Is it being followed?  
• Where is it breaking down? 

Suggestions to improve your PR Review process:

1. Explicitly state the desired priority and enforce it in standups and check-ins.
   Example: Tickets can only move into “In Progress” if there are no open PR review requests.
2. Keep an eye on who is reviewing the most PRS and ensure balance across the team for improved knowledge sharing. There is value in having junior developers tackle senior developers’ code reviews. Junior developers will learn the domain faster and think like senior engineers more rapidly if they ask good questions — and they’ll also learn to ask better questions over time. 
3. If you do not have the entire team reviewing PRs, ensure that those authorized have time allotted for that responsibility and track how much time it takes.
4. Review your team’s current definition of done and that your team is aligned. For instance, if your team considers submitting the PR as done, then once it is submitted, they are no longer looking at it, which can lock up the cycle and create bottlenecks. Reviewing your definition of done and ensuring it encompasses defined steps before a task and/or project is completed can eliminate this issue and create more cohesion across the team.

We have you covered if you’re looking for more support with how to go about creating your definition of done or would like to review Allstacks’s definition as a starting point.

Challenge: Stories & subtasks are too large, and it's hard to show progress

Your team’s stories and subtasks are too large so the team struggles to show or communicate incremental progress. 

Recommendation: Break down stories and subtasks into value-sized chunks

Stories and subtasks are ways to group work and monitor progress. We recommend viewing stories as a small chunk of shippable value. The usual story criteria are considered through INVEST - Independent, Negotiable, Valuable/Vertical, Estimable, Small, Testable. A best practice on subtasks is to ensure they require no more than a full day of work complete. This methodology ensures that progress can not only be seen but is also easily updated and visible. In the same light, if the tickets aren’t moving, it’s a quick indicator of a lag in progress and a potential red flag that might need assessment.

To improve the planning of tasks and stories you should ask hard questions like: Why aren’t tickets moving?  Can we break this task down further? This will lead to better alignment and accountability and empowers the software engineering team at an individual level to get involved with the process. 

Challenge: The team has too many commits per pull request and/or too large of pull requests.

Recommendation: Breaking Down PRs & Commits into Value Chunks

We commonly get asked, “How do we break these (pull requests and commits) down into smaller, easier to deliver and manage pieces?” First and foremost, it is imperative to note that pull request and commit size are independent of each other, but the ultimate goal should be to have both small enough to find direct value. For instance, a smaller commit size has an extremely high value when errors or issues arise because they can rapidly be sifted through and unwound to locate and correct the code that is unstable and/or in error. 

Process suggestions: 

1. Pull request per story or pull request per subtask
   1. 1. 1. These are detailed chunks of value and it is easy to know what they are
         2. As long as stories and subtasks are smaller and more precise, it’s easier to find value and shrink the size of pull requests and commits
2. Teach developers the importance of maintaining code 
   1. Allstacks suggests pairing senior developers who have small commit practices with junior developers who do not to ensure best practices are taught properly 
3. Process does not generate outcomes or output. Process teaches culture, teaches habits. Habits and culture are what generate the output and outcomes. This is why a process should be something the team can sustain and understand. Once the team grasps the why it is much easier to have them adopt the process and shift the culture to generate the desired outcomes. 
4. Get buy-in from the team and be flexible to reiterate - When creating the process around commit sizes and pull request review policies, get buy-in from the team around what they see is possible and what potentially will solve the problem. Set the test period of time up and review the process. If the process improves the experience and had a positive outcome, leaving the process as is might be an option. If it didn’t create any improvements and/or made things worse, be flexible to reiterate and adjust the process to try for the improvement and/or positive outcome sought. 

If you’re looking for style guide reference points, we have selected a few from different companies that might spark some inspiration. Our list includes:

• Airbnb
• Google 
• GitHub
• GitLab

More from Allstacks 

• Getting started with OKRs in software engineering
• Leadership spotlight with Girish Hoogar: Managing internal and outsourced software development teams
• A Checklist for Modern, High-Performance Engineering and Product Orgs