Trust Stories – Growing trust in distributed teams (RU)

Last week me and Alex Pikulev of Agilix recorded Trust Stories podcast episode, on Growing Team Trust in Distributed Teams. Courtesy of In Teams we Trust website

Main bullets are: 
– Growing trust in distrubited teams is hard, but nevertheless as important as in co-located team. 
– Team itself creates an atmosphere of trust in itself. Our task, as a scrum master, coach, manager – is to help and highlight needed areas.
– XP and especially Pair Programmingи helps in growing trust.
– Intrateam trust, from the informal side (skype beers, navigating as a guest to your colleagues in other locations, bike fixing via the webcam, ordering stuff on flea market in your city and sending it over to a colleague) helps a lot.
– More freedom for the team, for collaborative work and motivation. More trust! Work harder on understanding the context and value of features implemented.

More details (rus) / tg channel : https://t.me/inteamwetrust_rus/35
Video: https://youtu.be/Pq82aFap1rc

Workflow for the Requirements in the Distributed team

This is basically the anatomy of a distributed team, working on requirements. Key point here is that this is the process working for us, in current configuration, and it’s effective.

Disclaimer: Every organization is different: from internal structure to how it communicates with the outer world. So no workflow is a silver bullet.

Disclaimer 2: SkuVault is an ever-improving team of ~50 people, distributed across 10 timezones, 2 different versions, and serving loyal clients worldwide 24/7. Learn more about Communication in distributed teams: Messenger & Rules, or Why we ditched Scrum, in favor of Kanban in JIRA

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
  • No interruption

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

IMG_20170822_125022 (1)
mind the typical bad estimation of space on the left 😛

New Issue

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.

Example: 

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

  1. Picker gets to the QC table
  2. QC performing person takes the product, QCs it and labels the product with shipping label and tracking number
  3. The tracking number is added to the system and can be visible in relation to the sale
  4. 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

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

  1. Before the user clicks a Shipment Tab in the Sale Info page, the hint at the top says “Click a Shipment for Detailed Information”
  2. When the user clicks a Shipment line they see complete Shipment details at the top.
    1. list of fields for Shipments can be seen in Shipments – Plans / Technical Requirements
  3. They can click a button for Shipped Items or Total Cost to see detail for the items.
  4. If a Tracking URL exists for a shipment the user can click it to open the URL in a new tab.
    1. After new tab opens, user is navigated to shipping carrier website with tracking url info
    2. If there is not a tracking url user simple sees “Unknown” instead of the url.
  5. 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 :).

kanban_board

Nutshell

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!

Smaller IDEAS tickets - Page 1

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 ;). 

Year Retrospective @ SkuVault

Last year guys from SkuVault offered me an amazing opportunity to help the company manage a growing development team, create organized schedule, establish workflow that reflects the company goals .

For those who don’t know – SkuVault is a Warehouse Management System (WMS). Like a swiss army knife, SkuVault manages and syncs your inventory across e-Commerce platforms, POS, Logistics and Warehouses, providing accurate quantities in order to prevent out of stocks. Headquartered in Louisville, KY – SkuVault helps to manage the inventory for hundreds of clients all across the globe.

2540ridgemar

It’s time to list some of the achievements we accomplished during this year.

Observational Research and Optimization Scenarios

For the first 2 weeks, I was examining the flow within the project, and getting to know the team. Each couple of days I published blog posts on my findings with ideas on how to improve and optimize the workflow. Some things in my new team were completely different from my previous experience:

  • No teamleads. That meant that developers split up into Code Review teams, and reviewed each other.
  • Technology stack (.NET at SkuVault vs Scala / Riak / react.js at Storia). With all the pros and cons, .NET development teams don’t have that clear BE / FE differentiation: backend developers can work on frontend tasks via ASP.NET MVC, so our devs are more like (..universal soldiers).
  • No UX / UI design step in the workflow. This particular part makes every decision much faster. The product itself (SkuVault Warehouse Management App) uses Bootstrap, and is very utilitarian from design perspective. Key factor here is ease of use (as much as it can relate to industrial application).
  • Distributed team on both sides of the Atlantic, covering almost 24 hour period.
  • SkuVault is used by hundreds of customers around the world, bugfixing happens daily, and there are different bug priorities. This particular moment doesn’t work well with typical “sprint->release” cycles (because the priorities may change quite fast, or something needs to be urgently released).

With all those differences in mind, I started to streamline the workflow in JIRA.

Statuses, Transitions, Workflow

I managed to decrease the number of statuses.

  • Used to be: 23 (with any transitions allowed between any statuses)

shawshank_redemption

  • Became: 9 (with clear status sequence that reflects state of a bug / new feature).

SkuVault v1.7 - JIRA 2016-06-08 15-12-47

Most statuses were redundant, I’ve changed some of them with combination of “labels + status”, some were eliminated and substituted by generalized statuses (for example statuses “Design Holds”, “Client Clarification” changed to status: Hold + label “IncompleteDescription”).

The Workflow is constantly being refactored and improved per developers’ suggestions and whole team feedback. Last week I’ve released the 7th version of the workflow in a year.

Flow in general, and for every team member (BA / PM / Dev / QA) is described in our wiki, as well as terminology, list of labels to apply (there is a special glossary for labels). I explain the workflow as a sequence of steps, so that there is an instruction in case of emergency, or a new person onboarding.

On Duty Teams

During the first week we started to ask developers to fill a small questionnaire to find out how often they are distracted from new feature development by urgent client requests or bugfixes requiring immediate attention. It turned out that significant time (up to 80%) had been taken by Urgent Tasks, which distracted devs and made their work less efficient.

So the management team (well, actually it’s more like PMs, CEO, CTO and Support Lead) decided to establish teams of on call devs. These teams (2 devs: Frontend and Backend) would work only on urgent tickets, which allowed the rest of the team to work on regular tasks, ideally, without distraction.

On duty team concept has been rethought a couple of times, and currently we’re aiming at having 3 devs on call each shift, as client base grew significantly, and so have the requests, tasks and points of attention. Some of developers still get pulled to urgent tasks, because SkuVault heavily relies on integrations with other SaaS / eCommerce / Shipping systems, that change their APIs, improve their products, and may occasionally alter the way they interact with our system. And on duty devs may have questions for the developer who built the integration originally.

However, the concept itself proved to be extremely helpful, and overall the issue is resolved.

Mentorship

It’s a common thing to establish, when you have senior and junior devs 🙂 In order to clarify overall system architecture questions, seniors mentor other developers and code review.

Ticket Description Standards

Creating a clear guidance on filling out the fields and required info on a bug / new feature / or any other issue type is essential to streamline development.

Rules: Filling out ticket fields in JIRA - Project Management (SV) - Agile Harbor IKB 2016-06-17 12-01-08

Changing Kanban approach to Hybrid Scrumban

In a nutshell, a year ago development boards (one for planning, one for development) included lots of statuses, was extremely heavy (as you gotta display ~1k tickets), and hard to manage. Kudos to Tim Jannace and the team , who managed to bravely (and successfully) operate and maintain this board!

However, an agile board should focus on one goal: to show a piece of flow relevant for particular scenario / area. So those two boards were split up, so that each board reflects a single scenario:

  • Development Board, where the tickets transition from ToDo to Ready to Release: Scrum Board;
  • Urgent Board, which is used by on duty teams, and includes only Critical and Blocker tickets: Kanban Board;
  • Quality Control Board, where developers and test managers can to see the scope of tickets they need to review: Kanban Board;
  • Release Board, for the release manager to overview and manage the tickets that should be merged to master: Kanban Board.

There are boards for DevOps tasks, of course, as well as for other projects, but developers mostly have to check 2 boards maximum. And both of the boards are easy to use and lightweight.

On the other hand, pure sprint -> release cycles do not reflect how SkuVault operates, because of the Urgent bits that need to be released almost daily. So sprints are more like folders here, which allow us to forecast approximate or particular start / release dates for the tickets, and limit feature scope in a given time period. That’s why it’s called ScrumBan 🙂

Notifications, Due Dates, etc

I’ve also established automated email notifications on Pull Requests or Tasks are not Reviewed / Tested for more than 2 days.

We started to use labels trigger notifications for tickets that will soon miss due date, or for ones that shouldn’t be rescheduled.

There are a lot of other specifics, changes, undergoing improvements – over the year team grew significantly, as well as number of clients – and we adjust the company flows accordingly. Developers look motivated, and I couldn’t be happier to work in such an environment.

Key findings this year:

  • Don’t make a release the goal itself. Quality product is the goal. So you can skip a release or two, but deliver something good. Even if there are lots of clients,they would understand the importance of stability, not the feature they want firsthand;
  • Write up retrospectives on problematic moments, so that you solidify foundation of your experience for yourself and others. Try to gather additional data and opinions inside the team, in order to provide a broader angle to the problem;
  • Make everything possible to have a good human relationship with developers and other team members. You are colleagues, and a good person will always try to do her best, if she’s motivated (see motivation reference article);
  • Horizontal hierarchy and a little bit of dev anarchy is always good. Every team member should have his voice at least heard;
  • Always update team feedback on how things are, this is essential to keep the flow up to date and address concerns that devs may have. Cause you know, in IT, team is what defines success, and good manager’s work is to facilitate work and motivate the people;
  • Maintain comfortable release pace for the team and the clients;
  • Read professional literature, but don’t forget to check how this works in reality 🙂
  • There is always room for optimization. You just don’t have enough time! You can spend days micromanaging things, to extrapolate optimization on global flow later. Neverending exciting job.
  • Maintain work/ life balance. Don’t let team overwork.

Aside of your professionalism, key things to stay motivated are team spirit and ability to apply and improve your skills. For the past year we became mature, overcame challenges, and continue to create awesome WMS for our clients. Looking forward for the next adventurous year at SkuVault 🙂

Thanks to Ksenia, Slav and Kim for the review, and SkuVault team for the support.