When it comes to the development environments, every single detail matters. Starting from budget planning and a careful approach to business requirements to pure development procedures – like regular quality assurance testing or prototyping.
These steps help a business to ensure that the digital solution they are building is delivered on time and meets the needs of a target user. As a CTO, it is your job to be aware of this, and also to push all your efforts in that direction.
Sometimes, the best practices like regular knowledge sharing between developers, documentation, or following these practices when it comes to building the architecture seem to be of no value for the business. In fact, it’s a misconception, because the success of a business hugely relies on the development processes.
Imagine that only one developer in a team knows how to handle some legacy system you cannot quickly remove from the project, and then this person leaves the company. It will result in allocating an additional workforce to figure out how to maintain it and resolve issues when they occur.
Without prior knowledge, it may take some time, and I haven’t yet mentioned the delays in the project delivery caused by scope changes and unplanned working time for learning.
That’s how knowledge sharing may become critical for a business to remain operations running as usual during the team changes and other force majeures.
It’s clear that the established process and adhering to these rules as well as setting the new ones are helpful to keep the team organized, so let’s dive deeper into the best development practices and their benefits from a business perspective.
Pre-project initiatives
Briefing the project and assessing its potential cost-value ratio can help you have a vision of the future project and understanding the preliminary scope of development. It includes the time frames required for completion, the number of involved people, and additional resources.
For some large-scale initiatives, an additional budget may be required for purchasing auxiliary tools, obtaining official certifications, or organizing training sessions and workshops to help the team.
If it’s not planned beforehand, it may happen that these spendings are not taken into account on the top-level budget forecast, and your team does not receive sufficient funding to deliver all the objectives that go into the scope.
So, the best practices in pre-project initiatives should include estimates of the delivery time, resources you need, approximate team dependencies, and demonstration of the business value of your project.
Let’s say you plan to do code refactoring. In this case, apart from describing the benefits for the dev team, highlight the reduced risks for business, such as the application integrity, increased stability, and reduced number of critical incidents that cause downtime for the end-users.
Proper organization of the planning process
Another practice to follow as a CTO is the planning algorithm. It includes dividing the project into several stages.
The first one includes formulating objectives and outlining business requirements with the detailed user stories description so that representatives of the developer team can check the feasibility, assess the risks from the technical side, and identify the blockers.
It’s done during the dedicated planning sessions with the records of the discussion. This way all the project stakeholders can be on the same side.
Then, this information – with the input from the dev team – is passed to a designer for creating design mockups. Once done, it’s time for the most interesting stage, i.e. the start of actual development with testing and releases.
Planning on lower levels like regular weekly grooming sessions is even more important as it allows to assess the sprint planned tasks vs. done, which helps to accurately measure the progress and be more precise in the estimations.
It may also happen that some of the team members will be doing tasks faster than initially specified. Taking this into account, it’s always advisable to keep the backlog organized by priority so that a person who managed to cope with planned tasks sooner may take a challenge and complete some of the unplanned tasks.
If there’s a hard deadline for delivering the software it’s worth keeping the calendar of team availability to plan the progress accordingly. This is something your team leader can do, and includes planned vacations, official days off, and setting some buffer for sick days or other unplanned leaves of core team members (especially when it goes about the architect and senior devs).
This allows having a real picture of the estimations and helps team members to be more organized when it comes to clarifying with colleagues and tech leads the best solution for completing the task.
Cost-time optimizations
To achieve maximum effectiveness, it’s required to assess the current processes and seek their optimization. When there’s a possibility to optimize processes, any slightest chance should be used.
On the surface, these are templates for tasks in the project management tool, because it helps to avoid cases when some important information or field is missing, which may block the development.
Another required step in this direction is performing the audit of meetings. These are among the main pain points for the dev team, as the several hours per week spent on meetings means less time to code. For sure, meetings are important, but it’s possible to optimize them as well. Here’s how it can be done:
- Reducing the number of daily team meetings to 2-3 times per week, so that every team member can share their progress
- Reducing the number of participants for irregular meetings involving only team members that have a direct impact on a situation ( i.e. there will be no use of involving junior specialists for discussing the changes in the architecture, or inviting front-end specialists for back-end discussions unless there are dependencies)
- Having a clear agenda for a meeting and compiling a list of questions that require investigation beforehand, so that situations, when another meeting after the initial gathering is required, are set to a minimum.
- Keeping meeting recordings to refer to them later if need be
- Sending meeting minutes in the written form to allow all interested parties to get acquainted with the summary and taken decisions
Another aspect of improving the cost-time ratio is the automation of routine tasks like quality assurance testing to balance the time and expense. This way, the expenses spent on additional software and external expertise are compensated by the possibility to reuse the automation scripts.
In the long run, it brings more effective use of human effort. The latter can be redirected to other important tasks which cannot be automated like ad-hock testing, code security reviews, etc. Time to spot and fix bugs are also minimized, as automation helps to detect and fix them faster.
Aligning software with requirements
The main aim of the development process is to deliver pieces of software that are corresponding to the business requirements. That’s why before any task related to development is moved from “to do” status to “in progress”, it’s critical that the developer working properly understands what needs to be done.
That’s why it’s better for Project Managers and Tech Leads inside your development team to minimize the ambiguity of requirements. If the slightest nuance is not clear, it’s always worth initiating additional discussions to receive the mutual agreements.
Communication with stakeholders on the task progress, writing user flows and scenarios, and user acceptance testing help development teams to ensure that their scripts work as initially planned.
Building a viable product
Last but not least goes the building of a minimum viable product. It means providing a user with the possibility to resolve their issues with the limited software functionality and help to prove the hypothesis that there’s a demand for such a product. This way, later on you can add some advanced features.
That’s why it’s important to properly align the expectations between the parties. The sooner the viable product can be tested by the target user, the better because this way your development team will be able to understand what features to prioritize next, and what improvements can wait in the backlog for the next iterations.
This viability also includes the optimal choice of a technology stack and auxiliary tools that will be possible to maintain after the release and scale the functions. e.g. if you know that the version of the software or platform used on the project will reach EOL soon, it’s worth thinking about alternatives beforehand.
It also includes the selection of a language, acceptable frameworks, and compatibility with other components that may already be in use.
Conclusions
Following the best development practices is equally valid from a business perspective as well as from the technology side.
With their help, it’s possible to maintain the commitments and adhere to the set deadlines. For developer teams, it means a better organization of the working process on all the stages, including forwarding projects from one team to another, putting them on hold, and resuming certain initiatives.
It’s always easier to focus on delivering software of supreme quality when all the flows are properly documented and responsibilities divided. So, when these practices are brought to the project, teams can optimize their processes and deliver valuable digital products your users will love and actively use.
