td-berlin Tech Blog

Trommsdorff+Drüner’s (t+d) first experience with remote work took place when we opened our office in Bejing. One would assume that this first wave of remote working culture prepared t+d to become what it is today in terms of remotely centered work. However, this long distance expansion of t+d did not really influence the daily business in our Berlin office too much (and vice versa) simply because the distance was too long and the dependencies between work in Bejing and Berlin were not that strong.

The second remote wave within t+d was of contrary nature. Our development team was and is growing because of an increasing number of projects along with a growing core of product features. Very soon it became obvious that our search for appropriate team members could not be limited to Berlin and Germany only. Thus we were looking for good RoR and JS developers in neighbouring countries. As time passed, our team grew to 13 highly skilled developers working from three different countries, with 5 different nationalities and one common experience at t+d. With every new team member, may it be a local or a remote, t+d tailored its work processes in the IT department to an extent that aims to produce maximum possible satisfaction for each individual person in the team. One of the keys to achieve this is t+d’s open and agile mindset when it comes to processes and tools. There are no rigid structures in and around the development teams that need to be obeyed just because those rules and structures have been there for the previous years. We highly pursue ‘trial and error’ in liaison with ‘take it or leave it’. We believe in team spirit the same way like we do in collaborative choices when we have to decide about tools and processes that define our daily workflows. Eventually, pending doubts could be countered with reliable velocities and great sprint results. Within our teams and projects we gained a level of ambidexterity that enables us to plan with quarters and deliver in weeks. At the same time Scrum helped us to prevent the well-known “small” additional tasks from being added to the scheduled workload of the teams. To achieve this we had to define new processes and evolve with them over time. At the same time one cannot create a remotely centered working culture solely by defining any order of working steps. The key is and will always be the persons in the teams and the constitution of their individual preferencese, experiences and ideas in combination with the right tools used in the right way.

/giphy Communication

Our communication tool of choice was an evolution from Skype, via a short trip to Hipchat and finally leading us to Slack. We are not the only company which discovered the extraordinary possibilities that Slack offers with regard to third party tool integrations and user experience. Slackbot and the Giphy integration opened up a huge creative space for all of us in the teams. The freedom in communication is not only funny, even (or especially?) when Giphy seriously fails from time to time, but it also motivates everybody in the team to participate in channels and discussions. Not only does it serve communicative entertainment, but also it allows our team to integrate supportive notifications like deployment and provisioning stats, DataDog alerts, Sentry notifications and much more. With the opportunity to combine those individual benefits within a communication tool, Slack became a big pillar of our working culture. As one can learn from the previous line this working culture is not only about productivity but also a lot about fun while being productive.

Trellorganization of work

The second tool that we use to make our working culture remote friendly is Trello. Trello offers a really nice and handy way of organizing tasks and user stories as they are defined in Scrum. Users can create lanes for specific statuses of tasks and manage product backlogs in a separate board while the team has full control over its sprint backlog board. It was obvious from the beginning that we could not rely on post-its on one of our office walls as the synchronization would have generated too much overhead for our remote colleagues. Trello appeared to be a nice digital substitute for post-its. Beyond this we even use Trello to do all(!) our Scrum appointments. It even makes the meetings more fun. For instance in retrospective we can leverage pictures to talk about experiences of the previous sprint or we can attach screenshots to tickets very fast with easy drag and drop functionalities. What Trello is lacking regarding to statistics we managed to catch up on by creating our own statistics based on burndown charts with Google Spreadsheets. This way we have an overview of numerous sprints and can work with average velocities during planning.

Let’s hangout

So far I’ve mentioned the tools that we use for communication and workflow management, but there is nothing that can substitute seeing the people who you are working with. Since this is rarely possible in a remote working setup we started from day 1 with using video conferencing tools. Initially our choice was Skype but soon we swtiched to Google Hangouts. Regardless the connection issues that we had, Hangouts offers more options for engagement. A hangout can be started straight out of Slack by typing /hangout so there is no need to start an additional application. Also hangout offers engaging special effects that make the team laugh from time to time which is an unvaluable capability when it comes to meetings as all of us know. With hangout team members see each other in the morning during standup and during all other Scrum appointments (planning, refinement, review, retrospective). As a positive side effect the ease of starting a video conference out of slack not seldom results in short conversations between team members, because usually it is quicker and involves less typing effort if one has a specific quesiton. In addition to the workflow management, this “face to face” communication fosters the remotely centered working culture that we established in t+d.

GitHub to rule it all

It’s probably not surprising that the next member of our stack is GitHub. The perfect tool for collaborative management and development of software. It allows our team members to work on the same code base without interfering each other’s work. Because of its collaborative character we also use GitHub for documentation of artefacts like API implementation guidelines etc. GitHub allows us to write a first version and then hand it over to the full team for review. Everbody can apply changes or give comments while the author can trace what’s been changed at a single glance.

Specifications in the wiki

As all of us know development of software for different clients needs specification of the respective needs and requirements. This is done by our product and project owners who specify all their user stories in a wiki. We always try to keep the structure of the wiki elements the same so the efforts for reading through all specs can be reduced to a minimum. Actually, an outcome of one retrospective was that we need a special format for the specification of KPIs and metrics that we use in our smart data projects. With aid of the development team the product owner was able to define a file format that is used eversince for definition of such KPIs. This avoids a communication overhead when we enter the implementation phase because it accounts for the positive atmosphere within our department as we are all working with the same files, same formats and especially the same project language. Of course the wiki allows everybody in the team to access from everywhere and another time this makes the geographical borders in our team to become more and more blurry and irrelevant.

Summary

There is no such thing like the tool that enables a company to build a a remote working culture. It is the combination and right implementation of tools in the daily work. One of the most important drivers is the team driven decision making when it comes to tools. Only the persons who have to use and work with the differnt tools should test them and decide whether to establish them or not. One might think that this opens Pandora’s box because teams would raise interest for new tools everyday. This is wrong for two reasons:

1. At the end it comes down to collective team decisions when somethings new should be tried
2. The longer a department is working with a specific tool the bigger its dependency gets with respect to your working culture

If the team still wants to change this so badly, then this tool really seems to be a pain and it is probably pushing your team’s satisfaction, producitivity and creativity more than it is acutally pulling it. Basic steps into a more communicative and independent working culture should be to talk about the current processes and analyse with your team what are the pros and cons. Consequently you should introduce improvements step by step and adjust your overall setup in an iterative and agile way. Feeback is key and counter arguments not necessarily mean that the selected tool or process is not working but maybe it is not properly used and just needs adjustments. Think about the key characteristics that you want to endorse in your team. Is it creativity? Introduce less words, more pictures in your meetings. Is it transparency? Introduce checklists in trello for each team member in a Scrum standup manner and so on an so forth.

I will now share my lines via GitHub and Slack with the team, move my Trello task forward in our sprint board and tell my team members tomorrow in our hangout standup that I finished my article and that I would like to get some feedback. I am wondering in which country it will be read first.