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.
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.
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.
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:
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.
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.
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.
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.
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.