Top 5 ways to increase speed and quality for your software teams

Many of our customers lose patience with their internal IT teams because the teams usually default on delivering within the right time. Even if they deliver within the deadlines, there will be problems with quality; the bugs count would increase multifold. Especially after a release.

With us, we have never had this problem because we follow a prioritized list of non-functional checklists that are optimized for each customer and each product. Based on the current product maturity, the list will differ. For a startup, the speed of getting to the market might be very crucial. But for an enterprise customer, the quality could be the deal breaker. Our analysts break down the market and help come up with the list of the most important non-functional requirements that would suit the customer.

That said, let's look at how we can improve the speed of software development teams in general. The following tips and techniques could be applied to any software team (internal or external) and the results would be encouraging.

1. Identify the right sprint duration

Many of our customers make this mistake. They either choose a very big sprint (often confusing releases with sprints) or they choose a very small sprint which is unsuitable. Most of the problems with speed and quality would be solved if the right sprint duration is chosen.

We recommend the following guidelines for choosing a sprint duration.

For new companies, startups, and small products

• Choose a small duration of 1 week
• Ensure that the product could be deployed multiple times per day (if necessary)
• Track the sprint velocity very often
• Combine grooming with one of the standups so that you don't waste time
• Smaller sprints ensure that the work is visible and gives a feeling of momentum to the team

For mid-size products, teams

• Have the sprint duration as 2 weeks
• Most of the teams will fall under this category
• Code can be deployed atleast once per day
• Have dedicated grooming and planning days within the sprint

For legacy products, large teams

• Choose a sprint of 1 month
• Big products which have heavy integration or legacy products that cannot be easily built will fall under this category
• Code should be deployed atleast on a bi-weekly basis (mid of sprint and end of sprint)
• Ensure that a week is allocated for bugs that arise from integration (towards the end of the sprint)

2. Identify the scope better

Many software issues could be root-caused by product managers not detailing the scope of the feature or the user story. This leads to delays in development and also to lots of bugs if the feature has overlapping modules of functionality. Many times the product owner has to cut down the scope of the user story to keep the development simple. Also ensure that the scope is documented somewhere - either project management tool, wiki, or documents. It would be better if the history of the document could be tracked.

• Ensure the scope is well-documented
• Scope of each user-story should be definite and clear
• Product managers should be detail-oriented and should think of all use cases
• Sprints shouldn't ideally be started without proper scope for each user story

3. Do not backlog bugs

Bugs should never be backlogged. This may seem controversial but most teams have the habit of moving low-priority bugs to the backlog and never picking it up. Bug clean-up should happen at the end of every sprint and all bugs should be fixed then and there. No exceptions. This leads to two things:

• Team begins to understand the importance of the right, good code
• Test coverage keeps increasing over time and would cover most use cases

We cannot overstate the importance of this point. But most managers would think that this is tough to follow. Our suggestion: Begin the development with this principle in mind and it would work out eventually.

4. Educate the team on the Whys

Most team members never understand the why the aspect of doing things. When the team understands why certain features are being built and how they will fit into the big picture, it becomes easier for the team to function without friction. Also, many team members, if they can see the big picture, would build systems that would help in the long run without skipping on the immediate sprint deadlines. Ultimately, the team becomes better at knowing the Whys.

5. Write tests

We cannot say this enough times: WRITE TESTS. Most small companies would skip out on tests because that may take time and would not help in being fast enough to develop. We would suggest an alternative approach: Find the product market fit, develop quickly and once you know that there's a future for the product, start writing tests. This ensures that the product is built quickly as well as built for the future. Also, tests do not slow down development as most managers would think. Tests would increase the velocity of the developers rapidly once a threshold of tests is reached. It increases the confidence and the speed with which you can change the code. So our suggestion: write tests, always.

Conclusion

These above suggestions would help you to win when it comes to the software team's speed and quality. As we acknowledged, every team is different, every company is unique. What works for some companies, might not work for others. But it is always better to know the guiding principles and aim for the best.

Bonus tip: Celebrate all wins

This is a bonus tip for the ardent reader: Celebrate all wins - small or big. If the team delivered the sprint without no bugs, celebrate it. If the product launch was successful, celebrate it. There are no limits to celebrations. The team will eventually fall into the winning methodologies and look for processes that will help them win.