Working as a team to deliver software

Team organisation

In order to build a successful web app, you need to have team representation from every discipline. These disciplines are:

  • Information Architecture
  • Design
  • Back end
  • Front end
  • QA

This list is largely representative of the functions needed to produce any other piece of software (mobile app, desktop app, game), which can be augmented or substituted with additional members as need be.

Incidentally, this order is approximately the order in which you need to tackle a piece of functionality in order to complete it.

The importance of role separation – even in small teams

While it’s possible to have a single person be responsible for more than one of these disciplines, I would still recommend they are treated as separate and approached as different tasks. This prevents you from needlessly switching between multiple jobs, damaging your efficiency. It also means you’re 100% focussed on the solution at hand, which should yield better results.

By breaking work down into component disciplines, you can start to simplify the load. This prevents generating or tackling too much work at once (which is harder to then analyse and digest by the team). You can also start to assign jobs to different people. By splitting the job out between multiple team members we can increase our pace, but at the expense of continuity of information. This sounds obvious, but if you’ve spent a year working on a project in a closed room on your own, then you really need to stop and readjust your way of thinking to incorporate the concept of ‘team’.

The process I’m trying to outline here is designed to minimise the extra overhead incurred from using multiple team members on a project.


Aside from actually delivering your software, continuity of information should be the top priority for your team.

Your team is dependent on all other members in order to deliver (as the array of disciplines should indicate; you can’t do front end without design, for example). Equally, should a team member fall sick or leave the project, then the others will know what they were working on and be at least able to account for what part of the puzzle is missing (even if they can’t step in to their role personally, they could impart knowledge to a new-joiner).

Ideally, your team should communicate on a daily basis in a stand-up or scrum. In these meetings each member says 3 things :
– what they did yesterday
– what they’re doing today
– any issues, impediments or blockers to what they’re doing that another team member may be able to alleviate.

Talentomic is being co-developed by myself and another developer based in Helsinki, which makes it a great example of the need for constant communication. As progress happens around other commitments and work, we both have a different pace of working – I may have 4 hours free in a given week, whereas my counterpart may have 30. It’s thus unproductive for him to be waiting for me to complete something, or if he is dependent on me to deliver something, knowing it’s precise status helps plan his work and keep the project moving.

Once your team knows who they are and what they’re trying to achieve, it’s time to start breaking down the project into bite-size chunks, which will be the subject of my next post.

2 thoughts on “Working as a team to deliver software

Leave a Reply

Your email address will not be published. Required fields are marked *