Flexible processes and distributed teams - the secrets of mastery

A couple of months ago, I was at a Scrum training. Sharing experience with fellow practitioners, she mentioned that I now have a team of ten people in eight offices. It was not that they didn’t believe me at all, but they talked to the conversations that we had a normal process with probably justified skepticism.

However, we successfully make projects with teams divided into 2-4 offices, in total we currently have ten development offices, and when we look for a person to the team, we pay attention primarily to his abilities and human qualities, and in the second - to the place of residence. In addition, in our company, people sometimes wander between offices, because it's so much more fun. In general, when we began work on our current project, we had only four locations.
')
I have been working in DataArt for six years now, and I have considerable experience in organizing people hundreds of miles apart. I suspect that members of freelance teams read me with a condescending smile, but I think there will be people to whom my experience will seem useless.

So, I want to share observations, techniques and principles of the organization of a distributed team. In projects, we usually practice Scrum, except when it does not work because the customer is not ready. But in this case, we must be a single team, synchronize knowledge, status and all that jazz.

So what is the problem with a distributed team? Communications. Difficult communication at all levels, which generates a fan of problems. The same “transportation”, which is mentioned as one of the components of waste (loss) in the concept of Lean Software Development.

I singled out for myself the three components of the communication problem:

• Technical : if a person is not there, you can’t just go and approach him to discuss some current problems.
• Motivational : if a team does not have its own room, where there is a blackboard with stickers, a list of problems and the rest of the useful context, focus and priorities begin to “float”.
• Psychological : people who do not sit side by side and do not see each morning discussing the latest news or success of children at school for coffee are less inclined to forgive mistakes to their colleagues, especially if they know about a colleague only the login in the version control system and e-mail. The concept of “us and them” may arise in relation to colleagues from another office and other unpleasant things.
• A separate item is the adaptation of Scrum-activities for a distributed team.

Technical component

It is solved by modern technologies in general once or twice. Messengers, voice communication, screensharing and even a camera in the phone - all we can help.
We have traditionally used the good old Skype for a long time, but problems have recently begun with it, and the product has many worthy competitors. I’m aware that at least one team is using Hangouts. So I would suggest that Skype does not get hung up.

All team members are on Skype, there is a team chat. People sometimes create podchatiki for several people - to discuss their poser. There is a persuasion that when a person is at a computer, he reads what came in Skype.

When there is not enough text and voice, you can fumble the screen. Skype Premium allows it even in conferences, I used to use join.me before (probably, if I strain, I’ll remember a dozen more similar products).

Once we were discussing architecture, and I painted on the go in a notebook, then I took pictures on the phone and sent it to a colleague, my colleague finished painting it in paint and sent it back.
In general, the glory of modern technology, would be thoughts and ideas that are worth sharing, and there is a way to do it quickly and efficiently.

Motivational component

Here it is more difficult. Of course, every project has a wiki, Confluence, or a corporate Sharepoint site. But, hand on heart, who looks in there, except for links to environmental issues and passwords from test accounts? The correct answer is: project beginners looking for a high-level description of the architecture.

But, if people do not remind about the goals, the status of the sprint and all sorts of simple rules, the team relaxes. For a successful process, information radiators are needed.

There are two options, I use both alternately or immediately: a general discussion of what we see on the virtual dashboard during the stand-up, and sending a succinct short status letter, in fact, the same radiator.

For example, starting from the second half of the iteration, QA sends out their vision of what is happening every morning. The list of user-story, the status of each who is responsible for promoting it further.

Color coding of the status is our know-how (now it was thought, not to patent it). Orange - coding in process, developers are confident that they will have time; yellow - transferred to testing; light green - testers accepted and the story can be shown; green - took PO. Red - a high risk of not having time, that is. We do not spend efforts until we close the rest. Black was also specified - for those excluded from the iteration. If the testers did not accept the functionality, it bounces back to the orange or red level.

The same letter recalls a list of risks, blockers and everything that is worth remembering right now. Such a letter is sent once a day after the stand-up, it should be as short as possible and include only the most important. Quite to itself carries out the main functions of those most beautiful and not so much diagrams hung on the walls of the room for stand-up. The main thing is that it is really short, and the most important thing is to be on top: not a single developer will scroll to the bottom ten screens of “some managerial nonsense”

Psychological aspects

I am not a certified psychologist, but it is obvious to me that if the project participants feel that they are one team, a special group, they will support each other, forgive, not wish to let the team down, and generously offer help to a stalled colleague.
The most obstacle for this is purely business relations, when team members perceive each other not as living people, but as an incomprehensible picture from the avatar, where some dude in a motorcycle helmet poses against the background of a collapsed pioneer camp, and all this in the amount of 70x70 pixels and shot 10 years ago.

In order for logins in the commits log and nicknames on Skype to be perceived as living people, I always ask people to use cameras when talking, so that we can see a living person, facial expressions, non-verbal information; in general chat and even on stand-ups small talk is welcome, discussion of some news, problems, links to quotes from bash. In careful doses, this does not interfere with work, but it creates an understanding and a sense of who you work with.

At the beginning of the project, we, of course, are trying to get everything together and pobohat to get to know each other, to arrange team building. If everything succeeded, there was enough fuse for several months, and in order to continue a little longer, you need to make some efforts to maintain human relations.

Not all people see this as all the meaning. Our team has a person about whom I don’t even know what he looks like, because he basically does not use the camera (I saw one old photo). In another project, some people interfered with the project chat. In Skype, there is an option: make it so that notifications about new chat messages appear only if there are keywords there. We had a special spell to summon a QA lead.
The paradox is that such "eccentricities" play a positive role and contribute to the emergence of command memes that are understandable only to the project participants. But common jokes bring together like nothing else.

In general, internal jokes and traditions of project teams should probably be the subject of study by sociologists. When something new arises and lives for a long time in our projects, I always rejoice, because the more the general context, the less the separation between “they” and “we”, the more cohesive the team.

Here, perhaps, it is worth mentioning the practice of face-to-face (one-to-one), which also works fine on Skype, but it is good and not for distributed teams, there is no particular specificity here.

Adaptation of Scrum Activities

Agile introduced the concept of team and team responsibility as a counterweight to individual engineers, each of whom did some piece of work, without knowing which floor the one who was doing next was sitting on.

At the end of the 90s, when these ideas were born and formed, the video communication was not so developed. The power of the workstations could only afford email and ICQ (Jabber, IRC, etc.) and the only sensible solution was to put everyone together. Now technologies allow Scrum to adapt to the use of video conferencing without degenerating the idea into nightmarish cargo cults.

Daily scrum

The easiest. Everyone pours coffee, sits at the computer, puts on headphones and starts a Skype conference. Stand up as stand up.

Usually the project leader fumbles his screen on which our scrum-tul is deployed. We update the status, time spent, what else is there.

We agree on rallies, discuss problems. The only difference is that people sip their morning coffee without standing.
We have a rule that everyone speaks briefly at first, if anyone has something to discuss, it remains in the conference, who does not need it, they can switch off and go to work. I usually send out minutes after the meeting, and everything is fine.

Sprint Planning Meeting

This is the most difficult. We are again going to the conference, PO is fumbling the screen with sketches and a description of the story, the team is watching, discussing, voting ...
According to the classics, it can last up to 4 hours.

Unreal. By experience, if a person is sitting in headphones for more than 30 minutes, he just needs to relax his attention and look, he suddenly finds himself reading mail or Facebook tape, and you lose it. If a person is interested in the topic of conversation, he can hold out for 45-60 minutes, but this is already the edge, then you have to stretch your legs, neck, drink water ...

If you break up "for 10 minutes", it is delayed, because someone went to pour coffee and was stuck arguing about the merits of the last framework. While everyone was waiting for him, the programmers had already gone into the code, and the tester launched a pack of autotests and now just pours the test data into the database through the VPN, so everything gurgles in it and the image freezes.

Therefore, we plan to sprint strongly in advance in pieces of 30-35 minutes a day. Sometimes two pieces - in the morning and in the evening.

Planning pocker also happens via Skype. If all team members have a deck, people simply select a card and show them face to face with the words “ready.” If there are no cards, then the number is dialed in the chat, the person says “ready”. At the command, people turn over cards or press "enter".

We had intermediate options like drawing a number in a notebook with a marker, or an application for Andriod, which drew a map on the screen.

Sprint Review and Sprint Retrospective

Distributed in time and also pass as video conferencing. Often, customer stakeholders have a room equipped with cameras, screens, and other devices, sometimes even with operating equipment, that is, a presentation is made for them, a log of questions is kept, comments are sent out ...

Retrospective is usually the next day, the list of topics and voting on them goes through the project chat.
The last planning session, which marks the beginning of the iteration, is already after the retrospective, in order to, if necessary, shift the emphasis of the iteration and add or remove something.

That's all.
Nothing particularly wise, but it works.
And we really do projects by distributed teams.

Have a nice day, everyone!