I spoke with Ben Linders of InfoQ (thrilled to be published at that website!) about challenges and communication patterns for Distributed Teams, uncovering bits of my Atlassian Summit 2018 speech.
The biggest challenge of distributed teams is communication, which is essential for establishing ground rules on collaboration. Shifting working hours to accommodate each other and team liaisons help to communicate and synchronize work. Teams based on trust, respect, and openness will thenselves to help people throughout the organization and foster a culture that keeps teams in sync.
InfoQ spoke with Kiniabulatov about the challenges of distributed teams, how product owners and stakeholders collaborate at SkuVault and how the workflow is managed, how distributed teams communicate effectively and synchronize their work, and how SkuVault nurtures a culture that keeps teams in sync.
Recently I hosted Minsk Atlassian User Group, where I shared our experience on migrating to Stride and gave the analogy between Stride, and Russian word ‘Stradai’ (-> eng.: ‘Suffer’). I’ll explain the analogy later. Hence the ‘Napalm Death’ song ‘Suffer’ joke on the first slide 🙂
Given that a lot of people use Telegram as a corporate messenger, and given all of the telegram-blocking happening in Russia currently, it’s pretty relevant to write about alternatives. We at SkuVault migrated due to the need of user control, but migration experience is relevant to many other teams.
Atlassian launched Stride as a HipChat Cloud replacement (so we can call it hipchat 2.0). Main competition is Slack, which is currently de-facto corporate messaging standard, as we know. I’ll compare Stride to Telegram and Slack in areas they are strong.
Biggest point of Stride is that it connects to your atlassian ecosystem. Typically you got single account for Atlassian User, from which you can manage entirety of Atlassian Permissions. Now, Stride is added as an application to the very same account, and access / admin rights are easily managed from the very same place. If you want to have control over the users and the ecosystem that is locked to Atlassian (as we do) -> this is an ideal scenario.
In Telegram we had personal accounts, which you don’t have control of (sure you can create virtual / work phone numbers and link them to telegram to make it corporate-friendly, but that is kind of a crappy way to maintain users ecosystem).
In Slack – you have to pay more than $3/user and it’s a separate account management system.
User Control means removing a person, when she no longer works at the company, visibility for messages in order for infosec to not be compromised.
Audio and Video Group Calls
It may not be something you’d count as a pro, but given that we previously used Telegram + Skype for calls (with hangouts as a fallback in case of skype outage), it’s nice to have same app doing everything.
Jira / Confluence Integration via bots
Integration with Jira and Confluence (not out-of-the-box-though) gives you a glimpse of the ticket in the chatroom (ticket card that reflects priority, assigne and editable layout), ability to create tickets as a command to chat-bot (create new bug Fix spacing on signup page in SV project), bitbucket PR review poking, and a lot of neat other things you’d expect inside the Atlassian ecosystem).
Mentions, citation, styles for text. NO HASHTAGS THOUGH – giant bummer!
And here’s my analogy of ‘Stride’ to russian word ‘Suffer’: you can use Stride, but it’s still raw, and a lot of features you’d expect to be basic in messaging, are half-baked in Stride.
Let’s admit, that Slack sucks at group video calls as well. But Stride is much worse 🙂
Issues include showing bad internet connection, when connection is good.
People may suddenly leave the call, although didn’t click on leaving or anything
Stride’s animations are smooth, so when it switches to another person, it fades in / fades out. And sometimes crashes during that animation!
Video lags a lot, sound doesn’t though
Video freezes a lot, and doesn’t resume until you restart the call
RAM consumption (400mb), CPU consumtion 70% on core i5 2014. This is a lot.
When you share the screen, and stride catches a glimpse of itself (stride window), it falls into the infinite glitch of Stride fractal windows.
Ok, done with the video calls!
No hashtags (sucks)
Sending messages is painful (it’s slow).
Sending messages with attachment is a torture (Stride waits until image is uploaded (slow), and only then allows you to click on send message (which is slow as well)
No forwarding between chatrooms -> leads to isolation of discussions to room-only.
They are horrible (not Rocky-Horror-Show or Dr. Horrible way, and not even Troma-way. They are as bad as most coffee in US (ha-ha)). The sound of notification is bleak and unnoticable. You can’t change it, even if you rip apart the guts of app package and assemble it again 😦 That results in people not reacting on urgent messages.
There is no mute for chat rooms, which results in information overload and renders the whole notifications system pointless.
There is no indication that your message was read by your counterpart. You don’t know whether to poke your colleague or he already read this.
Phone gets 2/3rds of all notifications. But when it does – mac app doesn’t show any of those! This is a typical failure, I’m writing this post on the train from Brest to Minsk where I ride to host AUG Minsk, and our team notified me with long message on my phone, but i see no new messages in my mac app. I have to restart it to get those messages.
Although integration with jira bot is neat (hey, slack does that even better, actually), it crowds chat room’s vertical space like a giant worm that digs Jasinto in Gears of War 2. If you dump number of tickets to dicsuss in the chatroom, you can’t read any message because card previews will occupy the whole 2-3 screens of vertical space.
As per our admins, Stride doesn’t parse JSON on itself, so basically you have to parse and feed parsed JSON to the API yourself. Not the case with telegram.
Stride is not-horrible-beyond-anything, it’s ok. You can use it and adjust to it. Especially if you’re locked to Atlassian Ecosystem (and I love and use jira, even after the latest interface update). But if you’re already on slack – there’s no point, it will work better for now.
There are a lot of things to improve, and the guys at Stride work on making their product better. It took 5 years to telegram to become the best and neatest messaging platform, it took same number of years for Slack.
So as you know my speciality is distributed teams 🙂 This post is about what changes does the agile communication face (and scrum in particular), when it’s adjusted to the distributed teams. This is my experience, I don’t assume this is a silver bullet, but such approach works for me for the last 5 years and proved itself to be proficient.
Let’s divide communication by types:
stragetic meetings (plannning, retrospective)
daily huddles (e.g. daily standup in scrum)
Let’s add another dimension: geographical distribution:
Collocated teams – everything’s perfectly fine for all three types of communication events. Teams, working in scrum, that are collocated face no issues with any of those.
Distributed teams with little difference in timezones, but still with overlapping hours. Great examples are US – Chile / Mexico. Netherlands / India.
Daily syncup can be handled with almost no pain, as well as planning and retrospective (if you incorporate scrum in your company).
Instantness of clarification on work tasks is lost (when overlapping hours end), however given that skype / hangouts / whatever you use is just a click away – no significant impediments are to be found.
No matter what you think about focused team, and that it processes everything faster due to unitedness, whenever team member is outside of her overlapping hours with the rest of the team – communication lag happens.
Distributed teams with no overlapping hours (8+ hours difference).
Approaches here are:
3.1 Team liason. When someone from the team in one part of the world is having a meeting during his time off work, to sync up with other part of the team in different timezone. Usually, team liason is someone from product team, however there are different examples of who syncs up with dev team in the industry. It can be simply a representative from one part of the team that syncs up on the progress with the other part (just like in scrum of scrums)
3.2 Timezone Compromise approach. Teams change their work schedule, to have a compromise in at least 1 overlapping hour, in order to sync properly. For example, start of working day for one part of the team in western hemisphere moved from 10am to 9am, and eastern hemisphere team changes their working day to start from 10am to 9am. Thus, you got at least 1-2 hours overlapping. Whoa, problem solved -> we can get back to bullet 2, on how teams with overlapping hours work together! But remember, everything depends on team configuration, whether the team is comfy with selected approach, and development tasks specifics.
3.3 And finally, you can set up communication process in a way it’s comfortable for everyone in the distributed team. My personal beliefs is that redundant communication is always less efficient than on-demand-clear-bulleted-discussion, thus I’d prefer clear agenda and clarification when needed.
— 3.3.1 First of all, that means that people still are participating in retrospectives and planning sessions, cause those events happen once per 2-3 weeks (thus distraction or working off-time is tolerable). However, those meetings / scrum rituals are to be performed with clear goals, and well-prepared bullets. Try to not allow offtop conversations (when someone gets into topic not relevant to current discussion). Remember, team values personal time, and no team member should suffer from poorly planned meetings.
— 3.3.2 Second, it means that daily sync (or daily standup, if you follow scrum) can be done via text, at the end of team’s working day. In order to reach more visibility, developer can share a link to the branch, that he worked on. But main goal is to have an exceprt of what team member has done during the day, that is visible for everyone (e.g. special channel on updates in telegram). Some people also propose asynchronous video messages (Dave Snowden of cognitive edge shared this experience of his with me, referring to the times he worked at IBM) – you record video message for the team, and even share the screen, if you want some visual material on your work.
— 3.3.3 Third, clarificational communication (meaning day-to-day clarification communication type) is done on demand. Meeting for such batch of clarifications is done in a compromise time, so that noone’s felt left out). The good part of that is since you don’t have to get explanations on critical and extremely complex clarifications every day – you don’t need to torture your colleagues with evening / early morning calls each day. Usually, most of the impediments are resolved via instant messaging. Please keep in mind, that requirements standardisation is a key role in these clarifications, as properly structured requirements save a lot of time while developing a feature.
— 3.3.4 And fourth, but equally important, more standards and documenting. The more info necessary you prepare for your colleagues overseas, for the questions that may rise during your off-time, the less he will be stuck. Please use common sense in how much you need to prepare. When team gets to know each other, such planning becomes much easier. And finally, efficient process always means that person doesn’t get stuck 🙂
Finally, we’re getting to my favourite ever part!
Distributed teams with no overlapping hours + language barrier! I’ve been working with those for the last three year, and here are the additional steps to make it all work efficiently.
The three common baseline rules to follow are:
Prepare meeting agenda prior to the meeting. I’m talking about writing down basic points, explanations, and maybe even branching when presenting solutions (depending on meeting complexity). It’s obvious, that people not fluent in english can’t properly communicate during the meeting – everything starts to require much more time, which isn’t efficient (and quite heavy, when it comes to hourly payrates 😉
More documenting. You may say that Agile says “working software over comprehensive documentation”, however when dealing with distributed teams + no overlapping hours + language barrier, I can’t stress enough how much documentation means. There are key principles better to be described, as the team grows: communication standards (what type of communication is done via which tool, working time, speed of response), requirements acceptance, visual standards for documentation. All three principles affect how developer understands the task he’s supposed to work on. Requirements should have only one way of interpreting, should include clear pre-and-post-conditions; bugs are to be described in reproducible steps.
And finally, it’s essential to have a bi-lingual person (team liason), who helps with english (he comes up with translation of complex bits, moderates the discussion). This person is better to be a developer or someone who gets the technical part well, as she often helps with syncing two development parts of the team. She may also add meeting notes on technical details agreed once meeting is over. That person most likely will sacrifice some of her time off, since hours don’t overlap.
At the end of the day, there are plenty examples across my experience, and blogs, how people manage to work with just on demand meetings, and create complex projects together. Those are git, atlassian and, among others – SkuVault.
Let me add an additional rule to common sense manifesto – process over redundancy. Greatly established process, understandable and rational for all parts of the team, makes it easy to track progress through transparency, keep team motivation high (for being productive) and time off undistracted.
И делаем это без необходимости прилета в РФ американского гендира.
Последние полгода я набивал шишки, ходя по инстанциям, собственно, поделюсь опытом 🙂 Задача: открыть 100-процентную дочку в России (материнская SkuVault.com находится в Луисвилле, Кентукки). Наш случай несколько уникален: CEO не мог посетить РФ, так что заверять и пересылать идентификационные документы приходилось туда-сюда меж двух контитентов.
На практике, все делается достаточно просто. Всего-то придется столкнуться с бюрократической машиной Mother Russia (которая за последние годы стала неимоверно удобнее), проблемами с межведомственной коммуникацией, ну да беготней с документами.
In order to let developer work as productive as possible, management should ensure the following bits related to her work are tackled:
Requirements Fallback – whom to ask
Issue Description & Decomposition
We moved closer to ‘no interruption’ bullet by creating on call teams, that are reacting to whatever urgent issues arise. (hållo to Kniberg’s Scrum from the Trenches 2nd edition – our own way of ‘firefighting teams’!).
However, there was no requirements preparation workflow a while back, so as the features grew more complex, more dependencies were discovered, we faced the inevitable given our product size: scope creeps, miscommunication, conclicting scenarios and inconsistency.
In order to bring all departments that were related to requirements eliciting and approval, we’ve created Product Management flow, which had to be highway to hell to better requirements.
Product Management Flow
We aimed to tackle the following areas by creating a formalized workflow:
Easy to understand sequence of steps
Each step has an accountable person, visible to all participants
Workflow encourages Argumentation and Discussion -> no misinterpreted suggestions and details are hashed out collaboratively
Each step ensures higher quality requirements, by providing criterias to be met on the output
Workflow consists of sequential steps: New Issue -> Discovery -> Sign Off -> Analysis
Ticket is created by trigger from multiple sources (marketing, services, tech, customer support forums,..). During this state, the ticket is relatively empty, providing only the request and source of the request.
Transition: In order to move the issue to the next stage, Product Owner reviews whether we’ll ever do this feature. If no – he closes it. Yes, sometime – he moves the ticket to Backlog. Yes, near-future – he moves it to Preliminary Analysis.
Preliminary Analysis (Discovery)
Step Goal: Product owner should outline Feature goal (what we need to achieve, benefits for our company and customers); describe basic business process (general 1-2 sentenses on how it works among the warehouse, since we’re a warehousing solutions company); and add that to wiki-page for that feature.
Brief feature description
Shipments are a way to track sale items that have been shipped to the customer of the Sale. A Shipment exists in SkuVault once a Tracking Number is assigned by the carrier.We want to provide an ability to connect and save tracking numbers, so that our users can have more visibility and editing right inside the app.
What do we want to achieve
Allow people that use shipping providers that don’t integrate with marketplaces as SkuVault How it works on the warehouse
Goal: Allow clients to label products with tracking number, and see shipments in relation to Sale they are attached to
Picker gets to the QC table
QC performing person takes the product, QCs it and labels the product with shipping label and tracking number
The tracking number is added to the system and can be visible in relation to the sale
User tracks the product via tracking number
Stakeholder Sign Off
Since there’s quite a stream of tickets, we let Stakeholders approve bunch of tickets at a time. Someone might say ‘Hey, isn’t that Product Owner’s responsibility, to approve?’. Well, first of all our product is big and includes different areas and domains: services, marketing, tech, operations – all having their own pursuits respectively, even if we’re moving towards the same goal.
Step Goal: approve the idea, general process and timeline for the feature to be developed.
The next step would be to gather related parties and start..
Analysis is biggest, most collaborative and complex part of the workflow. It involves:
[Business Analysts (creating User Stories)] => [collaborative efforts between BAs / UX / Developers (Wireframing)] <=> [BA / Developers (requirements adjustments, brainstorms, decomposition and clarification)].
Outcome: clear and atomized User Stories with Backend Subtasks with estimates, that give you ability to grasp and plan the feature for development. By you I mean us, Project Managers 🙂
Example: User Story – formalized and easy to grasp description, representing user activity and ability to interact with it.
Precondition: user is on Sale Info page
Before the user clicks a Shipment Tab in the Sale Info page, the hint at the top says “Click a Shipment for Detailed Information”
When the user clicks a Shipment line they see complete Shipment details at the top.
list of fields for Shipments can be seen in Shipments – Plans / Technical Requirements
They can click a button for Shipped Items or Total Cost to see detail for the items.
If a Tracking URL exists for a shipment the user can click it to open the URL in a new tab.
After new tab opens, user is navigated to shipping carrier website with tracking url info
If there is not a tracking url user simple sees “Unknown” instead of the url.
If a Label (ie: PDF) is present, the user can view it in a new tab, or download it by clicking on ‘Download’ button
Post-condition: user is able to see related Shipments info
We got strict rules for creating user stories, technical tasks, support requests and bug reports. This ensures same standards across out task-tracking system (Jira, and properly used Kanban magic) for different issue types, and allows to interpret requirements with the single possible way (which is extremely helpful :).
Right, so in a nutshell, this dramatically increased our requirements quality, and gave us ability to start analysing scope creeps properly, visibility for similar projects and better prognosis. There are things to improve, such as redundancy removal from the requirements, optimizing time spent on the workflow, better communication when estimating client requests – we’re getting closed to that!
one more thing: “oh, author, your flow is redundant for smaller features!”. You’re right, just remove sign off phase and ease analysis to accomodate simple story description for that feature / improvement ;).
Warning: don’t misinterpret scrum for agile as a whole 🙂
Around a year ago I wrote a yearly retrospect on how the workflow at SkuVault is organized, and how we set up our jira boards to work in sprints.
sprints and their goals
There was no Kanban backlog at the moment, and we used Scrum board as an improvized scrumban tool: we had the sprints, which were treated as folders to fit tickets in some time period. Classical sprints were not suitable for our workflow, I mentioned the reasons in Year Retrospective @ SkuVault. So that sprint-folder system was great, visible and allowed us to predict.
Yet, in a year period the signal that our approach (sprints as folders) doesn’t quite work appeared – there was a number of tickets migrating from sprint to sprint being rescheduled over and over.
Allow me to add a small note here on SkuVault specifics: There are different categories of work, and planning a common roadmap doesn’t quite work either: we get different priorities from different departments (QA, Product Management, Services and Angry Clients, Services and Happy and Willing to Pay clients) – so the urgent ticket scope inflates. Urgent tickets may require distraction of a developer working on some client request, which shifts the timeline for delivery. So, in a nutshell: there is no unified roadmap between different categories or depts – there is a near-term plan only, with each category having it’s own stack of priorities. Now add to this a remote team that works in collaboration across atlantic and with the timezone difference of 9-10 hours 🙂
So a question is: how to remodel the workflow to reflect the specifics?
Buckets and Kanban
We came up with the idea of buckets: basically those are categories of work, originating from different departments with separate product owner responsible for stack of priorities.
Last year Atlassian finally realised the scenarios teams use their product for. So, Backlog for Kanban was born out of desperate cry of thousands of PMs, Teamleads and other people who cannot develop themselves and just drag and drop tickets on the boards (/sarcasm).
The feature came out quite handy and we were able to merge our workflow with our development process IRL.
Backlog Kanban allowed us to re-evaluate a lot of backburners that were hanging out there, never getting into the sprints. It also gives us a cleaner board – cause you can store current workload apart from near-term plans, yet in the same board. It’s something you already get with scrum boards, just without sprint management.
We attacked backburners and development scope from two fronts:
created a separate IDEAS project, where tickets were getting fully fleshed out prior to development;
moved all of the backlog tickets that were on the shelf in development projects back to the IDEAS, to re-evaluate;
This + we’ve added Buckets System, with the support of limited number of devs in the pool for each bucket. I’ll try to write a separate post on how Buckets work in our company later (spoiler alert: they work only as indicators of ticket origins, otherwise – they are kind of not really helping, as of the current state, after some teams shuffling 🙂
Boards, Workflows, and two Backlogs
We’ve got two workflows – one for preparing the ticket for ready-to-be-developed state, the second is for development itself.
Each workflow has it’s own board – as you know, boards are the best ever unicorn rainbow tool to show state of the project from a particular angle.
So two boards reflect those workflows.
(Also called pre-development), managed by Product Management. Includes it’s own backlog for backburners, that we put in the shelf for some time (or close to forever); Sign Off, Detalization and Formalization, Architecture Review and finally Ready to Schedule states. Each step has a description and a format of how it should look.
The point of this board is to reflect status of every single idea that we decided to evolve into a feature, and to see the bottlenecks in Product Management workflow.
Establishing that IDEAS board was also a result of creating full Workflow for Product Management, without letting the ticket out of the IDEAS project and into main SkuVault development project, until all the details and edge cases are fleshed out (well, you caught me – there is no chance you get all 100% of edge cases, but you should try as hard as you can).
By creating standards for each step of formalizing the ticket, we’ve ensured the consistent quality of ready-for-development tickets, which ensured that they won’t be put on hold until clarification from API partner / Client / Product Management. You don’t get big stream of tasks pouring into development, but the quality of such tickets lets developers be distracted less and be more motivated, because who wants to switch context and work on something unfinished.
As I pointed out in previous posts – development board is pretty much untouched -> if it works, don’t break it 🙂
But the utilization of Kanban Backlog in JIRA came quite handy for both of the boards: you are able to have a set of tickets in the backburner, still in same project, but not wasting ginormous amounts of space on the board -> you just access all backlog via a special planning view.
While IDEAS board has a backlog with things, that should sit on the shelf for some time, Development board utilizes kanban backlog in a slightly different manner: I store optimization tickets that we need to check every couple of weeks / months there; as well as User Stories for Epics, that are still in IDEAS, that we didn’t get into development yet; or it’s a very handy way to form a pool of tasks for upcoming developers.
JIRA also support swimlanes for boards, which is utilizied by us in a manner of separating projects one from other:
..in a nutshell
We’ve ditched sprints, in favor of Kanban. It’s much easier to not pointlessly drag and drop tickets from one sprint to another, if they’re not ready. As I wrote, Urgent tasks needing on call devs contradicts with uninterrupted scrum approach for developing concrete chunks of functionality in a given timebox (mind the fact that scrum and agile as a whole deals with deadlines badly, while we have deadlines most of the time);
Kanban gave us differentiation by projects on one board, without making the board too crowded. Scrum boards give that too, but count the hassle of moving unfinished tickets from one sprint to another, which doubles the maintenance work;
Kanban Backlog is a great feature, allowing us to manage all tickets in the project. We could have done this in two boards (one for new tickets to be moved to agenda or closed, and another for development / formalization itself) – but now we can manage all tickets in one. Neat.
We had an Urgent Board (Kanban Workflow), and Development in Sprints (Scrum) -> now that we moved Development itself to Kanban, we were able to unify the boards, and everything, from minor to blocker tasks, is visible on the same Board! This is great!
Never use scrum rituals just for the sake of rituals. We didn’t use sprints for the sake of sprints, we approached sprints as folders and timeboxes. However it’s a common mistake, while management or teams create a cargo-cult for scrum. Most likely you’ll use different practices and methodologies over the time, and finally will come to a hybrid approach that makes you efficient.
There are different companies, and certainly there’s no silver workflow bullet for all. So given the maturity / infrastructure / tech. stack / staff – you should model the workflow related and reflecting the flows inside that particular company. SkuVault is changing, growing, scaling – and so is the workflow. Different depts can have different workflows – and we reflect that.