Software development methodologies often come equipped with a set of tools. These tools are principles and activities that, among other things, enable predictability, drive continuous improvement, and help identify bottlenecks.
Scrum sprints provide visibility into future deliverables, Kanban’s WIP limit helps the team reduce waste, and XP (Extreme Programming) advocates for rapid feedback. These are just a few of the many concepts that each methodology offers.

Whether your team uses a more flexible methodology like Kanban or a more well-defined one like Scrum, you may be missing out on beneficial tools that are not built into your methodology of choice.
The popular software development methodologies available today have been a game-changer, but none of them (not even Scrum) provide a complete toolkit.

In leading teams of various sizes, product maturity, and stages of a company, I learned there’s a set of tools that assisted my teams in creating a culture of high productivity and consistent delivery of high-quality products.
Below I list this set of battle-tested tools that provided great value for me and my teams time after time. If your team is not practicing any of these tools, I strongly recommend giving it a try.

Task size limit
Whether your team is implementing user stories, requirements, or any other type of a deliverable, limiting the size of these tasks has significant benefits:
It provides focus for the team, shortens feedback loops, increases flexibility because there are more opportunities to make adjustments between tasks, smaller tasks are more predictable, and so on.
I recommend aiming at an average of one work week per task and no more than two work weeks.

Work-in-progress limit
Limiting work-in-progress (WIP) is about identifying bottlenecks and ensuring healthy flow in your development process. To put it into practice, limit the number of tasks (active or inactive) in each step of your workflow. You can, for example, limit the number of tasks currently in development to x2 of the number of developers on your team. If there are any inefficiencies in your development process, you will quickly reach the WIP limit and the inefficiencies will be exposed, forcing you to act.
While it is more commonly used in Kanban boards, the underlying principle behind it can be applied to any methodology.

Throughput/velocity calculation
Knowing your team’s task completion rate, combined with some basic math, can help your team plan more efficiently, provide estimated delivery dates to stakeholders, and identify bottlenecks in your development process.
Kanban teams frequently strive for tasks that are roughly the same size. This allows the team’s throughput to be calculated. When combined with the current backlog, you can deduct when each backlog item will be delivered.
In Scrum, a sprint backlog can be created by combining the team’s velocity and task size estimates.
For teams that have never used this tool before, the efficiency boost it provides is often not obvious. It manifests itself over time in an improved planning process and the invaluable predictability it provides for both small and large teams.

Pre-mortems
Perhaps the simplest of tools, yet one of the most effective ones with the highest return on investment. A pre-mortem is a session in which the team gathers to assess what will break in production and come up with ideas to mitigate these risks.
Ask the team to imagine the project has failed and to brainstorm every possible reason for that failure. Later, the team can devise methods to proactively detect these failures and prevent them from occurring in the first place.
It’s surprising how uncommon pre-mortems are, given their low cost and high value.

Retrospectives
The retrospective is a meeting in which team members reflect on their work and discuss what went well and what could be improved. Typically, retrospective meetings are held at the end of a project or sprint.
I’m assuming most of the readers are familiar with the concept, but I’m also assuming not all teams are practicing it regularly. It is often because the team focuses on pointing fingers rather than creating a blameless environment, an environment where team members feel safe sharing their learnings and looking for ways to improve together.
Being disciplined about conducting effective blameless retrospectives, with actionable results, is a critical component in a true continuous improvement culture.

These are just a few of the tools that I’ve found helpful in my work as a developer and engineering manager. I’m sure there are many more that your team can benefit from. The ones I listed provided the most value for the least amount of effort while meeting the core requirements of visibility, predictability, and continuous improvement.
I hope this list will help you and your team build better software.