Flexible processes and distributed teams - the secrets of excellence
A couple of months ago I was at a Scrum training. Sharing experiences with fellow practitioners, she mentioned that I now have a team of ten people in eight offices. It’s not that they didn’t believe me at all, but the talk that we had a normal process was treated with probably justified skepticism.
However, we are successfully doing projects with teams divided into 2-4 offices, all in all, we currently have ten development offices, and when we are looking for a person in a team, we pay attention primarily to his abilities and human qualities, but already the second - to the place of residence. In addition, in our company people sometimes wander between offices, because it is so much more fun. In general, when we started work on our current project, we had only four locations.
I have been working in DataArt for six years, and I have considerable experience in organizing people who are hundreds of kilometers from each other. I suspect that members of freelance teams read me with a condescending grin, but I think there will be people who find my experience useful.
So, I want to share the observations, techniques and principles of organizing a distributed team. In projects, we usually practice Scrum, except when this is not possible due to the unavailability of the customer. But in this case, we must be a single team, synchronize knowledge, status and all that jazz.
So what is the problem of a distributed team? Communications. Communication at all levels is difficult, which creates 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 have identified for myself three components of the communication problem:
- Technical : if a person is not nearby, you can’t just take him and approach him to discuss some current problems.
- Motivational : if the team does not have its own room where there is a board with stickers, a list of problems and the rest is useful context, the focus and priorities begin to “float”.
- Psychological : people who do not sit nearby and do not see each morning discussing the latest news or the success of their children at school during coffee are less inclined to forgive mistakes to colleagues, especially if they only know the login in the version control system and e-mail about their colleague. The concept of “we and them” may arise in relation to colleagues from another office and other unpleasant things
- A separate point is the adaptation of Scrum activities for a distributed team.
Technical component
It is solved by modern technologies in general for one or two. Messengers, voice communications, screensharing and even a camera in the phone - all to help us.
We have traditionally been using the good old Skype for a long time, but problems have recently started with it, and the product has a lot of worthy competitors. I know that at least one team with us uses Hangouts. So I would suggest on Skype not to go in cycles.
All team members are on Skype, there is a team chat. People sometimes create sub-coaches for several people - to discuss their problem. There is an agreement that when a person is at a computer, he reads what has come on Skype.
When there is not enough text and voice, you can fumble the screen. Skype premium allows this even in conferences, before I still used join.me (probably, if I strain, I’ll remember a dozen more such products).
Once we discussed architecture, and I drew along the way in a notebook, then I took pictures on the phone and sent it to a colleague, a colleague drew it in paint and sent it back.
In general, glory to modern technologies, there would be thoughts and ideas that are worth sharing, and there is a way to do this quickly and effectively.
Motivational component
Here it is already more difficult. Of course, every project has a wiki, Confluence, or a corporate Sharepoint site. But, honestly, who looks there, except for links to environmental and passwords from test accounts? The correct answer: beginners of the project in search of a high-level description of architecture.
But, if people are not reminded of goals, sprint status and all sorts of simple rules, the team relaxes. A successful process requires information radiators .
There are two options, I use both alternately or immediately: general discussion of what we see on the virtual dashboard during stand-up, and sending out a capacious short status letter, in fact - the same radiator.
For example, starting in the second half of the iteration, QAs send out their visions of what is happening every morning. A list of user stories, the status of everyone who is responsible for moving it further.
Color coding of the status is our know-how (now I thought about whether to patent it). Orange - coding in progress, developers are sure that they will be in time; yellow - submitted for testing; light green - testers accepted and the story can be shown; green - received PO. Red - there is a high risk of not being in time, that is, we are not wasting efforts until we close the rest. Black was also agreed - for those excluded from the iteration. If the testers did not accept the functionality, it bounces to orange or red.
In the same letter, a list of risks, blockers and all that is worth remembering right now is reminded. Such a letter is sent once a day after stand-up, it should be as short as possible and include only the most important. It completely carries out the main functions of those very beautiful and not very diagrams, hung on the walls of the room for stand-up. The main thing is that it really should be short, and the most important thing should be on top: no developer will scroll ten screens of “some kind of managerial nonsense” to the bottom
Psychological aspects
I am not a certified psychologist, but it is obvious to me that if the project participants feel like one team, a special group, they will support each other, forgive, do not want to let the team down, and generously offer help to a stalled colleague.
The biggest obstacle for this is purely business relations, when team members perceive each other not as living people, but as an incomprehensible picture from an avatar, where some dude in a motorcycle helmet poses against the background of a collapsed pioneer camp, and all this in the size of 70x70 pixels and filmed 10 years ago.
In order for logins in the commit 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, a small talk is welcomed, a discussion of some news, problems, links to quotes from the bash. In accurate doses, this does not interfere with work, but it creates an understanding and feeling of who you work with.
At the beginning of the project, we, of course, are trying to get together and have a
Not all people see the point in this. Our team has a man 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, project chat interfered with someone. There is an option in skype: make so that notifications of new chat messages appear only if there are keywords. We had a special spell to summon a QA lead.
The paradox is that such “eccentricities” play a positive role and contribute to the appearance of intra-team memes that are understandable only to project participants. And 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 general the context, the less division into “they” and “we”, the more united the team.
Here, probably, 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.
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, not having a clue on which floor the one who is doing the next one sits.
In the late 90s, when these ideas arose and took shape, video communication had not yet been developed. The workstation capacities could only afford e-mail and ICQ (Jabber, IRC, etc.) and the only reasonable way out was to put everyone together. Now, technology already allows you to adapt Scrum to the use of video conferencing without degenerating the idea into nightmare cargo cults.
Daily scrum
The easiest. Everyone pours coffee, sits down at the computer, puts on headphones and the Skype conference begins. Stand up as stand up.
Usually the project leader fumbles his screen on which our scrum tool is deployed. We update the status, time spent, what else is there.
We agree on rallies and discuss problems. The only difference is that people sip their morning coffee while not standing.
We have a rule that at first everyone speaks briefly, if anyone has something to discuss, they stay in the conference, but they don’t need to, they can disconnect and go to work. I usually send minutes after the rally, and everything is fine.
Sprint Planning Meeting
This is the hardest part. We are going to a conference again, PO fumbles a screen with sketches and a description of the story, the team watches, discusses, votes ...
According to the classics, it can last up to 4 hours.
Unreal. From experience, if a person sits in headphones for more than 30 minutes, he just needs to relax his attention and look away, 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 last 45-60 minutes, but this is the edge, then you need to stretch your legs, neck, drink water ...
If you go “for 10 minutes”, it drags on, because someone went to pour coffee and got stuck arguing about the merits of the last framework. While everyone was waiting for him, the programmers had already left for the code, and the tester launched a bunch of autotests and now just pours the test data into the database via VPN, so everything is bubbling and the image freezes.
Therefore, we plan to sprint strongly in advance with pieces of 30-35 minutes a day. Sometimes two pieces - in the morning and in the evening.
Planning pocker also happens on Skype. If all team members have a deck, people simply select a card and show it with a shirt to the camera with the words "ready." If there are no cards, then the number is dialed into the chat, the person says “ready”. On command, people turn cards over 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
Spaced in time and also held as video conferencing. Often, stakeholder customers have some kind of room equipped with cameras, screens, and sometimes even working equipment, including a presentation for them, a log of comments questions, results are sent out ...
Retrospective usually happens the very next day, a list of topics and voting it goes through project chat.
The last planning session, which marks the beginning of the iteration, happens after the retrospective, to, if necessary, shift the emphasis of the iteration and add or remove something.
That, in fact, is all.
Nothing really wise, but it works.
And we really make projects distributed teams.
Have a nice day, everyone!