Services

More than half of our customers have outsourced before and previously failed. We don’t cover up or underestimate the difficulties of software project or distributed teams. From time to time we also fail. But we believe that we try to avoid some common mistakes : ) TEO partnered in the 5-year research project 2012-16. “Next Generation Technologies and Processes for Global Software Development” along with IT University and Copenhagen Business School from Denmark. www.nexgsd.org

No doubt that this is on top of the list. Code is our core delivery. In most situations, TEO develops custom software solutions for its customers. Hence, we ask you to assist us in checking the quality of code and quality of the architecture of the solution. Open the hood and do code reviews often in the initial phase and regularly hereafter. Hereby we get the base right and develop in the right direction from the early start. Moreover, your benefit as a customer is that you always have an insight of what and how the code base is. Hence, knowledge is transferred back to your organization about the details of the solution.

Second, the quality of the product is the quality of collaboration. Teams don’t build themselves, co-located and remote alike. Good performance requires social engagement with your team fellows. We sometimes confuse higher education to mean better social skills. Take some time to introduce yourself to each other. Know the basics, strengths, and responsibilities of each other. The more you know the better the team performance is. Rebuild when people leave or join the team. In our experience, remote teams fail on projects not due to competencies, project specifications, processes, or cultural differences, but mainly because of a lack of social skills in the team.

Seeing is believing–and we usually know what is wrong when we see it. Don’t rely on project plans and mockups. See the progress, see the code work, and comment on it frequently. Share a screen and demo the current state of the development on weekly basis at least. Even if it is not near completion or only small features are added. This gives the team the understanding of the progress of the project as a single point of truth and enables everyone to give quick feedback in case of changes etc. rather than an exchange of lengthy documents.

Remote teams suffer a sense of urgency contrary to co-located teams. Immediate face-to-face interactions get first priority. And your boss may ask you to do other tasks as he/she doesn’t see the persons depending on you in the room or at the lunch table. Make your commitment and allocation to the project clear with your organization. Answer all queries from your team members within 24h, but the faster the better. We have 4-6 hours of time overlap which can be positively availed. As a customer and manager, e.g. project manager or product owner block time slots in your calendar to be available to the team. Also, keep a 1-month backlog visible to the team to avoid loss of productivity and frequent queries.

Most software developers like to concentrate on their primary job -programming. Some don’t like to talk much. But talking and communication in the team are essential to good project output. If the email is getting long drop it and do a voice call instead. Time to time meetings can be skipped, but in general, even if you don’t think there is anything to talk about force the meeting and you will find that something useful surfaced during the discussions or demo. You must at least schedule recurring weekly big meetings in the project team and daily scrum meetings in the development team.

Most small and medium-size businesses don’t want to spend resources on extensive requirements specifications and documentation. Do the high-level requirements and let the developers in the TEOs team do a detailed breakdown, estimation, and planning. This is why TEO doesn’t offer developers but ”development teams”. This has two benefits: Customer spends less time while the understanding and ownership is transferred to the people who shall actually do the job. Agreed ”keep-alive” documentation has to be planned into dedicated sprints serving this purpose only. During meetings always share a screen and write the Decisions of Meeting (short 1 liners) while everyone sees it and emails afterward.

Today most software projects subscribe to the SCRUM framework. Decide the tools to use, the process, and the practices to apply in your project. Not everyone does SCRUM in the same way. Don’t hesitate to define your own flavor and add special practices that you have a good experience with. Rotate responsibilities in the team to get a robust team delivery and process orientation. New team members get productive faster by a brief but formal process description. When dealing with complex industries a Project Dictionary defining all special terms is also a very useful tool and practice.