Could this concept also apply to development work?
Let’s talk about the creation of a workflow which saw the collaboration of two teams more than 10,000 kilometres apart.
When a multinational company in the finance/ insurance sector entrusts the designing of innovative digital services to many individuals, different areas find themselves
collaborating with each other. The participants involved differ not only in skill and roles, but can also be located at great distances from each other. Because of this, a net of suppliers searching all corners of the globe is created in order to maximise competitiveness, in terms of quality, use of resources and attention to the final product.
In this case the international team got involved in developing an application, the purpose of which was to take out insurance policies in a safe and secure way, following the client from the collection of personal data up until the signing.
In order to manage the collaboration in the best possible way, it is fundamental to build an ad hoc work method, even before development. Antreem, in this dynamic, in addition to dealing with consultation and research for the best solutions to develop, is capable ofsetting up a tailor-made work management flow.
Obviously, there are different challenges to deal with when colleagues are far away. From the immediate language barrier to the problem of different time zones: in order to
work well it is necessary to structure the workflow extremely well, with the aim of avoiding problems in the development stage, follow-up or production.
For this reason, a cycle working pattern based on the quality control of every single step of the development has been designed.
The cycle starts with the development, immediately followed by the “4eye” control : this is the first step of quality control that is performed. To be precise, it is a face to face with the developer and a Quality assurance manager who usually, through the use of VOIP applications, makes sure that the application behaves in the way intended. If problems of any type arise, (relating to developments just performed, or accidental regressions), these two steps repeat until things start working as they should.
At the end of the development cycle,the so-called “Code Freeze” is performed: a sorta of check-point, where the application is frozen in its current state. It is then that the QA team and client perform in-depth, well-rounded tests to verify the complete function of the application and, if necessary, make note of any eventual defects which may not have been detected in the preceding steps.
Once complete the release of the new version of the app, the new development phase starts over.
Undoubtedly this method requires greater effort in terms of time (especially in the initial phases), but it has an enormous advantage which it repays generously: it constantly
monitors the quality of the project and respects the requests of the client. Through special tools it is indeed possible to check how often the “4eye” controls fail, how many
defects are detected in an advanced cycle etc… With similar benchmarks it is possible to obtain graphs that evaluate the quality of the projects over time: therefore a if the
objective is to have consistently decreasing number of defects in the project, this way is highly recommended.
Especially when colleagues aren’t sitting nearby and it would be difficult to do this type of monitoring in another way.