How to build a professional development team in a few steps quickly and effectively – a case study
The current trends in developing and supplying individual software for companies have significantly moved towards the model based on outsourcing. This is a very convenient solution, as the customer (the ordering company) does not have to support the whole team of IT engineers. They can use an IT outsourcing service instead and hire external specialists and experts who will deliver them a ready product in a professional manner. This solution eliminates the problem of spending money on internal software engineers, testers, analysts or even IT managers. This is a convenient and flexible approach. The benefits are clear, which is proven by the constantly growing demand for outsourcing of IT specialists as well as by newly established software houses.
What if we do it otherwise than everyone else? Does the creation of a department responsible for software development in a non-IT company make sense and have a chance for success? Possibly, as there can always be qualified people hired who will develop all the processes and create a team. OK, let us set the bar higher now. What if we decide to create a team based entirely on staff that know very well the business of their company, but have never dealt with programming and IT sector before? Additionally, the goal is to create from scratch and deliver a shop floor management system within a few months. Does it sound like a mad plan? Perhaps, but what I want to demonstrate in this article is that sometimes there is a method in such madness. I invite you to read the case study of a company that decided to go that way and train their own IT development team.
Let us start from the customer’s profile introduction. It is a large organisation that operates in automotive industry and has got its branches in more than ten countries. One of its major operation areas is manufacturing of car equipment. The company has introduced a system for production monitoring, control and planning in one of its branches. It is a system written and maintained by one (!) of employees – a self-taught enthusiast of software development. The system works quite well, although it has been written without the use of any architectural patterns, good programming practices or even a version control system! In order to allow for the system’s development and implementation in another manufacturing plants, it had to be written all over again in a professional manner with the use of the best techniques and tools. The customer applied for such service to Transition Technologies PSC. In about 8 months we helped them achieve the goal to write a relevant system and transfer the know-how concerning the whole software development process. It is worth emphasising nearly all the work with the customer was carried out remotely. In the further part of the article I will focus on the description of how it was possible to train four developers from a practically zero level to strong juniors and, in case of one person, even to a regular developer.
Step 1 – trainings and workshops
The first, obvious step was to learn the necessary basics to start the work. The project was supposed to be created with the use of the .NET Core technology, Jira was selected for the project management and the source code was to be stored and managed by Bitbucket. Jenkins was suggested to ensure Continuous Integration. In the first place, we started a series of trainings covering the subjects mentioned above. During a week’s time we provided a substantial dose of knowledge through conducting the following trainings:
- Jira user training,
- Git developer training,
- Bitbucket developer training,
- Visual Studio training,
- Development process workshop,
- Jenkins developer training.
At a later stage of the project, every 2 months we organized 2-3-day workshops on site in the client’s office. It was the time when we could precisely explain and train the participants of the project on the particular subject needed during development process. It is much more convenient to answer all the bothering questions and provide the necessary information during a face to face meeting when an overhead projector or a whiteboard is available, so certain problems can be illustrated and analysed.
Step 2 – controlling, mentoring, consulting
As in every project, sometimes it was necessary to analyse a difficult issue and find a good way to handle it. Such matters were usually planned as a subject to discuss during the on-site workshops at the customer’s. We were able to sit down together in one room and brainstorm to come up with a draft and then the details of the solution. It was also extremely encouraging and developing for the team. It taught them how to look for solutions for essential and complex business requirements, taking into account efficiency, scalability and security of the whole system. During the work on this process, they learnt to focus not only on the problem discussed, but also on the analysis of its influence on the system as a whole.
Such work was greatly beneficial. The progress was visible for example on Sprint Retrospective meetings. The developers shared the new elements they learnt in the given sprint. In addition, it was visible how the following proposals of the project improvements from our ‘lessons learned’ document were implemented and what influence they had on the work quality and efficiency measured by burndown and velocity reports. We could also observe the number of code review remarks was dropping and pull requests were merged faster.
Step 3 – preparation for independent work
The last step was to prepare the team members for work as independent developers who know, understand and use the basic programming techniques and models in .NET. They should be able to handle most of the typical programming problems (or find the relevant tools for this purpose). It is also important that they are able to identify errors in another developer’s code upon the code review.
They have reached this level step by step. First, the moment a developer made fewer and fewer major errors, he noticed them and needed help only when dealing with more difficult tasks, he was promoted to a reviewer role. From that point he was allowed to do code reviews for others and accept pull requests, although they required an extra verification from another reviewer (so called double check). This taught him a different point of view, as from then on not only his code was subject to verification, but he had a chance to take a critical look at the code written by the team and report other developers’ errors. Moreover, he had an opportunity to look at the pull request again during the so called double check and see what other possible errors were reported by another reviewer which he did not notice himself. The code evaluation was easier thanks to the developer guide document prepared earlier, pointing out the principles of the correct development in a project. The moment the developer accomplished a considerable number of code reviews and their quality was satisfying, he became an independent reviewer. From that moment, his acceptance of a pull request resulted in merging it to the target branch.
This way we got to the point where the team reached the level of strong junior developers and in the case of at least one of them it was the regular developer level. That is why the team no longer required constant mentoring, control and learning. It was able to develop on its own. In case of serious problems that might require more knowledge and experience to be solved, the customer has left an optional short training and consultation in the contract.
Has the experiment of building a team on unexperienced people without the necessary programming knowledge been successful? Yes, indeed! The project has been completed in accordance to the earlier assumptions. It passed the first security tests quite well during which only one serious incident was detected. The moment our cooperation and my role in the project was accomplished, the software was ready for the production deployment. Obviously, a complete evaluation of the project and whether it is successful or not will only be possible after certain amount of time since it starts working on in production. I would like to point out, however, the fact the company gained the competences and know-how of software development was as important as the completion of the project itself. As a result, the customer can create and develop these competences through extending his team with another specialists – this time not only developers, but also testers, analysts and devops engineers.