As a developer, you have most likely faced a situation where you had to dramatically accelerate the work speed in order to complete the project on time, risking professional burnout. The truth is that nowadays the ever-growing development speed has become a topical issue not only for game dev and startups but also for enterprise solutions.
Indeed, in the World Quality Report 2020-21, Capgemini states that about 70% of development teams work under pressure, deploying products daily and hourly. But how can this be done with no harm to quality?
That’s precisely what I’ll show you in this post, so that you can be faster than your competitors without sacrificing quality, all while you avoid professional burnout.
Some Words on Development Speed
In software development, speed is not a simple concept; after all, the definition of speed itself may vary depending on the perspective.
For instance, with Agile development, some experts describe the concept of speed in terms of various patterns. On a basic level, these patterns are represented by such units as a sprint (extreme and moderate), a marathon, and an interval. Let's look at each of these speed patterns in more detail—eventually this will help you choose the one that is most relevant to your specific needs.
Extreme sprint is a speed pattern that best suits some critical situations—for instance, when there is quality loss, unhappy customers, or similar things requiring immediate attention. When working in the extreme sprint, the team puts aside all additional tasks and reduces the work in progress (WIP) for each of the development stages. This helps to lower multitasking and focus on the specific problem, thus finding the ways to resolve or mitigate it.
The main disadvantage of the extreme sprint mode is that it is too difficult to implement and maintain continuously. It’s like a demolition derby with developers working extremely long shifts (over 10 hours), which may take a toll on their productivity and health, cause them to experience daily burnout, and consequently, reduce the quality of their work.
Such an approach to speed can hardly be a long-term strategy in any company, because it makes the development process too unpredictable and unreliable.
The moderate sprint is another modification of the sprint pattern. Despite its name, it nonetheless remains dangerous and unstable regarding project management. Here, we won’t see extreme overwork. Developers work regular eight-hour shifts and try to use their productivity to the fullest with minimal disruptions. In other words, coding is the only thing they do to increase work production.
However, over time this may also become a problem. The reason is that in such working conditions, when the developers’ focus is limited only to coding, productivity inevitably drops, and no one may even notice that something is wrong.
This lack of reflection is due to the team members working like hamsters in a wheel and doing the same routine tasks day after day. At a certain point, team members begin to burn out and work unenthusiastically, which inevitably affects the quantity and quality of the performed tasks.
Unfortunately, teams can work in such an ineffective mode for a very long time; in the long run, it may dramatically reduce the ROI of the entire software development project. After all, it may take up to several months or even years just to identify and acknowledge the problem.
As a result, though moderate sprints may still be effective if they are used in just a pinch, they are not a sustainable long-term strategy.
Unlike sprint modes with their extremes, the marathon speed pattern relies on evenness and endurance for the sake of long-term sustainability. The key idea is to balance between high productivity and the highest speed possible without compromising developer creativity and morale.
In this speed mode, teams work regular shifts and have time to solve complex tasks—or just stop and think. Is it an ideal speed pattern? It is. Although it can hardly ever be found in real-life practice.
Be as it may, in such a relaxed mode, the risk of being outperformed by competitors runs high. After all, while your teams are spending time planning, hypothesizing, or meeting, your competitors release new features or releases, attract new users, and increase profits.
To mitigate the collective downsides of the above speed patterns, we can make the more effective and logical choice—to utilize the interval mode, which combines all patterns described above.
Intervals as an Optimum
Don’t limit the team to a certain pace, but instead make use of the best features of all the speed patterns. The interval speed mode makes use of sprints and marathon runs with regard to the team’s priorities and challenges at a given project stage.
Given all of the above points on patterns, intervals can be one of the most optimal speed modes, regardless of the scale and complexity of your software development process.
Here is an example of a potential combination of several speed modes within one interval. These sprints and marathons should follow each other, with the cycle ideally repeating over and over again:
- A speedy sprint. In this mode, the team performs WIP and puts all additional activities—such as meetings, learning sessions, or company events—on hold. They fully concentrate on delivering value: coding, QA, creating documentation, and deploying. This sprint duration is about a month. Some experts would recommend closing it up with a period of self-reflection and relaxation—for instance, you can spend a week for experience sharing and planning for future activities.
- A mindful marathon. When a marathon follows a sprint, the development pace is higher than in a regular marathon. That is the time to code calmly, reduce tech debt, learn new skills, or polish the existing ones. This period lasts for about three months. And then another sprint comes.
Alternating between sprints and marathons, the team can speed up the development process, alleviating the negative effects of the two approaches. Besides, unlike sprint and marathon modes, intervals extend to all project teams, not only developers. Potentially, this can help you improve employee communication and thus establish a more cohesive and synchronized software development process.
If you want to make your development even more productive, check out the books Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin and Agile Estimating and Planning by Mike Cohn—they will provide you with specific recommendations and the most effective approaches to Agile development (and continuing the interval conversation in more depth).
Regardless of the scale of your particular project, as well as the development model and speed modes you prefer, software development always remains a complex combination of interconnected tasks, ranging from requirement gathering to software testing and post-release support.
To optimize the whole development process, teams use DevOps and continuous testing, specific practices centered on fast development, product evaluation all through the delivery pipeline, and rapid cross-team feedback.
However, restructuring the work amidst a project is a complex matter. That is why it makes sense to recur to external help—DevOps consulting and continuous testing services to split the implementation activities into small parts while paying due attention to engineering teams collaboration. Qualified vendors have well-established approaches, experience in DevOps adoption, and risk management.
Besides, under their guidance in terms of industries, methodologies, and the object of implementation, the team can dive into the process and build a maturity model for continuous testing that focuses on the business risks right from the early project stages. Ultimately, this can help you put developers into a sustainable interval mode that will be beneficial in both the short and long term.
Time to Pick Your Speed
Speeding up the development process is a complex matter that has become an eternal challenge in software development. After all, you need to not only write quality code and achieve the project’s business goals, but also be faster than your competitors. Although there is no one-size-fits-all advice, software development specialists may offer a range of tips that can help you mitigate the difficulties.
As such, it is best to alternate between sprint and marathon speed schemes to take advantage of the benefits that the two approaches offer, namely minimal downtime and long-term sustainability.
This way, you can leverage the benefits the two approaches offer—minimal work disruption and long-term sustainability. When used one after another, both these approaches allow the team to reach the balance of optimal speed and endurance in the long term.