Hey, guys. We thought we might want to share with you our approach to the development process. We find it pretty noteworthy. Keep reading, and we’re sure you’ll think that too. :)
In the first introductory part of the story, we'll talk about the essence of the principle itself. In the second part, we'll cover specialization and training in the development department, and in the third part, we'll address the main pros and cons of our approach.
Follow us on Facebook to get the updates. ;)
What is interchangeability
The essence
The principle of developers interchangeability means that the manager pass any task of the project to any developer, even in the midst of the project.
To succeed, one needs to consider the internal time that is about to be spent on immersing in a specific project and code, as well as the risks of standing idle and failing the external deadlines. By comparing internal costs with external risks, and with the help of common sense and experience, we find a common denominator and then make a decision on how to distribute or pass around the tasks.
Shaping project teams
The interchangeability principle means that several developers get involved in a number of different projects in various combinations.
In each project, the team is formed dynamically, which means that the team’s cast might change. If necessary, we can engage more developers in an urgent or highly important project. Of course, it means that we release them from other projects. However, not from all projects at once, as the developer never works on one single thing.
Sometimes the team can change completely. Sure, it's unlikely to happen on a project with a rich history, but it definitely may occur in the process of implementing new products and features.
Ok, we'll share a secret: it happens with old projects as well. It's all about balancing costs and risks.
Key project developer
Our approach doesn't imply that there is no key developer responsible for the project - the one that makes key decisions in terms of software design. If we take a closer look, we'll see that the key developer is present in every project, but in our case, he or she can switch roles with time.
While implementing a certain functionality, it's the lead developer who is immersed in the project deep enough so that he can make appropriate decisions on it. If the next functional block is highly different, the lead developer is likely to be replaced, though it's not obligatory.
Making the best architectural decisions and designing the code based on the task is an important right and duty of a competent developer. No matter how awesome the design is, you can't get away from it. And it's a good thing.
Our approach suggests reducing the risks related to such decisions through preliminary business and tech design, as well as through decomposition and a number of discussions.
Project Team Management
The project team is managed by a project manager with the help of an analyst-designer and a technical director. Usually, the analyst-designer is the one who's most aware of the project details and is permanently immersed in their projects. The project manager always knows what is going on and keeps in touch with everyone involved.
Such coordinated management ensures an adequate transition of developers among the projects. It also helps to pass the knowledge and guarantees that the tasks are duly set. Yet, the developers themselves have gotten used to it, and they know that at any time a colleague might need some clarification on the project. Our colleagues have become pretty good at talking to each other.
What boosted this approach and how it developed
Small projects, high mobility of deadlines and downtime
We began our journey with relatively small projects. Sometimes, tasks got shuffled like a deck of cards: someone asked to clarify something and had to wait for an answer, a priority got suddenly heightened, planned deadlines got jeopardized. As a result, it was quite difficult to plan the internal workload of the developers.
We were looking for a way out and found it - among other things - in increasing our own flexibility. This is how the developers interchangeability principle was born.
Medium projects mixed with small ones. Importance of meeting external deadlines
We were a fast developing company, as they say. In reality, we just grew up to serious, solid projects. It's not that there were huge budgets or major innovations right from the start, but we had to do some tricky work impeccably from the technical point of view.
Therefore we had projects with different planning horizons. Apart from internal flexibility, it was important to meet the deadlines, although the deadlines were quite diverse. The interchangeability model got a second major limitation.
Large projects mixed with medium and small ones
In the meantime, the year 2019 has come. Now we work with projects of various scales, and the scales are growing. However, we do not exclude small projects, especially if the task is exciting and the relationship with a particular client has a long-term perspective. We are interested in building long-term relationships with client companies because the implementation of Bitrix24 is never a quick process.
Realistically, one can talk about the results of Bitrix24 implementation at least a year after the main functionality was put into action. If the functionality is standard, the year is counted starting from the point when all required settings were made. If it was customized, the year is counted starting from the implementation of the release version of customized functionality. And one need to make sure that the implementation was held correctly: Bitrix24 was carefully integrated into the company's business processes, and the employees were trained to use it before the official launch.
Mid-term planning horizon and long backlog
While planning a large project, one needs to know how much resources they have at least in mid-term horizon right from the start. And to find out what they are, one needs to understand how much and exactly which resources a large project will take. Thus, the planning process depends on the resource load, and the load depends on planning. At the same time, the data for planning and load changes all the time.
Therefore our model just as Jörmungandr bit its tail and locked itself. We had to find a key to managing the system with interdependent unknowns, and we did come up with one - prioritization.
And that's how we roll
Prioritize
The main metric of our work right now is priorities in the widest meaning.
One can say that our model based on the developers interchangeability principle works as a closed loop that receives the current of tasks. And the current of tasks is managed by the priorities that are beyond the scope of the system.
Priorities are set by business and corrected by experience and external information. It all changes constantly, and we are always ready to react properly.
Since we manage our priorities by ourselves and based on all available information, we're not constrained by the circumstances, and we do not perceive changes as an abnormal situation.
Task formulation
The main task of analyst-designer and project manager is to lead a client from the idea stage of the project up till the stage of acceptance of the finished project by shaping and delivering on expectations of all participants of the process, and those of developers as well, which is quite important.
Both analyst-designer and project manager are responsible for setting the task with sufficient details. We tend to set tasks as fully described as possible and give developers all necessary information including the overview of the project and a place of the task in it. At the same time, where it's possible, we tend to set tasks without particular reference to some specific technologies - languages, frameworks, implementation options.
Then we answer all questions coming from the developers and make timely changes due to the lack of information in the implementation plan. It can be a lag of response from the client's side, as well as a lag of task clarification given by the designer and a lag of task assessment due to various clarifications.
In the end - in fact, at the very beginning - we must give the developer clear acceptance criteria. At this stage, we implement acceptance basing on user stories in addition to functional descriptions, prototypes, schemes, and other artifacts.
Putting together puzzle pieces and testing it
Project manager and analyst-designer ensure project manageability. In this regard, they need to decompose the project correctly and then discuss the final decomposition and assessment with future performers.
In a climate of dynamic teams composition, we need to take into account the time needed to put together the puzzle that consists of various tasks of different developers, and deviations in the assessment from different performers. To simplify the work with assessments coming from various performers, we have developed a standard for assessing tasks, and now we're putting it to practice.
A tester, who is supervised by the project manager, has to take into consideration the decomposition details too. Developers interchangeability affects the testing process as well. There are some special aspects of how each developer executes tasks and writes code, as well as circumstances that accompanied tasks changing or redistributing.
Ask the developer
We are paying more and more attention to immersing developers in projects at the concept stage, which is the stage of shaping the business framework of the project and planning its implementation. It enhances developers engagement and personal professional motivation. Although we must admit, they are not fond of this kind of work, i.e. reading and discussing documents that are not followed by the development right away.
To facilitate this process, we got used to compiling brief documents that describe the essence, purpose, and technology of the project. Such documents can significantly vary in format from project to project, but the purpose remains the same - to be a unified entry point of understanding and discussing the project for everybody, including developers.
Immersing developers into the project at even earlier stages allows us to use all possible opportunities to simplify and reduce the upcoming development. To be honest, engaging developers long before the development stage significantly speeds up the process.
Unexpected, right? But the time is going to be spent anyway. If not on decisions before the start, then on decisions in the middle of the development process, and these decisions are going to be much more difficult. No one knows what time costs the changes in the midst of the development process can entail.
We prefer to spend this time beforehand and keep projects manageable.
What we get
We have been practicing this approach for quite a while now and have no intention to abandon it. The principle of developers interchangeability makes us flexible on organizational and technological terms.
Organizational flexibility
Organizational flexibility means that we rarely find ourselves facing insurmountable internal obstacles. We can always or almost always find a solution. The main thing is to take advantage of the opportunities offered by prioritization.
Instead of seeking external opportunities for a maneuver, we create internal opportunities and are incited to use it. Of course, we use external opportunities as well, but we do it carefully and in a selective manner.
Technological flexibility
Technological flexibility means that we can choose stacks and implementation methodologies for each particular project. It’s just partly that we depend on the pool of already implemented projects.
Is someone ready to work on Agile? Great, we're in - it gives good short-term predictability of the load and prompt feedback from the client. Does someone agree only to a standard waterfall or maybe even just to a tender? No problem, we will create an implementation scheme that combines a fair budget assessment, stage-by-stage approach to implementation, feasible flexibility, and common sense. We carry out even bolder experiments while picking ways to implement internal projects.
Instead of offering a standardized scheme of work to all customers, we are eager to frame a unique scheme for each project or even for each project stage. In the context of our specialization tied with Bitrix24, it does not entail any additional risks or costs.
Living principle
Of course, changes happen all the time. But we strive to be constructive: we keep an eye on the implementation of internal changes; remove what does not work; come up with new solutions for pressing issues.
Our goal is to ensure that a proper developer has everything he or she needs to efficiently work on the implementation of a task that is clear for everybody and has plain acceptance criteria.
We believe the goal is quite realistic. Mostly, we succeed. :)
In the next part of the article, read about how we arrange specialization, training and empower the spirit of cooperation among developers.
