The 6 Principles of Planning Development and Testing Workload

It is a general consensus that workload planning is one of the toughest parts of software development that can greatly impact the process either detrimentally or beneficially if done poorly or well, respectively.  When planning something, you work with intangible things, with events that haven’t taken place yet, you have to consider a lot of factors that may not be under your control. But workload planning has its own challenges as well. In CI/CD development cycles, the workload on the team can vary from one iteration to another, which creates additional difficulties in planning. Inconsistent and unregulated communication between the teams or even within the team, lack of team alignment may result in misinformation about the team or individual team member work capacities, which adds to the planning difficulty.

If these issues aren’t tackled early on, you may have to deal with a frustrated team, unevenly distributed workloads, missed deadlines and ultimately inferior development results. For your company or customer it will mean exceeding allocated budgets and delivering a sub par product.

Situations like the one I described above are easier to prevent than to correct. The vast experience my team and I have gathered from working with a range of projects and customers and the inspiration we continue to draw from the leading figures in our field, allowed us to refine our expertise and come up with a workable solution.

In this article I’d like to introduce 6 principles of workload planning. Practical application of these principles allowed us to make educated planning decisions and resource allocations on numerous projects, creating team workflows that were comfortable for team members, transparent, and delivered excellent results.

1. The Principle of Dynamic Workload

The word ‘dynamic’ in the name of that principle implies that a software project should be treated as a living, evolving construct, and it requires a fluid and responsive way of management. This is specifically true for workload planning. On the one hand, as a project manager, you want to distribute the tasks with a consideration for the skills and changing availability of each member of the team. On the other hand, you want to set clear priorities and stay within your timeboxing throughout the entire development process and not spend a lot of time on redrawing your plans in a very possible case of changing conditions and requirements.

Implementation path is the technique that allows you to consider all the above-mentioned factors and create a detailed plan which focuses on technical aspects and acts as a bridge between technical and functional project roadmaps. The implementation path defines project milestones and conditions that must be met at these milestones. It also outlines how the team composition will change throughout different stages of the project and reflects shifting needs for particular experts. The layered structure of the implementation path is made to be accessible to each team member, so that they have a clear grasp of their own user stories and their place and status in the general picture.

Working with the implementation path helps the team to have a bird’s eye view of the project development and planning, effectively reacting to changes in requirements or conditions, shifting the load and keeping the balance within milestones smoothly and without additional regulations. In many cases, the load distribution becomes so effective, it allows speeding up the development process in a given iteration.

2. The Principle of Cross-functionality

In a way, cross-functionality is a team feature that greatly complements the dynamic workload principle. A cross-functional team shifts workload more easily because of their versatility, and is able to form a stable union. In such an environment, team decision-making becomes easier and more reliable, the team becomes more self-sufficient, without the need of formal proposals to higher-management for many important decisions. This speeds up many business processes and makes the team much more flexible when it comes to reacting to changing conditions and requirements. This flexibility allows to accommodate for more impacting changes without having to change the goals, development scale or budgets too much.

But how to improve a team’s cross-functionality? Even if a team consists of members that bring together different perspectives and skill sets and is capable of innovative solutions, there are ways to boost cross-functionality. AI-driven tools can work with disparate data to create easy-to-understand materials that allow team members to quickly improve their expertise about adjacent fields and exercise critical thinking. AI tools can take on automating repetitive tasks, helping the team focus on more  strategic work and more complex problems. They can also propel collaboration and help provide access to diverse perspectives, thus enlarging the team’s outlook and improving cross-functionality. Careful selection of relevant AI tools for teamwork creates good alignment of the team efforts with project requirements and environments used.

3. The Principle of Innovative Estimation Methods

Estimation is a crucial part of workload planning and much depends on its accuracy and integrity. Human error is common in such calculations and it can have long-lasting consequences.  AI estimation tools allow you to streamline your work in resource allocation, calculation and validation of risks. AI-driven instruments take into account more factors and contexts, and can create simulations and optimization algorithms for more effective risk response plans and resource allocation that factor in more variables than human calculations.

When using AI tools to enhance your estimation efforts, it’s best to align your calculations with functional and non-functional project requirements and take into consideration the domain model complexity. It is also useful to use the entity-management approach when doing your estimations, and AI tools can help with that as well. Once you define entities that contribute to workload, be it skills, equipment, software, legal and regulatory issues, other resources, it becomes easier to estimate in terms of particular tasks, and identify potential bottlenecks. This ultimately contributes to a more flexible and dynamic workload management.

4. The Principle of Transparency

The name of this principle speaks for itself. It is essential that you maintain transparency in workflows and processes on every level and in every type of communication. Whether between the team members or between the team and the customer, communication should always be clear and transparent. It is important that concerns are shared openly and the team has access to stakeholders with as few intermediaries as possible in order to avoid any miscommunication. Goals and requirements, clearly communicated and agreed on between the team and stakeholders allow for a very accurate distribution of responsibilities. This empowers engineers for feature enhancements and improves the overall product vision, thus making the team and the stakeholders a cohesive unit.

At large, it means standardization. All terms and definitions across the project need to be consistent, goals and requirements should be expressed unambiguously, any double meanings should be avoided in all project documentation.This type of clarity helps the team and the customer to clearly distinguish and agree on core, additional and key features. It also allows to prioritize accordingly and establish all possible dependencies between the feature sets. What this results in is a balanced MVP with a solidly working combination of features and a clear vision of priorities and milestones for everyone involved. This way, both the team and the customer will have aligned expectations of the delivery process and reduce the number of blank spots in estimations.

5. The Principle of Minimized Communication

In my practice, if communication within the team and between the team and stakeholders is not regulated, it can quickly get out of control with a snowball effect and consume a lot of time and effort better spent elsewhere.  While some topics and activities are repeated in each cycle iteration, others may be spontaneous and lack guidelines, which can result in avoidable conflicts and the team squandering energy.

This is why I think it is important to formalize all workflows, introduce communication protocols for common situations and have guidelines for any information exchange. A good example is using a code style. Implementing a code style with specific tools like Prettier and ESLint helps everyone to be on the same page and have a very clear picture of code guidelines to which they can adhere. This can seriously cut down the amount of exhausting debates. It also helps with formative code review processes, getting the code style issue out of the picture entirely.

Another best practices item would be creating checklists and defined step-by-step procedures for all common activities. This also has the additional perk of reducing the amount of guidance and supervision junior team members need, and eases onboarding of any new team members thus mitigating many risks team fluidity can bring about. In the worst-case scenario, if an engineer does not adhere to a checklist or skips necessary steps that they believe they have already tried, troubleshooting can take days or even weeks. There is an excellent book called "The Checklist Manifesto" by Atul Gawande that provides valuable insights into implementing checklists when approaching complex tasks.

6. The Principle of Constant Learning

To reiterate my statement from the beginning of this article, I think a software project should be viewed as a dynamic, evolving entity. But the same must also be said about a good team. Team stagnation can be disastrous for any project, so team evolution within and outside the project is crucial if you want to keep your team challenged and motivated.

Aside from the obvious field of general skill improvement, one area where your team can expand their knowledge is their expertise in the project-related context. This benefits the team members as well as the project itself, as in-depth context knowledge allows the team to provide finer-tuned solutions and respond more precisely to user needs and pains.

In terms of practical application of this principle, there are several ways to enrich your team’s learning. Organizing workshops is one of them. Workshops create an excellent platform for free and live knowledge exchange and practice between subject matter experts, can focus on project-related tasks, and their brainstorming sessions can bring about new and elegant solutions. Participating in practical workshops also largely reduces the learning curve in workshop topics for team members who are less experienced in this topic, and boosts their confidence. Workshops can also become good team-building opportunities.

Skillset onboarding sessions become essential when integrating new team members and when a quick kick-off is expected of a new team member. These sessions help the new members to quickly align with the customer requirements and understand expectations related to communication, technical skills, and project involvement. Additionally, these sessions provide an opportunity for new team members to familiarize themselves with the project complexity and try out workflows and processes in a risk-free environment. This ensures that new team members can quickly catch up in their expected skill set and make immediate contributions to the project's success.

Practical Examples of the 6 Principles’ Application

I’d like to elaborate a little on the particular examples of when application of these principles helped me and my team to salvage projects that were in a bad state or on the brink of failure.

In one case the project had been ongoing for an impressive 1.5 years and was still far from completion. Additionally, the client's team had abandoned the project. This was a challenging situation that required unconventional and innovative solutions. The turning point came when we made the decision to completely redesign the product. Although this introduced an element of risk due to the replacement of the core, it also reduced overall complexity.

Introducing a clear implementation path with a dynamic team configuration in the timeline of clearly defined milestones allowed me and my small team to transform the trajectory of the project and deliver an MVP within 3 months from the start. Meticulous planning, precise execution, and experience were the key factors.

In another case, our expertise played a crucial role in turning around a challenging situation for a customer team struggling with integration tasks. We were able to polish user story status and estimations, including the technical roadmap, by implementing the transparency  and minimized communication principles. We established clear and open communication protocols between team members and stakeholders, ensuring accurate distribution of responsibilities and improved product vision.This improved task placement and tracking, benefiting all teams and team members and giving them a clear view of their workload. It is a reminder that progress comes from wise decisions and dedication. We are currently working on this project and it has greatly picked up the pace.

Conclusion

Today’s software development sphere is extremely fast-paced. In order to stay afloat, projects simply can’t afford the way of trial and error. Meticulous and  accurate planning reduces the risk of so many problems that it becomes an absolutely invaluable part of the software development cycle. Planning your workload will allow your development and QA teams to function in a resourceful mode, prevent your experts and team members from burnouts and create a good balance of challenge and motivation.

Applying these 6 principles in your practical work will help you have a clear picture of where you are resource-wise, task-wise and people-wise at any given point of your project's technical and functional roadmap. It will also help you be flexible in dealing with changes in conditions and requirements and accommodate them more easily and with fewer losses, thus sticking to your commitments with stakeholders and customers and delivering a reliable, expected quality product.